[TriEmbed] Chain-able EEPROM or Similar

Adam Haile email at adamhaile.net
Mon Nov 30 18:22:38 CST 2015 

Ahh... yeah. They are serial. And always all the same protocol. Mixing
would be just too complicated. It's much cheaper that way.

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

> Are your LEDs connected in series? I thought you want to have those
> (groups of LEDs) in parallel?
> If in series, then how are you going to control them with a single/double
> data line?
> If you use my idea, each node could be program to work with different
> protocols, WS2811, WS2801, etc. Then you use send "universal" LED data over
> common data line and the node converts to a proper LED protocol.
> If the LED number and transfer rate is high, then you would have to run
> separate LED data line
>
>
>
> On Mon, Nov 30, 2015 at 7:11 PM, Adam Haile <email at adamhaile.net> wrote:
>
>> 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/1a29c819/attachment.htm>

More information about the TriEmbed mailing list