A very cute hack for a 1-wire LCD panel interface, including power!

[kf4hcw]

On 2015-01-02 18:31, WB4JFI wrote:
> Why reinvent something when another solution already exists

I find that "reinventing wheels" keeps me well in touch with how they
are invented and how they work, and better able to (re)invent other
things as needed.

> Most micros already have I2C libraries (and built-in-the chip
> hardware), so implementation is not an issue.

Not tiny ones. My favorite (at the moment) ATTiny85 has pieces of
hardware and software that can do this, but if I can avoid putting all
of that onto the chip for I2C I can also do a lot more with the chip and
work with fewer constraints. Larger chips do have I2C dedicated hardware
and don't have these limitations, to be sure, but they are also overkill
for many applications. I like to see what I can get out of simpler metal
first.

>   I2C is also bidirectional, and requires confirmation between master
> and slave devices.  I haven't seen devices crashing the bus unless
> defective, but you would have the same problem with the proposed
> shared serial bus.  Or ANY shared data bus structure. 

In many applications the bi-directional nature of I2C is just not
needed. Also, it is harder to build a robust bidirectional network than
it is to build a unidirectional (single master). Extending the
techniques from the article it is comparatively very simple to ensure a
failed device won't break the network. Not so much with I2C as a failed
device that has the option to talk on the network also has the machinery
to break it.

> If you add large enough drivers to the serial data line to provide
> enough power to drive decent-sized motors from the bus, you are going
> to be generating a LOT of RF from the switching transients.

As a rule it would be better to keep the control system's power isolated
(as much as practical) from the servo power, so the intent was never to
drive motors from the data line. The motors would get their power from a
dedicated source and only the control system would be powered from the
data line. Adding the drivers makes it easier to extend that network
beyond one or two devices without losing signal integrity. In a good
design I also hallucinate that each motor subsystem would do it's best
to keep any RF local and to isolate any faults to itself -- can't have
one shorted servo taking down the entire robot if we can avoid it -- and
if all of the RF can be "canned" at the motor itself then it's not
likely to get anywhere it shouldn't.

> To do what is proposed, you now need another micro over I2C to
> interpret device addressing as well as the hardware pin driving. 
> That's another springhead required (over I2C), more software design,
> debugging, and programming time.  Plus, it's only one-way, unless you
> add yet more sophistication in both hardware and software, driving you
> to an even more sophisticated micro chip. 

All true, but consider that the motor controller software would be dead
simple, would only need to be developed once then burned into the
hardware for the servos, and that the tiny processor doing that work can
handle much of the work of the rest of the circuit. IMO, not a terrible
trade-off.

Not to mention that the tiny processor at each motor makes it smart
enough to keep itself operating safely, detect faults, normalize control
directives, and a lot of other things you might decide to do if you have
the chip there anyway... That's a forward looking design advantage.

I know that last bit sounds like a contradiction to the claim of
simplicity so I'll clarify... The software and gadgetry required to make
I2C work and to be as robust as this solution is at least on par with
what might be required to add some safety and management features to the
control software -- so, why not -- but if "not" that's ok. None of that
is required, just possible and low-cost.

If I need some data to come back from a motor then maybe a different
network is in order, or I2C, or something else... but that's a whole new
scenario. In most cases motors on simple robots are open loop servos...
but with the extra processing power out there (for pennies) there's
nothing to stop us from making the controller very smart... consider
maybe sending it as much as 3 bytes -- one for speed, one for max force,
and one for desired position and then letting the controller on the end
figure it out with a handful of extra parts. Even if you're not looking
(no feedback to the central controller) this could add up to a profound
capability in a motor controller.

Anyway -- my original comment was just a bit of thinking out loud about
where this could be taken. If I only have to connect 3 of wires to
control just about anything (Power, Control Net, Ground) -- and those
wires can be patched to anything nearby that has the network, the wiring
loom for any simple robot becomes dramatically simpler and more
light-weight... and in prototyping such a thing I could move virtually
anything virtually anywhere without any heavy lifting. Trying out new
configurations would be much more painless -- not to mention field
mods/repairs under duress.

Got a few joints on an arm with a claw? Run 3 wires down the length of
it and tap in at each servo. Brilliant.

Best,
_M

-- 
kf4hcw
Pete McNeil
lifeatwarp9.com/kf4hcw