[TriEmbed] Chain-able EEPROM or Similar

Mon Nov 30 18:11:57 CST 2015

I have to support multiple LED types... so have to assume I cannot modify
the LED data stream in any way :(

On Mon, Nov 30, 2015 at 7:09 PM, Robert Gasiorowski <rgresume at gmail.com>
wrote:

> 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/ca3d7af4/attachment.htm>