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.

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?

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.