Your In most OCSDK sample applications, the local module terminates all events that the stack generates. This hides the series of event notifications that are happening (e.g. as the mote joins). Instead, the module can post semaphores when the mote is joined and/or has a service, simplifying your code.
Sometimes you may want to process specific events, so your application can register callback functions to handle a number of eventsthem:
- Packets received from the network
- Timer expired - Generated when an OS timer you created expires
- Time Notification - Contains the timestamp associated with a TIMEn trigger
- Event notification - Note that if you register an Event callback, the local module cannot join for you since your application consumes the boot event.
- Advertisement received in Search mode (new in OCSDK 1.2.0)
- TxDone notification (new
...
- notification (new in OCSDK 1.2.0) - tells your app that the packet with a given sequence number has been sent
Callback functions are not ISRs, but they have some things in common with ISRs. In general, a callback function executes at higher priority than your application's tasks, so the following rules of thumb apply:
- Keep the code in the callback to a minimum
- Post a semaphore to an application task to process the event instead of handling it directly in the callback
- Use globals to pass variables - don't use static variables in a callback
- Don't use the critical section macros from uCOS-II
- Other important shit
They differ from ISRs in that:
- Interrupts cannot be suspended in a callback
- etcetera, etcetera, etcetera