The

 handles low-level API formatting, but you need to supply some functions in order to support the specifics of your platform. The necessary functions are declared in the following header files:

• dn_uart.h: these functions allow the

   to send bytes over the serial port, and receive bytes from the serial port. A "flush" function is provided in case the serial (UART) driver of your platform is buffer-oriented rather than byte-oriented, e.g. if the serial port is driven through a DMA module.  The

   doesn't handle flow control - the mote doesn't need incoming flow control (the UART_RX_CTSn and UART_RX_RTSn lines) when your microcontroller is sending .  You will need to monitor UART_TX_RTSn and assert/de-assert UART_TX_CTSn as part of your application if your microcontroller cannot wake on data. 

• dn_lock.h: these functions allow the

   to operate in a multi-threaded environment. If this is the case in your system, your implementation of these functions would typically consist is pending/posting a mutual exclusion semaphore (mutex). You can use stub functions (i.e. empty functions) if the

   does not operate in a multi-threaded environment.

• dn_endianness.h: these functions are used to match multi-byte API fields (which are big-endian) to the endianness of your platform. While the SmartMesh mote is a little-endian processor, all communications is done in network (big endian) order, so if you have a little-endian processor you need the byte-swap functions found in dn_endianness.c in the examples.

You may also need platform specific code to handle timers - these are not abstracted as with the other functions. Generally they fall into two categories: Software and hardware timers.

• In the Arduino Due example, a software timer is used.

• In the MSP430FR4133 LaunchPad example, a hardware timer is used.