From: Andreas Zwirtes <zwirtes_at_gmx.de>
Date: Tue, 08 Oct 2002 02:34:15 +0200

Hi all!

Just read a thread about LCD and remote, that was not too long ago. I
have some thoughts to add from a pro automotive systems developer. This
is very technical stuff and may be hard to read. But at least i think it
is worth the time. So let's start with some basic stuff.

You should not connect the jukebox to a PC parallel port, since theese
are parallel, not serial. The PC usually has serial ports available, so
make use of them. This will make life much easier on the Linux/Windows
side. It takes few minutes to get a serial communication program running
in VB, but maybe several days to mess around with hardware drivers and
timing on the parallel port. Once there is a defined serial protocol, i
will find the time to implement it on windows. The parallel port already
burnt it's outline in my calendar and i won't touch it any more except
for simple tasks like programming controllers..

A Controller that handles UART data on one pin is not necessary. The
automotive industry shows us how to do it. They use an interface that is
called "K-Line". It implements bidirectional communication with one
line. The tricky part is: Both sides have to stick to a given protocol,
that avoids data collision. I can contribute on that issue, if needed.
More on that issue below. There are sophisticated protocols around, that
also allow interruption of one sender by another with higher priority
without loosing data. The suggestion of Andreas Stemmer points the
right way. It would be easy for both controller and rockbox if the
controller frequently asks for data. The rockbox wouldn't spend much
time on the commnuication, because the most complicated part
(oversampling and aligning the serial data) is done by the integrated
UART. The suggested solution is very similar to automotive K-Line
withount priority interruption.

It is ok to send data via a time dependent routine. But if we do this
(which seems to be necessary since UART TX of the jukebox is not
available) the remote should have a hardware UART, since theese do
oversampling and jitter/timing corrections. Atmel have sophisticated and
small low power (3.3V) parts with UARTs.

Electrical protection is not very complicated if controller ports are
used on both receive-sides. The ports of the Atmel AVR parts for example
are ESD protected and have a very high resistance. Also the SH1 ports
have a very high internal resistance. So a simple resistor and a small
cpacitor (!) is enough to protect both devices from current overdrive
even against shorts to VCC or GND. Although short circuits are a problem
with the SH1 without an internal resistor. Chaotic communication with
the original firmware is not a problem with the above mentioned
protection. Don't think about drawing power from the communication line,
unless you already have experience with it. In most cases discharged
capacitors result in heavy communication problems and thus - lots of
communication. This - on the other side - prevents the power capacitor
from charging properly. Also such circuits will result in a badly edged
signal and cause the controller to draw much power. This is common to
all digial CMOS circuits that have to deal with slow rising signals.

Battery drain for frequent polls of the remote is not a problem, if a
UART is used. Frequent LCD updates will draw more power. Don't push the
communication speed for transmitting command too fast. This will
increase software load on the jukebox and power requirements of the
controller. 1200 up to 2400 baud is enough, seriously. Also it is not
necessary to "introduce" the remote/display to the jukebox, because it'l
ask the jukebox for display data. The protocol should enable the rockbox
software to distinguish between original and new remote. With a pretty
well defined protocol it's absolutely no problem to decide if a standard
or "rockbox-type" remote is connected.There is no need to detect spikes
or something. The jukebox could send a wakeup (that's a short push to
ground) to the remote if there is no communication for a given (timeout)
time. Well, certainly it's necessary to analyze the original remote's
protocol and schematics to develop a suitable protocol. That sort of the
before mentioned wakeup is common "language" for most automotive
sensors, that the remote control is very similar to With this
implemented, the remote can also shut down safely without consuming
power or listen to repetitive communication. It will just wake up, if
there is a need to (AVRs and most of the other controllers can do that).
The "plug out" situation will be detected by missing answers from
rockbox. No need for a shutdown command.

Just to answer the questions regarding power: It is absolutely necessary
to put the controller in total halt mode. A very good AVR software
design will draw less than one microamp in power down mode. And that is
the only choice when talking about battery life and small CR2032 Lithium
batteries to keep the device small and handy. We design door lock remote
controllers for cars, so i know what i'm talking about. This is also
possible with a PIC, but they will draw lots of power while trying to do
a UART emulation. I also wonder - while talking about power - what kind
of display are you talking about? Standard LCDs with build in controller
draw more power than one of theese little lithium batteries are able to
provide. Connecting a custom LCD directly to the controller (which is
the only alternative i can imagine at the moment) is only possible with
special controllers. Then we are talking about Texas Instruments. This
problem should be solved before implementing any software, because it
has a high impact on software structure, timing and maybe also on the
protocol.

Generally it's good advice to have some spare bits and a checksum/size
information (called "framing" in automotive) in all transmissions to
differentiate newer versions of remotes in the future and to ensure
correct information. It's annoying to see a fried up display due to
communication problems. Also timeouts should be well thought and
defined. It's better to think about that beforehand, trust me. Could
help on that, maybe with a communication specification.

I don't think that it is possible to do implementations of - for example
Sony - vendor specific propietary protocols for displaying information
on commercial (car-) hifi devices. Just for one reason: There are too
many of them and most are undocumented. Surely it's better to develop a
transparent (documented and easy to understand) protocol. Anybody can
port it to his own device, if he wants to. In one part - that goes to
Andreas Stemmer - i disagree with you. I think, that it is not much of a
problem to get the hardware working. The tricky part always is the
software. btw: respect to all rockbox developers.

Just dreaming: What about a transparent protocol and a small interface
hardware to talk to a ready made consumer remote? Sounds like a flexible
solution that could fit to various protocols and interfaces....

Hope i didn't stress you too much!
Wasn't it Dire Straits who used to sing about "too much information"? ;)

Andreas Zwirtes aka radhard
Received on 2002-10-08