Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: remote control

Re: remote control

From: Andreas Zwirtes <zwirtes_at_gmx.de>
Date: Thu, 10 Oct 2002 22:26:23 +0200

Well, we didn't discuss the circuit. I think almost anybody would have
come up with a similar solution for the hardware, because the path is
already laid. Most people wouldn't have thought about pulling currents
in off mode or static charges... But what about the software, what do
you think of this protocol?

Issue power port:
Ok, I don't like drawing power from a processor pin as you might guess,
but that seems to be a big discussion point. What do you think of a
short standard frame that we call "give me power for 100ms"? So the
Archos knows, when to provide power, he nows how long and it cannot be
turned on accidentally. The possibility to implement such a frame is
given any time, so we don't have to worry about. We can implement it
whenever we want with this protocol. Also the solution is very easy and
every controller will be able to decide, if he want's to have power or
not. Even if we decide, that this feature is too dangerous (maybe some
guys fried their controllers), it is possible to turn it of with the
next rockbox version. The controller just has to answer "not
implemented" (NACK).

Especially for controllers with limited current driving capabillities
like the Hitachi, port pin powering is a safety issue. Well, maybe the
first step is to figure out, how much the voltage will break down if we
load the controller with 1mA. If it goes below 2,8-3V, it'll be useless.

Matt: Thank you. Every suggestion is appreciated and I saw some good
points. Well, if you understand the protocol (wich is not complete by
now and not even aggreed), you'll see that there already is a framework
to build ahead. All the layers below application don't have a clue what
is going on. You can even send pictures, if you like. Also every remote
can have it's own functionality. And even if the player doesn't support
it, there'll be no problem, because it tells the remote that he cannot
provide the data. Sketches for a remote like in your description would
be very interesting. Programmable buttons would be easy to implement
with a proxy layer, but I think, there's already a big discussion on
that. Maybe the remote should have it's own configuration facility and
use a proxy layer that implements easy functional routing.

Stuart: If you plug in the off the shelf remote, at first there'll be
nothing going on. I don't think that the remote will send a wakeup frame
to the archos. Since I do not have a remote here, could somebody check
that? We also have to check, if the original remote is protected against
collision. Maybe it is not, because the Archos is always switched to
receive mode. We should be on the safe side, if we always let the slave
start the communication. So it really has to be master and detect
connection or power up/down.

Stuart again: It is always possible connect different hardware
solutions. You also can use a 3.3V RS232 pegel converter, if you make
sure that it is possible to switch it to highZ (open). That would always
be necessary, there's no way round. Every remote will have to switch
it's TX off, when it's not transmitting anything. The description was
just a suggestion how to connect a controller. I have easy circuits for
PCs here, that should work. You don't even need a controller, when
talking to a PC.

It is quite a bit complicated to put an external UART on every remote.
You don't know the interface and it will draw more power in battery
powered remotes. But if we use the AVR controller line, we are able to
use the same software in 8pin / 4k up to 144pin/256k (maybe even more)
processors. There also is a GCC port for this device, I beleive. I think
we will have to use different hardware for a handy LCD, a PC remote and
some others. I agree, that is would be usefull to implement one standard
interface with external UART and some buttons / lcd. But that won't be
the ideal mobile solution. And it is not necessary for PC or palm,
because they could use a very simple cable interface that only uses
passive parts.

The IRC should be the right place to discuss smaller issues. This here
is quite right in the mailing list, since it is sorted a little bit on
topic.
What do you think about starting a design document? It could describe
hardware and software interfaces. Is everybody able to view/edit RTF
file format?

Andrew: Agree. I also think it is a good idea to make different devices,
simple cables and weird remotes.

Bye,
Andreas
[radhard]
Received on 2002-10-10

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy