Rockbox mail archive
Subject: Re: new thread about remote control with display
From: Andrew Jamieson (ajamiesn_at_optusnet.com.au)
> A Controller that handles UART data on one pin is not necessary.
This is not necessarily what was suggested. Just bi-directional data
transfer on the one pin from the Archos. The HW interface on the remote,
and specific protocol is certainly up for grabs.
>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.
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.
>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
Not if we aren't using UART compatible protocols ....
> 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.
An integrated UART is definitely simpler, and would consume less power (we
could have the chip wake-up on UART interrupt).
> Battery drain for frequent polls of the remote is not a problem, if a
> UART is used. Frequent LCD updates will draw more power.
I am not really concerned about power-drain caused by polls when the remote
is plugged in (it's probably possible to design either system to consume
roughly the same power). What I am concerned about is the remote continuing
to poll when it is not plugged into a unit. This will rapidly reduce the
life of the battery.
At a quick 5 min search; parts like
http://www.dataimage.com.tw/product/cm/pdf/CM1610NR-J2.PDF have 2mA
consumption (typical). I'm certain we can find something lower than this.
CR2032 usually store ~ 200mA (see
2) so a 2mA LCD would give us ~100 hours of operation (if we get the uC
design right, we can ignore the consumption of this - but this will require
a good design). If we go for something a little bulkier, we could use a
small NiCad or NiMh rechargeable, and trickle from the signal line to extend
the life. It's possible we could use run this re-charge current into the
black if we get an LCD that is low enough in power, and the circuit is good
enough. This would be necessary to use something as small as a 1/3 AAA, due
to it's low capacity
> 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)
Isn't this a 'spike'? I proposed a similar system in my previous
email -what difference are you proposing here?
> Just to answer the questions regarding power: It is absolutely necessary
> to put the controller in total halt mode.
It is simpler to do this. It is ideal in a current consupmtion sense to
have the remote shut off it's power with a FET switch, or such like. It
should certainly operate in it's lowest power mode that interupts can wake
it up from during operation, and most uC's lowest power mode would be
acceptable for multi-month to year long length shelf lives (they usually
scale down to 1-10s of uA, so on a CR2032 that's 200mA/10uA (worse case) =
> 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.
That's why we're talking. I doubt anything is going to be implemented
without an error detection protocol at the very least.
I hope I haven't come off as too negative here. I enjoy discussing
technical issues, (as, I would imagine, do most on this group - hence why
they are here), and am happy to be proven wrong (as has often happened).
Page was last modified "Jan 10 2012" The Rockbox Crew