Re: Ipod 5G serial
I guess for core serial transfers it should be fairly simple to keep things generic, ala: int set_set(int baud, int parity, int bits, int stop) // 9600N81 int ser_xmt(char* buffer, int buflen) int ser_rcv(char* buffer, int max, int timeout) int ser_poll(void) Maybe some: int ser_enable(void) int ser_disable(void) ...if you have interrupts Interrupt driven serial I/O may offer extra complications, but generically it's just: voidser_int(void) ...I would think And if it is a fully featured serial port, maybe some other pin level functions. You might find that a good place to look for more ideas is in a DOS interrupt reference (Ralf Brown's Interrupt List springs to mind) Beyond that you will need to decide what you will be doing with the interface and what things a programmer would like to say to that interface, such as: int usb_handshake(...) int usb_sendfile(...) ... etc. and take ir from there. Good Luck, BC i meant, tihnking about keeping it generic from the start... On 22/03/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Wed, 22 Mar 2006, Jonathan Gordon wrote: was there any discussion on how to make it more generic.. tihnking about usb-otg on the h300... Since none of it is close to be supported yet, talking on making non-existing things generic seems very premature to me. I believe usb-otg is a lot more complex and potentially advanced than supporting a mere serial port is. Still, let's add support for it first and then see what we can do generic and what not. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
half-idea for #ifdef and key deifnition hell...
hey all,
ok, so i had a few min on the throne before and i was thinking about
how to make the keypress code nicer (and get rid of those bloody
painful _PRE definitions..)
ok, so just remember, this idea isnt 100% done and prob has flaws, but
thats why im putting it on the list.. so we can argue about it and
make it workable..
so, my idea is to sort of emulate the menu code...
youd have something like
struct {
int button_code;
bool needs_pre;
int ret_code;
function* function_to_call;
} Button_Choice;
where cutton_code is the #define of the button you want to get,
needs_pre will check that the last button was the _pre definition
(which in this would be the array item prior to this one), ret_code
would be the value to return, ill explain the reason in a sec, and
function_to_call is the function to call when this key is pressed
(instead of having a switch afterwards), this would of course be
skipped if its NULL;
so, then youd use it something like
static struct Button_Choice [] {
{ GENERIC_LEFT, 0, 1, NULL},
{ GENERIC_RIGHT, 0, 2, NULL},
{ GENERIC_ENTER_PRE, 0, 3, NULL},
{ GENERIC_ENTER,1, 4, NULL},
...
};
then, instead of calling button_get() or whatever it is, you call
another function do_button_choice(struct Button_Choice *buttons, int
num_choices, int last_button, int time_out) where last_button is used
to store the last_button so the _PRE things work, we could use a
static variable here, but this way means we can call it in a nested
sort of fasino... although, just typing this now, im not sure this is
needed... and timeout sets the button timeout before returning...
in that function it would call get_button with the timeout setting..
if get_button returns BUTTON_NONE then the funciton immediatly returns
BUTTON_NONE also. otherwise it goes through the list and if the button
that was pressed is in the list it checks if it needs _pre, if it does
and the last button was not pre then im not sure what it should
return.. (maybe it should keep going through the list and check if the
same definition exsists but without needs_pre? otherwise return
BUTTON_NONE or BUTTON_UNKNOWN or something?).
if the button is found (and if it needs _pre and it was the last
button) if it has a function to call it returns that functions return
value (or not?) otherwise it returns that items ret_code value.
now the reason we need that and not do like the menu and just return
the item index is so we dont have any #ifdef 's in the switch but can
still use them when adding items...
does this sound workable? would it make life easier and actually be a
good replacement for the current system?
my only concern is that it may not be fast enough... but if its not,
then where key press speed is really needed (i.e games), they can call
get_button() manually...
Re: Ipod 5G serial
On 3/22/06, Bluechip [EMAIL PROTECTED] wrote: I guess for core serial transfers it should be fairly simple to keepthings generic, ala:int set_set(int baud, int parity, int bits, int stop) // 9600N81int ser_xmt(char* buffer, int buflen)int ser_rcv(char* buffer, int max, int timeout) int ser_poll(void)Maybe some:int ser_enable(void)int ser_disable(void)...if you have interruptsInterrupt driven serial I/O may offer extra complications, butgenerically it's just: voidser_int(void)...I would thinkAnd if it is a fully featured serial port, maybe some other pin levelfunctions.You might find that a good place to look for more ideas is in a DOSinterrupt reference (Ralf Brown's Interrupt List springs to mind) Beyond that you will need to decide what you will be doing with theinterface and what things a programmer would like to say to thatinterface, such as:int usb_handshake(...)int usb_sendfile(...) ... etc. and take ir from there.Good Luck,BCi meant, tihnking about keeping it generic from the start...On 22/03/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Wed, 22 Mar 2006, Jonathan Gordon wrote:was there any discussion on how to make it more generic.. tihnking about usb-otg on the h300... Since none of it is close to be supported yet, talking on making non-existing things generic seems very premature to me. I believe usb-otg is a lot more complex and potentially advanced than supporting a mere serial port is. Still, let's add support for it first and then see what we can do generic and what not. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/ One possible goal would be to re-implement Apples own serial protocol - see http://stud3.tuwien.ac.at/~e0026607/ipod_remote/ipod_ap.html this is already quite a sophisticated interface (best ive seen on a mp3 player !) and would allow all current and future accessories to work with Rockbox...Now if only someone would bring out a LCD remote (it IS possible with that protocl) that works with 5G and allows browsing... Im holding out for hte 'true video ipod' which is suipposed to have bluetooth. Im hoping to be able to control it from an old bluetooth phone acting as a wireless LCD remote... g
Re: half-idea for #ifdef and key deifnition hell...
ok, ive done more playing with buttons..
http://users.monash.edu.au/~jdgor1/rb/button_list.txt is a list of
every unique button definition in the source (excluding the plugins)
(its possible i missed a few but that shouldnt matter)
http://users.monash.edu.au/~jdgor1/rb/suggested_button_list.txt is the
list of bassically all the buttons that are used... i think... if all
these are defined for all targets (along with _pre) and smarter button
handling (like my suggestion) is implemented then there it should be
much easier to pick a button for a screen.. the items with * are not
nescacerily neded.. but might be better to have than not. and the ones
with ? im not sure what they are for.. and i wasnt sure what to do
with the last 5 defines so i left them there...
so with this list of about 20 keys that should be defined for all
targets i think it would make it generic enough...
only problem is with the remote control defines.. but that could be
fixed by doin a #ifdef has_remote around the block for all the rc
keys... i think
doing this list, im not sure that my last msg is actually needed now..
or the button function would just return standard values for the
generic buttons or something? this would allow ppl to define their own
combos with much less fuss than now...
On 22/03/06, Jonathan Gordon [EMAIL PROTECTED] wrote:
hey all,
ok, so i had a few min on the throne before and i was thinking about
how to make the keypress code nicer (and get rid of those bloody
painful _PRE definitions..)
ok, so just remember, this idea isnt 100% done and prob has flaws, but
thats why im putting it on the list.. so we can argue about it and
make it workable..
so, my idea is to sort of emulate the menu code...
youd have something like
struct {
int button_code;
bool needs_pre;
int ret_code;
function* function_to_call;
} Button_Choice;
where cutton_code is the #define of the button you want to get,
needs_pre will check that the last button was the _pre definition
(which in this would be the array item prior to this one), ret_code
would be the value to return, ill explain the reason in a sec, and
function_to_call is the function to call when this key is pressed
(instead of having a switch afterwards), this would of course be
skipped if its NULL;
so, then youd use it something like
static struct Button_Choice [] {
{ GENERIC_LEFT, 0, 1, NULL},
{ GENERIC_RIGHT, 0, 2, NULL},
{ GENERIC_ENTER_PRE, 0, 3, NULL},
{ GENERIC_ENTER,1, 4, NULL},
...
};
then, instead of calling button_get() or whatever it is, you call
another function do_button_choice(struct Button_Choice *buttons, int
num_choices, int last_button, int time_out) where last_button is used
to store the last_button so the _PRE things work, we could use a
static variable here, but this way means we can call it in a nested
sort of fasino... although, just typing this now, im not sure this is
needed... and timeout sets the button timeout before returning...
in that function it would call get_button with the timeout setting..
if get_button returns BUTTON_NONE then the funciton immediatly returns
BUTTON_NONE also. otherwise it goes through the list and if the button
that was pressed is in the list it checks if it needs _pre, if it does
and the last button was not pre then im not sure what it should
return.. (maybe it should keep going through the list and check if the
same definition exsists but without needs_pre? otherwise return
BUTTON_NONE or BUTTON_UNKNOWN or something?).
if the button is found (and if it needs _pre and it was the last
button) if it has a function to call it returns that functions return
value (or not?) otherwise it returns that items ret_code value.
now the reason we need that and not do like the menu and just return
the item index is so we dont have any #ifdef 's in the switch but can
still use them when adding items...
does this sound workable? would it make life easier and actually be a
good replacement for the current system?
my only concern is that it may not be fast enough... but if its not,
then where key press speed is really needed (i.e games), they can call
get_button() manually...
Re: Ipod 5G serial
On Wednesday 22 March 2006 01:20, Daniel Stenberg wrote: On Tue, 21 Mar 2006, jkubik wrote: Is anyone working on the Ipod 5G serial interface at the moment? If so, where are you? Since Christi hasn't shown up here yet since devcon I'll fill in and mention that she seems very interested in getting the serial port going on her iPods. We talked about it at devcon. Using the serial port you could get a gdb stub going, use it for debug outputs, make multi-player games and more... I did a bunch of looking around last night. It appears that rs232 is not impossible. I'm going to start with the Ipod Linux install, as I'm a linux person. Once I get the code working there, I'll post what I have here, in hopes that someone can help me put it into the rockbox code. -Joseph-
Re: half-idea for #ifdef and key deifnition hell...
Great work! You just took some work off of Christi's plate toward
cleaning up button definition hell. This is basically very closely
along the lines of what we were talking about at devcon for button
functions, and by moving the pre logic up to a higher level, we can
reduce code size and improve clarity in the button switch loops.
Some questions to ponder:
What is our next step from here?
Are there some button definitions which are optional or nonsensical on
some targets which should be made optional?
Where can we implement the _PRE logic so that it doesn't have to be
duplicated all over the place, and so that (on ipod) scroll touched
events don't interfere with it's proper operation?
Thanks much for looking into this,
Brandon
On Wed, 03/22/06 at 23:05:43 +1100, Jonathan Gordon wrote:
ok, ive done more playing with buttons..
http://users.monash.edu.au/~jdgor1/rb/button_list.txt is a list of
every unique button definition in the source (excluding the plugins)
(its possible i missed a few but that shouldnt matter)
http://users.monash.edu.au/~jdgor1/rb/suggested_button_list.txt is the
list of bassically all the buttons that are used... i think... if all
these are defined for all targets (along with _pre) and smarter button
handling (like my suggestion) is implemented then there it should be
much easier to pick a button for a screen.. the items with * are not
nescacerily neded.. but might be better to have than not. and the ones
with ? im not sure what they are for.. and i wasnt sure what to do
with the last 5 defines so i left them there...
so with this list of about 20 keys that should be defined for all
targets i think it would make it generic enough...
only problem is with the remote control defines.. but that could be
fixed by doin a #ifdef has_remote around the block for all the rc
keys... i think
doing this list, im not sure that my last msg is actually needed now..
or the button function would just return standard values for the
generic buttons or something? this would allow ppl to define their own
combos with much less fuss than now...
On 22/03/06, Jonathan Gordon [EMAIL PROTECTED] wrote:
hey all,
ok, so i had a few min on the throne before and i was thinking about
how to make the keypress code nicer (and get rid of those bloody
painful _PRE definitions..)
ok, so just remember, this idea isnt 100% done and prob has flaws, but
thats why im putting it on the list.. so we can argue about it and
make it workable..
so, my idea is to sort of emulate the menu code...
youd have something like
struct {
int button_code;
bool needs_pre;
int ret_code;
function* function_to_call;
} Button_Choice;
where cutton_code is the #define of the button you want to get,
needs_pre will check that the last button was the _pre definition
(which in this would be the array item prior to this one), ret_code
would be the value to return, ill explain the reason in a sec, and
function_to_call is the function to call when this key is pressed
(instead of having a switch afterwards), this would of course be
skipped if its NULL;
so, then youd use it something like
static struct Button_Choice [] {
{ GENERIC_LEFT, 0, 1, NULL},
{ GENERIC_RIGHT, 0, 2, NULL},
{ GENERIC_ENTER_PRE, 0, 3, NULL},
{ GENERIC_ENTER,1, 4, NULL},
...
};
then, instead of calling button_get() or whatever it is, you call
another function do_button_choice(struct Button_Choice *buttons, int
num_choices, int last_button, int time_out) where last_button is used
to store the last_button so the _PRE things work, we could use a
static variable here, but this way means we can call it in a nested
sort of fasino... although, just typing this now, im not sure this is
needed... and timeout sets the button timeout before returning...
in that function it would call get_button with the timeout setting..
if get_button returns BUTTON_NONE then the funciton immediatly returns
BUTTON_NONE also. otherwise it goes through the list and if the button
that was pressed is in the list it checks if it needs _pre, if it does
and the last button was not pre then im not sure what it should
return.. (maybe it should keep going through the list and check if the
same definition exsists but without needs_pre? otherwise return
BUTTON_NONE or BUTTON_UNKNOWN or something?).
if the button is found (and if it needs _pre and it was the last
button) if it has a function to call it returns that functions return
value (or not?) otherwise it returns that items ret_code value.
now the reason we need that and not do like the menu and just return
the item index is so we dont have any #ifdef 's in the switch but can
still use them when adding items...
does this sound workable? would it make life easier and actually be a
good replacement for the current system?
my only concern is that it may not be fast enough... but if its not,
then where
Re: half-idea for #ifdef and key deifnition hell...
On 23/03/06, Brandon Low [EMAIL PROTECTED] wrote:
Great work! You just took some work off of Christi's plate toward
cleaning up button definition hell. This is basically very closely
along the lines of what we were talking about at devcon for button
functions, and by moving the pre logic up to a higher level, we can
reduce code size and improve clarity in the button switch loops.
Some questions to ponder:
What is our next step from here?
im not entirely sure :p i was hopeing this msg would get more responses...
im gonna implement the function today in 1 of my plugins that uses
_pre on some targets and see how it goes..
Are there some button definitions which are optional or nonsensical on
some targets which should be made optional?
Where can we implement the _PRE logic so that it doesn't have to be
duplicated all over the place, and so that (on ipod) scroll touched
events don't interfere with it's proper operation?
im only worried about the scroll wheel events.. i dont have an ipod so
it might be hard to test it out... but we'll see
Thanks much for looking into this,
Brandon
On Wed, 03/22/06 at 23:05:43 +1100, Jonathan Gordon wrote:
ok, ive done more playing with buttons..
http://users.monash.edu.au/~jdgor1/rb/button_list.txt is a list of
every unique button definition in the source (excluding the plugins)
(its possible i missed a few but that shouldnt matter)
http://users.monash.edu.au/~jdgor1/rb/suggested_button_list.txt is the
list of bassically all the buttons that are used... i think... if all
these are defined for all targets (along with _pre) and smarter button
handling (like my suggestion) is implemented then there it should be
much easier to pick a button for a screen.. the items with * are not
nescacerily neded.. but might be better to have than not. and the ones
with ? im not sure what they are for.. and i wasnt sure what to do
with the last 5 defines so i left them there...
so with this list of about 20 keys that should be defined for all
targets i think it would make it generic enough...
only problem is with the remote control defines.. but that could be
fixed by doin a #ifdef has_remote around the block for all the rc
keys... i think
doing this list, im not sure that my last msg is actually needed now..
or the button function would just return standard values for the
generic buttons or something? this would allow ppl to define their own
combos with much less fuss than now...
On 22/03/06, Jonathan Gordon [EMAIL PROTECTED] wrote:
hey all,
ok, so i had a few min on the throne before and i was thinking about
how to make the keypress code nicer (and get rid of those bloody
painful _PRE definitions..)
ok, so just remember, this idea isnt 100% done and prob has flaws, but
thats why im putting it on the list.. so we can argue about it and
make it workable..
so, my idea is to sort of emulate the menu code...
youd have something like
struct {
int button_code;
bool needs_pre;
int ret_code;
function* function_to_call;
} Button_Choice;
where cutton_code is the #define of the button you want to get,
needs_pre will check that the last button was the _pre definition
(which in this would be the array item prior to this one), ret_code
would be the value to return, ill explain the reason in a sec, and
function_to_call is the function to call when this key is pressed
(instead of having a switch afterwards), this would of course be
skipped if its NULL;
so, then youd use it something like
static struct Button_Choice [] {
{ GENERIC_LEFT, 0, 1, NULL},
{ GENERIC_RIGHT, 0, 2, NULL},
{ GENERIC_ENTER_PRE, 0, 3, NULL},
{ GENERIC_ENTER,1, 4, NULL},
...
};
then, instead of calling button_get() or whatever it is, you call
another function do_button_choice(struct Button_Choice *buttons, int
num_choices, int last_button, int time_out) where last_button is used
to store the last_button so the _PRE things work, we could use a
static variable here, but this way means we can call it in a nested
sort of fasino... although, just typing this now, im not sure this is
needed... and timeout sets the button timeout before returning...
in that function it would call get_button with the timeout setting..
if get_button returns BUTTON_NONE then the funciton immediatly returns
BUTTON_NONE also. otherwise it goes through the list and if the button
that was pressed is in the list it checks if it needs _pre, if it does
and the last button was not pre then im not sure what it should
return.. (maybe it should keep going through the list and check if the
same definition exsists but without needs_pre? otherwise return
BUTTON_NONE or BUTTON_UNKNOWN or something?).
if the button is found (and if it needs _pre and it was the last
button) if it has a function to call it returns that functions return
Re: half-idea for #ifdef and key deifnition hell...
On Thu, 23 Mar 2006, Jonathan Gordon wrote: im not entirely sure :p i was hopeing this msg would get more responses... When we discussed this at devcon, we decided there was no way we could squeze such a huge overhaul into 3.0. That might also be a reason why not so many replies: we work hard on getting the stuff already marked as 3.0-material to work as they should. At least I am. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: half-idea for #ifdef and key deifnition hell...
On 23/03/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Thu, 23 Mar 2006, Jonathan Gordon wrote: im not entirely sure :p i was hopeing this msg would get more responses... When we discussed this at devcon, we decided there was no way we could squeze such a huge overhaul into 3.0. That might also be a reason why not so many replies: we work hard on getting the stuff already marked as 3.0-material to work as they should. At least I am. ah, alright. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: half-idea for #ifdef and key deifnition hell...
On Thu, 03/23/06 at 10:06:57 +1100, Jonathan Gordon wrote: On 23/03/06, Brandon Low [EMAIL PROTECTED] wrote: Great work! You just took some work off of Christi's plate toward cleaning up button definition hell. This is basically very closely along the lines of what we were talking about at devcon for button functions, and by moving the pre logic up to a higher level, we can reduce code size and improve clarity in the button switch loops. Some questions to ponder: What is our next step from here? im not entirely sure :p i was hopeing this msg would get more responses... im gonna implement the function today in 1 of my plugins that uses _pre on some targets and see how it goes.. I assume that this function will not have to exist within the event loop, so that it can be pulled back to a higher level to avoid code duplication? And also what Daniel said about working on other things that are 3.0 material currently (playback.c here I come). Are there some button definitions which are optional or nonsensical on some targets which should be made optional? Where can we implement the _PRE logic so that it doesn't have to be duplicated all over the place, and so that (on ipod) scroll touched events don't interfere with it's proper operation? im only worried about the scroll wheel events.. i dont have an ipod so it might be hard to test it out... but we'll see Scroll events may initially be handled just like other button events, I'm interested in creating (with Mikachu's help) an absolute positioning system for ipod 5g targets, but that doesn't _necessarily_ have to fit into the normal operation of buttons. Would be nice if it did though. Brandon Thanks much for looking into this, Brandon
Re: half-idea for #ifdef and key deifnition hell...
ok, well.. iv been playing with this idea anyway..
hmm.. looks like i put it in the wrong plugin :p this 1 doesnt use
_pre at all... anyway, here is the code iv got...
**
struct {
int button_code;
int ret_code;
bool needs_pre;
} ButtonItem;
int read_button(struct ButtonItem *items, int button_count, int timeout)
{
static int last_button = BUTTON_NONE;
int button = rb-button_get_w_tmo(timeout);
int i;
int ret;
if (button == BUTTON_NONE || button == SYS_USB_CONNECTED)
{
last_button = button;
return button;
}
ret = BUTTON_NONE; /* in case the button is not in the list */
for (i=0;ibutton_count;i++)
{
if (items[i].button_code == button)
{
if (items[i].needs_pre)
{
if ((items[i-1].button_code == last_button) ||
(items[i-1].button_code == BUTTON_NONE))
{ ret = items[i].ret_code; break; }
}
else if (!items[i].needs_pre)
{ ret = items[i].ret_code; break; }
}
}
last_button = button;
return ret;
}
*
now if some targets use a _pre for a button and some dont, ud define
the _pre to BUTTON_NONE on the targets its not used for, so it goes
through the list and will return the correct code regardless on
wheather or not _pre is used on a target (while still sayuing that
the button needs a _pre on at least on target).
wtahca think?
On 23/03/06, Brandon Low [EMAIL PROTECTED] wrote:
On Thu, 03/23/06 at 10:06:57 +1100, Jonathan Gordon wrote:
On 23/03/06, Brandon Low [EMAIL PROTECTED] wrote:
Great work! You just took some work off of Christi's plate toward
cleaning up button definition hell. This is basically very closely
along the lines of what we were talking about at devcon for button
functions, and by moving the pre logic up to a higher level, we can
reduce code size and improve clarity in the button switch loops.
Some questions to ponder:
What is our next step from here?
im not entirely sure :p i was hopeing this msg would get more responses...
im gonna implement the function today in 1 of my plugins that uses
_pre on some targets and see how it goes..
I assume that this function will not have to exist within the event
loop, so that it can be pulled back to a higher level to avoid code
duplication?
And also what Daniel said about working on other things that are 3.0
material currently (playback.c here I come).
Are there some button definitions which are optional or nonsensical on
some targets which should be made optional?
Where can we implement the _PRE logic so that it doesn't have to be
duplicated all over the place, and so that (on ipod) scroll touched
events don't interfere with it's proper operation?
im only worried about the scroll wheel events.. i dont have an ipod so
it might be hard to test it out... but we'll see
Scroll events may initially be handled just like other button events,
I'm interested in creating (with Mikachu's help) an absolute positioning
system for ipod 5g targets, but that doesn't _necessarily_ have to fit
into the normal operation of buttons. Would be nice if it did though.
Brandon
Thanks much for looking into this,
Brandon
