[TriEmbed] Chain-able EEPROM or Similar

Adam Haile email at adamhaile.net
Mon Nov 30 15:38:01 CST 2015


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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20151130/9994c625/attachment.htm>


More information about the TriEmbed mailing list