Rockbox mail archive
Subject: Re: remote control
From: Andrew Jamieson (ajamiesn_at_optusnet.com.au)
> And please read the
> last statements of who should be master or slave again. The Archos is
> not able to detect various states and has to poll frequently, when no
> remote is connected.
We'll definitely need some code in the Archos to determine between no remote
(or standard remote which is essentially the same from a port config point
of view), and LCD remote. This would have to come as a message from the
remote, I agree. But there is no problem with this that I see. The original
remote does not use breaks (IIRC) so the detection of a break can jump into
the new remote code. No need for polling, as you've said. The Archos does
not need to know all the states to be the comms master, just recognise the
idle->comms break pulse. The only difference in the system I am suggesting
is that the Archos sends data first after a break, not the remote. That
way, LCD update data can be sent with one message, and an ACK (break by
Archos, Archos sends LCD update data, remote ACKs, timeout to Idle) instead
ot two messages (break by Archos, remote query, LCD update, remote ACK,
timeout to Idle). There is no need to change anything else, and the
protocol is unaffected. Or have I missed something?
> We'll have to limit the duration of the power-pulse, because there
> is no opportunity for the remote to communicate while in "charge-mode".
> I'll try to start a design document.
Definitely have to limit the power pulse. All I am suggesting is a standard
time for this, rather than a configurable one. We could even use a
configure once option I suppose, in the initial power request conversation.
I am just trying to limit the amount of comms back and forth.
> I know some pretty good layouters, after the
> experimenting is done.
I think I'm a pretty good PCB layout guy :)
That's it. I'm gone for a week. Have fun.
Page was last modified "Jan 10 2012" The Rockbox Crew