From: sophana <jobarjo78_at_yahoo.fr>
Date: Fri, 14 May 2004 13:26:10 +0200

[IDC]Dragon wrote:

>>I did not implement the inquiry this way.
>>What I did is a generic poll inquiry, and the rockbox decides if it has
>>something new to transmit.
>>so the response message contains a haeder indicating what is the type of
>>update.
>>there is also a no update response message.
>>
>>As my pic is written in assembly language, I would like to put most of
>>the intelligence into the rockbox side.
>>
>>
>
>Hmm, welcome on your island then.
>This way you just have to make your proprietary Rockbox fork. I was hoping
>for a generic implementation.
>The simple and stupid way would be to poll the information you need, update
>your internals then as you please.
>A more complicated one would be to "register" for certain changes. Then the
>answer to your poll ping can be a more customized response.
>
>
>
The 2 approaches are not incompatible. I just proposed one more inquiry
command...
I don't think there is only one way of doing, but several of them can
cohabit in the same code even if it is harder to maintain...

there is also one thing about names. the pic does not have lot of
memory, so it cannot store a whole filename.
what sony does is that it send the first 16 char first. then when the
name os scrolled on the HU, additional text is requested from the HU.
I have not managed to make it work yet, but i'm working on it (when i
have time)
This kind of limitation surely has an inpact on the protocol.

also as the tx uart is implemented with polling technique, and it is
called from inside the serial interrupt (I did that because of latency
requirement), the less the rockbox has to transmit the better it is. so
a simple response char (nothing new) would save processor time and
overall system latency.
In my specific case, when there is nothing to update, the rockbox does
not even answer to the poll routine, to save processor time.

>>btw: is there an easy way of implementing next/prev folder? (equivalent
>>to next/prev disc)
>>it might be useful to implement standard button codes also like 'ON'
>>,'F1','F2'...
>>
>>
>
>I'm also stuck with that. The primitive implementation I could think of is
>to have 6 (or however many) prepared playlists you'd like to be treated as
>"disks". Another question is how to prepare them.
>
>
>
I saw in tree.c the variable:
static int dirpos[MAX_DIR_LEVELS]
and
int dirlevel;

if these variables are in a consistent state, it should be possible (and
not too difficult) to make a next/prev folder routine. don't you think?
the routine would do the same as changing the next/prev cd: playing
track 1 of the next/prev folder.
of course if there is no more folder, the routine would have no effect.

there are multiple possibilities for the implementation:
first is to cache the parent dir, get the name of the next folder
(dirpos[dirlevel-1]+1), cache the next folder, then build the playlist...
second way might be to cache the next/prev folder names, so we do not
need to read the parent folder.

this mode of navigation would be complement the dirbrowse routine (for
navigating fully through the hierarchy)
I'm also sure that people other than car users might be interrested in
such routines.

I'll try to look closer at it when I have time.

>Jörg
>
>
>

_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-05-14