Rockbox mail archiveSubject: Re: archos as a cd changer
Re: archos as a cd changer
From: Fernando Birra <fpb_at_di.fct.unl.pt>
Date: Wed, 31 Mar 2004 19:54:49 +0100
I've started from the Alpine M-BUS plugin from Jörg and modified it to
interact with the IBUS used in BMW cars. So now, I have an Archos "CD
Changer" in my car...
The code from Jörg is very good (what else could we expect) and it already
addresses most of the stuff you mention like hardware interrupts and
queueing of request. I used a playlist approach to the emulation. For now I
am simulating 6 discs (the radio only has 6 direct access buttons) using 6
playlists stored at the root folder, called DISC1.M3U through DISC6.M3U. If
you take a look at the code in the apps directory called playlist.c you will
find most of the code you need to start, shuffle, create, etc playlists. In
my emulator I process the messages coming from the bus directly instead of
using a gateway like you intend to do.
If you want we could further discuss this topic using e-mail.
PS. I will make the code available to all those interested. It is just that
there are still some quite ugly piece of code in there and a bunch of bugs.
"jobarjo" <jobarjo78_at_yahoo.fr> escreveu na mensagem
> Hi all
> I finally succeeded in connecting a sony head unit to a pic16f84a with
> the gnunilink software (gnunilink.sourceforge.net)
> Now I would like it to comunicate with the archos.
> I know I am not the only one wanting to do that. However I've had a look
> in rockbox source, and it seems not easy to interact with the mpeg and
> the status. I could not find any work for a tight integration between
> the mp3 and an external device.
> Could anyone show me a pointer to some work that has already been done?
> The actual remote control stuff is polled! Is there a problem
> implementing a non blocking interrupt handler? I need to implement it as
> interrupt because the archos should respond in a limited time to
> gnunilink requests.
> What I propose is simple:
> - actions are communicated from the interrupt handler to the firmware
> through a queue to avoid critical sections.
> - status are memory mapped. just need some small infos:
> - disc name (folder name)
> - track name
> - time
> no need for a mutex or something...
> for the action queue i propose to use the button queue. navigation could
> be done through standard archos behaviour just by mapping some specific
> head unit actions into some archos buttons...
> For the status, it would be the same, except that the head unit has 8
> characters. the display is also polled by the gnunilink, so there will
> be latency between actions and the display.
> talkbox could help...
> any comments welcome...
Received on 2004-03-31