Baloo pre post processes

Objective

Describe the use and configuration of Baloo's pre- and post-processes.

Typical usage of the pre- and post-processes

Baloo's pre- and post-processes serve to implement the NET layer protocol logic which does not "belong" in the different callback functions.

• The pre-process can be used to implement operations that should execute shortly before communication; for example, reading sensor values about to be collected.
• The post-process is typically used for more time-consuming operations (e.g., state-keeping, computations, logging, etc.). In most of Baloo's examples, the main application process (called app_process - see Baloo's program flow) is used as post-process.

Configuration

Contiki is an event-based cooperative multi-threaded operating system which uses the concept of processes. To trigger the execution of a process, the user can poll this process, resulting in its execution once the currently executing process yields (read more on Contiki processes here).

Baloo's program flow revolves around the middleware protothread, which organizes the communication rounds. The middleware allows the user to poll processes to execute before and after each round, as illustrated below. They are referred to as pre-process and post-process respectively.

The user defines the processes to poll by passing them as arguments of the gmw_start() function, which is called during Baloo's initialization (see Baloo's program flow).

void gmw_start( struct process*         pre_gmw_proc,
                struct process*         post_gmw_proc,
                gmw_protocol_impl_t*    host_protocol_impl,
                gmw_protocol_impl_t*    src_protocol_impl);

In addition to the process pointers, the middleware requires some information on the (expected) execution time of these processes. This is controlled by two configuration parameters:

• GMW_CONF_T_PREPROCESS (in ms)
  The middleware must know how much in advance (i.e., before the round) it should poll the pre-process. In turn, the pre-process should execute and yield before GMW_CONF_T_PREPROCESS milliseconds have elapsed; otherwise, the pre-process execution is interrupted by the middleware, such that the communication round can start as scheduled.
  Setting this parameter is compulsory whenever a pre-process is used.
• GMW_CONF_T_POSTPROCESS_MIN (in ms)
  The post-process is polled at the end of a round. Thus, it is not necessary to know how long the process is expected to run to know when to poll it; simply polls when the round is finished. The maximal execution time of the post-process is however limited by the available time between two rounds. If desired, the user can use the GMW_CONF_T_POSTPROCESS_MIN macro to set a minimal amount of time that should be left for the execution of the post-process. This may be useful for example when the number of slots in a communication round may vary (see Baloo's slot repeat feature).
  Setting this parameter is optional. It is set to 0 by default.

Finally, the middleware allows the user to update the processes to poll after initialization by using the on_round_finished() callback.

The execution and timing of the Baloo's pre- and post-processes depend on the middleware state (see the state-machine description).
In the Suspended state, the post-process is polled immediately after the control slot.
In the Bootstrapping state, the pre-process is never polled by the middleware. By definition, in this state, a node is not synchronized, so one does not know when "before the round" actually is.

---

Next > Baloo - Time management