Placement and behaviour of bt_control_t->next_cmd

[GoogleCodeExporter]

as of r2352

The code in the hci.c sub-state-machine executes these commands before reading 
the BDADDR, local features, and buffer size.

I think it will be useful if these three items are read first, and then the 
user custom commands execute, because the user's commands might require these 
info

Also I think the return code of the next_cmd should be able to (optinally) 
signal the sub-state-machine to skip some steps, jump right to HCI_STATE_WORKING

For example, return 0 means no command and skip to HCI_STATE_WORKING, return 1 
means send packet and then call next_cmd again, return 2 means send packet and 
then run rest of default initialization procedure, return 3 means send packet 
and then skip to HCI_STATE_WORKING

This will allow me to add a lot of stuff to the initialization steps without 
modifying the state-machine switch-case.

Original issue reported on code.google.com by frank.zhao.main@gmail.com on 6 Feb 2014 at 6:38

[GoogleCodeExporter]

The current order is a result of supporting t he CC256x chipsets, where a large 
init script (10-60 kB) has to be sent to the Bluetooth module before it is 
usable.

I don't mind getting BDADDR, local Features, and buffer size before that, 
especially as these are read only commands (the init script might do module 
resets...).

What do you need to do for your setup in the custom commands?
Why would you want to skip right to HCI_STATE_WORKING?

Original comment by matthias.ringwald@gmail.com on 7 Feb 2014 at 4:44

• Changed state: Accepted

[GoogleCodeExporter]

I am replicating an initialization exactly as I've captured it from the device 
I'm reverse engineering.

If I implement my own sequence, I don't have to worry about you modifying your 
sequence in a later update.

I don't really have to follow my captured sequence of events, but I'd like to, 
just in case something goes wrong. It's better to start with something already 
known to work. Plus I don't need to worry about redundant commands that hog 
precious boot time.

It's just a suggestion. Not really important but it feels like people might 
find it useful. I've already hacked this feature into my copy of your code.

Original comment by frank.zhao.main@gmail.com on 7 Feb 2014 at 6:35