<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
(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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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).<br>
<br>
-Pete<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/30/2015 01:35 PM, Adam Haile via
TriEmbed wrote:<br>
</div>
<blockquote
cite="mid:CAG8g-TYE-oJ8Sy+SKnsTLz6JDcL_MzUJXSHh4Rz58-WC3Cyd9A@mail.gmail.com"
type="cite">
<div dir="ltr">I have <i>no</i> idea if this technically is
something that exists, but I have to imagine it's possible.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Any thoughts?</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Triangle, NC Embedded Computing mailing list
<a class="moz-txt-link-abbreviated" href="mailto:TriEmbed@triembed.org">TriEmbed@triembed.org</a>
<a class="moz-txt-link-freetext" href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a>
TriEmbed web site: <a class="moz-txt-link-freetext" href="http://TriEmbed.org">http://TriEmbed.org</a>
</pre>
</blockquote>
<br>
</body>
</html>