[TriEmbed] Chain-able EEPROM or Similar

Mon Nov 30 14:44:57 CST 2015

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20151130/245b27f5/attachment.htm>