[TriEmbed] Chain-able EEPROM or Similar

Mon Nov 30 15:22:01 CST 2015

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

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