Baloo porting

Porting Baloo to a new platorm

---

This page is currently under construction. At this stage, the information included here has no guarantee of being complete nor correct.

---

The interface of gmw-platform.h contains two functions that need to be implemented for each platform:

void gmw_platform_init(void) is called in gmw_start() and contains platforms specific initialisation not handled directly by Contiki, see arch/cpu/msp430/gmw-platform.c for an example.

void gmw_platform_set_maximum_packet_length(uint8_t length) is called by the middleware to notify the radio to expect different packet lengths (control packets vs data packets). The length variable is the length of the packet in bytes. If the radio does not support a maximum packet length, it can be left empty, and GMW will work as long as the radio is able to handle the biggest packet sent by the middleware.

The middleware also requires two timer typedefs:

• gmw_rtimer_clock_t is the timestamp type used by GMW and the underlying Glossy implementation
• gmw_rtimer_t is the struct used as argument type for the host and source thread of the middleware, needs to have a 'time' field with the current timestamp

Then, gmw-platform-conf.h contains macros used by the middleware to call glossy and rtimer functions. The defaults used in gmw-platform-conf.h are DPP functions, however they can be overwritten, see gmw-conf-sky.h in examples/gmw-test-sky.

The most important defines are:

GMW_GLOSSY_START(initiator_id, payload, payload_len, n_tx_max, sync, rf_cal) Should point to the glossy_start() function, its parameters are: initiator_id node_id if initiator, GMW_GLOSSY_UNKNOWN_INITIATOR otherwise payload pointer to the payload buffer payload_len size of the payload in bytes n_tx_max number of retransmissions sync GMW_GLOSSY_WITH_SYNC or GMW_GLOSSY_WITHOUT_SYNC, depending on whether or not the middleware needs an updated t_ref rf_cal GMW_GLOSSY_WITH_RF_CAL or GMW_GLOSSY_WITHOUT_RF_CAL, allows the middleware to calibrate the radio for certain floods

GMW_GLOSSY_GET_T_REF() should return the t_ref generated by the last Glossy flood with sync enabled, with type gmw_rtimer_clock_t.

GMW_GLOSSY_UNKNOWN_INITIATOR Is the initiator_id used for Glossy floods where the current node is not the initiator. GMW_GLOSSY_UNKNOWN_PAYLOAD_LEN Is the payload_len used for Glossy floods where the current node is not the initiator. GMW_GLOSSY_WITH_RF_CAL Is the rf_cal used if the radio should be calibrated (if supported by the platform). GMW_GLOSSY_WITHOUT_RF_CAL Is the rf_cal used if radio calibration is not necessary. GMW_GLOSSY_WITH_SYNC Is used for Glossy floods where t_ref is updated. GMW_GLOSSY_WITHOUT_SYNC Is used for Glossy floods where t_ref is not updated.

GMW_RTIMER_SCHEDULE_HF(time, callback_func) should schedule a callback at time 'time' for function 'callback_func' using the high frequency timer.

GMW_RTIMER_NOW_HF() should return the current timestamp of the high frequency timer (type gmw_rtimer_clock_t).

GMW_RTIMER_NOW(hf, lf) should set the current timestamps of both the low and high frequency timer (type gmw_rtimer_clock_t).

The other macros should be self-explanatory.

The rtimer implementation of the platform has to be able to provide the following:

• a high frequency (HF) timer with enough accuracy to schedule slots during a round (20-100us, maybe even more if guard & gap time are adjusted accordingly), can also be used stand alone (without the LF timer).
• a low frequency (LF) timer used that can be used to schedule rounds even when the device is in a low power mode.
• support long periods (up to the maximum round period or longer, e.g. by using a software extension counting timer overruns).

An example implementation for such a rtimer is shown in arch/cpu/cc430/rtimer-ext.c and arch/cpu/msp430/rtimer-ext.c respectively.