[TriEmbed] Chain-able EEPROM or Similar

Robert Gasiorowski rgresume at gmail.com
Mon Nov 30 18:09:21 CST 2015


How about something similar to a token ring?
Each LED section would have data in, data out, and return path. The last
node would simply short data out to return path.
You send message (via UART) from controller to data in of the first node,
that node adds it's own message to the original message and sends to data
out, next node does the same, last node passes the message back to
controller on the return path. Controller get all messages about nodes in
the order they are attached.

You would need 4 wires, V+, GND, data, return

On Mon, Nov 30, 2015 at 4:38 PM, Adam Haile via TriEmbed <
triembed at triembed.org> wrote:

> Ok... realize you are talking about Dallas 1-wire now, but is there any
> way to know their order in the bus?
>
> On Mon, Nov 30, 2015 at 4:29 PM, Adam Haile <email at adamhaile.net> wrote:
>
>> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/9b79a3b0/attachment.htm>


More information about the TriEmbed mailing list