From: Andrew Jamieson <andrew.jamieson_at_projectlab.net>
Date: Wed, 9 Oct 2002 09:49:25 +1000

> If the remote uses a controller with a UART, it should be ok to connect
> the TX and RX with a resistor and connect the jukebox to the RX, because
> this is always input and does not need short circuit protection. But
> needs good signal quality. It won't be possible to use the receive
> interrupt of the controller to wake it up, because that requires a
> running oscillator.

Some micros do allow this functionality, but you lose the first byte sent.

> >Why? I still firmly belive that it would be simpler and more elegant to
> >have the Archos send data when required to an LCD enabled remote. It is
> >certainly simpler on the remote side to just take a data stream from the
> >serial line and throw it onto the LCD (after unpacking the payload). I
see
> >they whole system as a master/slave arrangement, and I believe the Archos
> >should be the master, not the remote.
> >
> That's easy. I hope you agree with me, that the jukebox should react as
> fast as possible to keystrokes.

Absolutely. There seems to be some confusion about the difference between
key messages and LCD messages. The remote should send key messages as soon
as they are recieved, without any prompting by the Archos. It is the
specifics of the LCD messages that we are talking about here. As Stuat
pointed out, if we have a remote polled situation for this, the remote LCD
will not change in sync with the songs, and this is unacceptable in my view.

> Stuart:
> This solution could use serial adapters, remotes and a whole bunch of
> other devices one might think of. It is also possible to detect
> connection of the jukebox with a PC. No limitation to any platform.
> Don't limit yourself by implementing a controller timing self-update
> scheme (talking about the controller keeping track of the title time,
> what would force us to keep the controller always full running). We
> don't have comms overhead here. The polling could be rather slow (1/10
> sec?), that would be less communication than updating every information
> on a time-based basis.

At 1200 baud, 20 bytes would take ~ 0.16 sec to send (assuming 10 bits per
byte and no protocol overhead). How can we poll every 1/10 of a second for
info? What I am (and I think Stuat as well) proposing is to send delta info
when required, song name changes, volume updates, etc. This is less
overhead than getting the remote to ask for updates every blah-tens of a
second.

> But please do me one favor: Don't talk
> about "avoid polling", when sending lots of unused data to the remote is
> the answer.

? See above.

> But why should we do that? They are easy, widespread, well known and
> reliable. Don't know anything better for one line bidirectional
> communication. Ok, there's CAN-bus. It has a sophisticated error
> detection and correction scheme, priority control and can handle a
> multimaster bus. But then the SH1 would spend 50% of his time to
> simulate a low speed CAN-bus. Ok, there'e LIN. It is automotive
> standard, but also it is a very stupid protocol for very stupid sensors.
> Anything I forgot?

I dunno why we wouldnt use a UART system. You were proposing a system that
allowed for automatic detection of contention without data loss, and I
assumed that this was to be at the link level, rather than the protocol
level. This is not possible with a single pin UART. I am certainly happy
to use UART comms, and definitely would not recommend CAN or other types
that would require complex emulation.


> For a good design, we should use all available techniques.
> Just take a look at: http://www.lcd-module.de/deu/pdf/doma/s_7123.pdf
> (Only first page is in german, rest english).
> E/A offers modules that are just 2.65mm thick, have I2C bus, use only
> 500µA (at 3V), have 3x12 characters, are very small in size (46x33mm).
> Well, maybe it needs an additional negative supply, but that can be
> generated by an AVR via PWM and a very small coil. Or if that is not
> goot, we could use a graphics display with build in negative supply
> generator. You can see it on
> http://www.lcd-module.de/deu/pdf/grafik/w128-6f8.pdf. Sorry, german
> only. It's also very thin, yet bit smaller in display size. It has a
> high resolution of 128x64 dots and uses a single 3V supply. It also has
> serial and parallel connection. But this display also will draw lots of
> power (about 1mA I think).
>

As I said, I'm sure we can do better. I also haven't given-up hope to power
the remote (mostly) from the Archos. We could do this quite simply by
diode-OR'ing the battery with the remote signal line on a switch. The
signal line is held high by the Archos normally, powering the remote. When
comms is necessary, the Archos lowers the line, indicating a start of frame,
and the switch is turned off to allow the remote to be powered by the
battery during comms (reducing the capacitive loading on the signal line).
The problem with this is that keypress comms becomes an issue. We could
possibly use a relatively frequent poll from the Archos to get around this,
but its a bit messy. It all depends on the final current consumption budget
we have to cater for with the circuit.

> Yeah, you're right. But this here is only used for insertion detection
> and is not used in normal communication mode. There might be other ways
> to detect insertion, but I recommend this, because it won't do any harm
> to the controller or the original remote. We should not use this for
> normal communication, because that is something the UART normally would
> filter out. Maybe you have another idea regarding insertion? I'm not
> very happy with this one. Maybe we also could use a standard UART wakeup
> signal, if the original remote is protected. Possibly the insertion
> shorts some pins of the plug, that would be great! I know that sounds
> stupid, but could be used for controller wakeup if configured properly.
> It's much alike wakeup on key press.
>

Please read the previous posts on this topic.

> Erm, well, you can't switch off the controller, can you? Who would
> detect the pin change then?

The power circuitry.

> Also it is not necessary to switch off the
> controller electrically. It draws less than one microamp in halt mode
> and is able to detect the pin change. It is common practice to leave
> controllers in remotes powered up all time. We also don't need a FET
> switch for the display. A good controller is capable of driving up to
> 10mA through the outputs. So the display could be switched off by the
> controller itself. We should not use a controller, that consumes more
> than a 1-3 microamps in power down. That eliminates all FET switches and
> makes the device cheaper and smaller. 300 nanoamp is state of the art
> but very expensive.
>

I think we should use whatever is cheaper and most elegant. I agree that
this is most probably a good low power uC, and this is certainly my prefered
option.
Received on 2002-10-09