i would like to learn some more about the underlying runtime supporting BLE Smart applications -- the startup sequence, execution context, the tasking model, etc.... i realize this is a rather broad topic; but at least a general understanding will help me (and hopefully) others when developing/debugging their application code....
let's start with startup sequence -- and the APPLICATION_INIT function in particular.... from what i can tell, this is entered immediately after the basic C runtime has been established by spar_setup.c followed by sparinit.c.... and then from here, there is typically a single call to bleapp_set_cfg() which receives the application's "create" function; the latter is where the real use of the underlying libraries begins....
this then leads to a flurry of questions about the "execution context" at each of these points:
- when are hardware interrupts actually enabled???
- when does the watchdog timer become enabled; and how long is its interval???
- when should i initialize my own periperhal HW, ideally *before* interrupts start coming in???
- is the application "create" function executing within a special task context???
- what happens if the "create" function doesn't return -- either for a very long or forever???
- are functions enqueued by bleappevt_serialize() executed first-come, first-served???
- tell me more about bleappevt_serialize() -- it's return value and the return value of the scheduled fxn???
- are bleappevt_serialize() functions subject to the same constraints as "create"; do they run in the same context???
- can interrupt handlers interrupt other interrupt handlers; and can tasks preempt one another???
- the API has numerous callbacks -- from gatt attributes being ready to UART interrupts; what context do these execute in???
- do any of the callbacks actually execute in interrupt context; and if so, what is the interrupt latency???
- similarly, what is the latency from scheduling (my own) function via bleappevt_serialize()
- what are the various "real-time" constraints imposed by the BLE stack, which my app should respect???
so sorry for being so pedantic, but the application code we're trying to port onto the BCM92073x requires us to know this sort of information....