[TriEmbed] Chain-able EEPROM or Similar

Mon Nov 30 15:29:04 CST 2015

How are they addressed?

On Mon, Nov 30, 2015 at 4:22 PM, The MacDougals via TriEmbed <
triembed at triembed.org> wrote:

> How about a 1-wire memory chip to store your  byte?
>
>
> http://www.digikey.com/product-detail/en/DS2431%2BT%26R/DS2431%2BT%26RCT-ND/4915443
>
>
>
> ---> Paul
>
>
>
>
>
>
>
> *From:* TriEmbed [mailto:triembed-bounces at triembed.org] *On Behalf Of *Pete
> Soper via TriEmbed
> *Sent:* Monday, November 30, 2015 3:45 PM
> *To:* triembed at triembed.org
> *Subject:* Re: [TriEmbed] Chain-able EEPROM or Similar
>
>
>
> You've heard of half-baked? This is to half-baked as waving a steak over a
> photograph of a BBQ grill is to cooking beef extra rare. But I can say with
> all honesty that this isn't based on anything except thinking about the
> problem statement. I don't know if this is reinventing a wheel that's been
> out there for years or not.
>
> I'm wondering if this could be done using just the DI/CLK lines of typical
> LED strings? That is, no additional cabling. Each LED string would have the
> nonvolatile gizmoid between it and the controller or next LED string
> upstream toward the controller. Diodes would be in the gizmoid and the data
> and clock lines would go through these diodes, with the gizmoid (a super
> cheap MCU like Shane's ATTiny) having four of its I/O pins connected to
> either side of both diodes. So current from the LED controller's clock and
> data lines can go through the LEDs but only current from the closest
> gizmoid can reach the controller and each gizmoid can sense current from
> downstream gizmoids. By definition the most distant gizmoid is in the
> driver's seat and all other gizmoids react to that last gizmoid and that
> last gizmoid is the only one to react to a controller "query last" message.
> (If I get to the end and it's clear the diode on the clock line is useless,
> then assume I didn't mention it!!) There would be just a few nanoseconds
> delay added to the data stream going from controller to the LEDs during
> normal operation: the gizmoids don't mediate the LED control data flow. The
> effect is just as if a long hank of wire is sitting between LED strings. My
> intuition tells me it might only exacerbate the "send even more zero bits
> with more than 64 LEDs" issue that is already well understood. So
> performance would be impacted but just by a teensy bit.
>
> Now, isn't it the case that the LED strings just sit like lumps if the
> clock line is left low? So as long as the clock is left low anything at all
> can be driven in either direction on the data line and the LEDs will not
> get into the picture and interfere or interpret the bit stream, right? So
> the controller can talk to the most distant gizmoid by bit-banging the data
> line while holding the clock low. The data could be a simple async bit
> stream that could be read by each gizmoid but again, only the gizmoid that
> senses no current from "downstream" reacts.
>
> And the gizmoids would have one big rule: shut up and stay quiet and do
> nothing but listen for a query-start after the last detected clock
> transition. So when the LED strings are in use the gizmoids are perpetually
> restarting their "stay quiet" timers. If/when the timers expire they are
> all looking for a message coming *the other way* if they are upstream of
> the last gizmoid and the last one is looking for a (CRC-validated) query
> message from the controller. The controller switches it's data line from
> output to input immediately after doing this and does nothing but listen
> for X milliseconds minimum.
>
> When the controller sends a query-last (with a valid CRC at the end) all
> the gizmoids receive it and after some short time switch their data lines
> on the "upstream of diode" data bus connection from input to output. If it
> isn't the normal "spacing" logic level for async data (and I don't
> remember, off the top of my head) then each gizmoid sends "one short ping"
> to allow sensing. The last gizmoid fails to sense this current and thus
> knows it's the caboose. It responds by sending an async message containing
> it's payload info and a unique identifier that was programmed along with
> the payload data (and a CRC) and *zero as the UID it detected downstream".
> Every upstream gizmoid receives this message and responds by waiting a
> random length of time while listening and decoding messages from downstream
> and it then sends its message with its payload and UID and *the UID of the
> last message it heard downstream*. After sending, each gizmoid switches
> back to receiving on the data line and and monitoring the clock. A resistor
> in series with the gizmoid's connection to the data bus line limits current
> for the case where there is a transmit collision. Presumably an additional
> circuit would allow the gizmoid to detect collision current as multiple
> gizmoids are trying to sink/source while their cohorts are trying to do the
> opposite. The controller is in input mode during this time and so it isn't
> dueling at a gate level, but presumably the "nearest" gizmoid could offer a
> series resistor enabled with a jumper to protect the controller. If
> collision detection is straight forward a gizmoid could perhaps retry
> *once* after a different random delay to optimize the whole process (but
> whether this would be a net win is debatable and I'm not enthusiastic about
> it).
>
> (If any gizmoid detects a high to low transition on the clock it switches
> its data line to input and goes back to the "waiting for n seconds of low
> clock" state. Again, that's the big rule.)
>
> Meanwhile the controller gathers gizmoid messages, tossing invalid ones.
> After N milliseconds (set with some reasonable "max LED strings" limit and
> the upper limit on random delays ad possible retries) the controller sends
> a message with a string of UIDs and the gizmoids listen to this. This time
> the last gizmoid in the string is not a special case: it and all the other
> gizmoids wait a random time and repeat their info if they didn't hear the
> controller echo their UID back to them.
>
> This whole thing repeats until the controller stops getting any replies.
> It then studies it's information and sends "send your info again" to each
> gizmoid it still needs to figure out. The gizmoid does this with "the last
> UID it heard from downstream". The controller keeps this up until it stops
> seeing new UIDs and is satisfied it has the topology worked out.
>
> Presumably there could be another semantic that says "Do this first and
> repeat each time the physical configuration is changed" to handle the case
> where this whole process is painfully slow. If it's always fast enough it
> could just do it every time the controller initializes or is told that
> something was changed. The async bit rate this whole thing can function at
> would seem to be a function of how accurate the timing of each gizmoid can
> be (figuring the controller's async clock is going to be pretty accurate).
>
> OK, I confess the desire to get other things done eroded my concentration
> and my gazintas and gazoutas and protocol may be mixed up, but hopefully
> this idea might at least point to how this is done out in the real world
> (smells at this point like I've reinvented some bastard form of RS485/RS422
> 'cept I know those guys operate with differential current).
>
> -Pete
>
> On 11/30/2015 01:35 PM, Adam Haile via TriEmbed wrote:
>
> I have *no* idea if this technically is something that exists, but I have
> to imagine it's possible.
>
>
>
> I need a small, cheap (isn't it always?) chip that can store a few bytes
> of data. Actually a single byte is all I need. And can be accessed kind of
> like a shift register where I can query an unknown number of devices int
> the chain and get, in order, the byte that each one stores.
>
>
>
> The intent here is  so that I can have multiple, pre-wired, sets of LEDs
> with an arbitrary order and number of LEDs on each. This chip would store
> the LED count for each pre-wired section. Without knowing anything about
> the pre-wired sections, I need to be able to poll all these chips and from
> that know how many pre-wired sections there are, how many LEDs each has,
> and in what order. The data returned just needs to basically look like: 48,
> 36, 24, 18 (4 sections with 48, 36, 24, 18 LEDs, in that order).
>
>
>
> I assume it would use an SPI-like interface... not exactly since I can't
> use chip selects. Since I would have an arbitrary number. A 2 wire
> interface would be great. Is it possible to do something like this with
> I2C? Basically, I know what I need, but don't know what to call it.
>
>
>
> Any thoughts?
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Triangle, NC Embedded Computing mailing list
>
> TriEmbed at triembed.org
>
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
>
> TriEmbed web site: http://TriEmbed.org
>
>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
> TriEmbed at triembed.org
> http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
> TriEmbed web site: http://TriEmbed.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20151130/a4fb0cbd/attachment.htm>