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

WB4JFI wb4jfi1 at wb4jfi.com
Fri Jan 2 17:31:40 CST 2015



-----Original Message----- 
From: kf4hcw
Sent: Friday, January 02, 2015 5:46 PM
To: tacos at amrad.org
Subject: Re: A very cute hack for a 1-wire LCD panel interface, including 
power!

On 2015-01-02 16:43, WB4JFI wrote:
> There are other solutions available as well.  Several different I2C
> LCD drivers are available, and the number of wires is only doubled to
> four required.  I2C is also a shared bus, so one can argue that you
> aren't actually losing ANY pins or connections on any micro that has
> I2C.  I have some projects that have four different devices sharing
> the one I2C bus on Arduinos, without issues.

This occurred to me... I2C can be more trouble that it's worth in many
cases... one or more of the devices sharing the bus can take down the
entire channel; and on something very small that doesn't have dedicated
I2C hardware you end up using a lot of byte space to make I2C work.

With a little bit of tweaking, this setup _could_ be augmented quite a
bit... what if the first byte selected a target device, and what if you
add a couple of transistors to improve the available current on the line
-- now you have a one-to-many control network that is super robust for
low bandwidth scenarios -- enough for quite a robot. Update several
motor speeds 10 times per second and still have bytes left over to say a
few words on the original LCD display - all over 2 wires... tweak it
just a little more and you don't even have to get the polarity right on
the receiving end... but I digress.

_M

<device 0-255><data><data><data><data><data><null>

-- 
kf4hcw
Pete McNeil
lifeatwarp9.com/kf4hcw

Hey Pete,
Most micros already have I2C libraries (and built-in-the chip hardware), so 
implementation is not an issue.  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.

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.  Maybe enough to cause 
interference to any included RF link.  Maybe enough to mess with any analog 
signals within the robot?  If the motor is powered separately, you lose the 
advantage of less wiring.

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.

Why reinvent something when another solution already exists, is proven, and 
works - probably more reliably.  Less wires I guess and maybe less host 
software...

To be clear, I like the idea in the article for simple LCD display 
interfacing with limited wiring and/or pins.  I wouldn't use it for anything 
more sophisticated, however.
73, Terry, WB4JFI




More information about the Tacos mailing list