-
Notifications
You must be signed in to change notification settings - Fork 3
Baloo wip
This page is currently under construction. At this stage, the information included here has no guarantee of being complete nor correct.
- Restructuring of /arch/
- Modify schedule.n_slots
- Documentation!
- Flexible logging
- Debugging and testing
- Extend the minimal GMW state machine
- Extend the noise detection feature
- Add the round-repeat example back in
- Starvation protection
-
channel_hopping_mode - Compile-time check for invalid GMW settings
- Enhancement of the Static feature
- Round start and end time
- Reduce node ID to one Byte
- Dynamically changing the host
- cpu/cc430 should be a subfolder of cpu/msp430
- relocate the gmw-platform.c files in platform//dev
This was done by Reto at some point, but got lost due to merging problems.
It would be good to modify the definition of schedule.n_slots with the specific bit placeholders for the flags. Reason: it is annoying that setting n_slots overwrites the flags!
All the main features of the Baloo should be properly documented... That includes how to use enable them (correct set of defines) and how to use them (what to you have to do in the callbacks).
Note In principle, we have everything we need from the structural PoV: a stat structure, which is filled by the middleware and can be accessed by the application layer.
The problem is that this structure must be rich enough to provide all information that may possibly be wanted at the application layer... That's a bit hard to predict :-/
We need to figure out a way to let the system designer defining specific debug variables (which would typically be called by the debug print process. The problem is that the logging would typically be done at the middleware level, which we do not want the system designer to touch. Could we do something like a user-defined function for logging? This would be called by the middleware, with an effect that can be defined by the user (ie. what should be logged). Then, the log itself can be set defined by the user and be further used in the debug process.
We need to provide some efficient way of debugging testing implementation on the middleware. The ideal scenario would be to have a workable simulator for that (see possibility on Cooja for TelosB motes, and Renode for CC2538-based motes)
Right now, the on_control_post() is not executed when a non-valid control packet is being received; nodes directly go back to bootstrap. It would be nice to extend this so that the callback is always executed. This would mean adding a new sync_event (e.g. GMW_EVT_CONTROL_INVALID), which would by default transition to the Bootstrapping state.
Extend the noise detection to be compatible with multiple primitives (demands to adapt the gmw_communication_active() function)
At the moment, callbacks cannot be interrupted (e.g., in case they overrun). If we want to let the user do this (as an advanced feature), the gmw.c needs to be modified (e.g. include the callback execution in an independent process).
If and when we have primitives that support both channel-hopping and non-channel hopping modes, implement the channel_hopping_mode API in th config section.
To be more user-friendly, it would be good to have as many compile-time checks as possible to flag invalid configuration settings (e.g. a wrong RF channel being used, etc.).
Consider modifying the static feature such that if one call gmw_set_new_control(), the middleware layer copies the control from the app also on the source nodes (if the static feature is being used).
It is important to clarify (and document) what is considered as being the 'start time of a round' and the 'end time of a round'.
- round start time: before the pre-process. The preprocess is where the host prepare the new schedule and all CPs read out message to send in from the Bolt queue.
- round end time: just before we yield the GMW process (before the post-process start executing). Needs some minor modif in gmw.c
The middleware currently contains both t_start and start_of_next_round. This is yet unclear why we have the two. This should be changed, or at least clearly explained in the code and the documentation.
Ideally, it should be possible to make the a Baloo project from the top-level directory. Select the platform, board, project, and go.
Maybe double-check first if that's compatible with the Contiki-ng build... It shouldn't be a problem when we want to merge the two later.
Possibly, a define could be used in case we need more than 255 unique node IDs. If unset, node IDs are encoded using one Byte only, which would reduce the schedule size significantly.
This needs to be thought through: it will maybe require to pause and resume the execution of the middleware. Plus, the HOST_ID needs to become a variable.