From: Andrew Jamieson <ajamiesn_at_optusnet.com.au>
Date: Sat, 5 Oct 2002 17:31:49 +1000

> It's not only setting a bit, rockbox also has to query this bit
> regularly
> and behave depending on the bit of course. As I said, it's not a big
> problem, but it could be more simple.
>

I honestly think this way is simpler. Especially as I would like to see it
integrated with the WPS. If the LCD remote is in, the the remote LCD WPS
info is sent down the serial line. If not, it is not. No extra modules
(OK, maybe a new serial handling module, but we need that anyway ....). Now
I'm not a coder, I may be wrong, but I don't see a remote polled situation
being any simpler (and unless you have a 'go' button on the remote, a polled
situation is going to require insertion notification anyway, or it will draw
MUCH more power).

> This means, the remote will need much power, even if it is not plugged
> in,
> because it has to check the transmit line very often. Perhaps we should
> make the remote wake up on any button press and then send the
> "hi I'm here" message.
>

Most micros can wake up from power-down states on an interrupt, or at worse
a reset. At a pinch, you could even design the circuit to switch itself
off, and turn on at this signal, but this is probably not necessary if the
micro has a good low power mode.

> I would normally plug in my remote when the jukebox is off.
>

Good point. Maybe have to use the Archos poll scheme .... The other option
would be to monitor for changes on the music lines, which would indicate
insertion. Maybe the lines to the headphones change status on power-up?
I'll check.

> Again, lots of power consumption on the remote.
>

Not if well designed. And I'm sure with everyone's input we can do a good
job.

> Good idea.
> I'm not very experienced in such things, I have already programmed
> a µ-controller (ATMEL) and can imagine what it can do, but I never
> tested reliablity or power consumption or something like this.
> Therefore I really appreciate your comments and suggestions.
> I think both solutions are possible but still have the feeling,
> that mine produces less complicated protocols and makes things
> easier. As I posted before: let's try it... (but I'll need some time)
>

And I'm convinced mine is better :) But I agree we should remain
unconvinced until we can test this. However, the HW should be designed to
accomodate all schemes, so the testing _can_ be done .... and I'm just a HW
guy at heart (and mind). This is why all this discussion is a good idea.

A
Received on 2002-10-05