OpenTag

OpenTag implements DASH7 Mode 2, which specifies a monolithic system encompassing OSI layers one through six, part of layer seven, as well as the application layer. OpenTag is designed to be light and compact, as it is targeted to run on resource-constrained micro-controllers. As a monolithic system, it does not implement different layers of the OSI model in a way that will enable them to be deployed on systems that differ from the typical, and nearly universal, MCU+RF transceiver architecture, utilized by WSN and M2M nodes.[1] However, the OpenTag RTOS employs an exokernel architecture (as of version 0.4), so a monolithic kernel is not required. Applications developed for OpenTag may safely reference the library or directly access the hardware, as befits the exokernel design model.

• It has a lightweight pre-emptive multitasking exokernel RTOS.
• Most kernels use fixed priority tasks.
• It contains a complete DASH7 Mode 2 protocol stack, including
  • Remote wake up;
    • Native query protocol; and
    • UDP & SCTP adaptation layers.
• It uses a Wear-leveling, Flash-based lightweight filesystem (Veelite).
• It has an internal C-based API.
• It has an external NDEF-based messaging API for client-server interaction.

OpenTag implements a multitasking real-time kernel designed specifically to implement DASH7. User tasks can be managed by the kernel, and they can preempt the kernel, although they must be allocated at compile-time. The scheduling frequency, or kernel resolution, is implementation-dependent, but it must be at least 1024 Hz and it must be an integer multiple of 1024 Hz.[2]

Kernel events use callbacks to invoke custom application code, which are called "applets". Extensive templating is used to provide callback functionality that is efficient for embedded environments. Thus callbacks in OpenTag may be dynamic (assigned during runtime), or they may be static, which requires assignment at compile-time but reduces overhead. As OpenTag implements an exokernel, user tasks may either be managed entirely by the kernel, they may be managed partly by the kernel and partly by external events, or they may be managed entirely by external events. Communication between tasks and the kernel is accomplished through an API of system calls and a message pipe interface.[3]

OpenTag's external API uses a simplified client-server model[4] and NDEF for data wrapping. The NDEF wrapper is particularly used for wireline communication between client and server, where the client is typically a human-interface device and the server is the OpenTag SoC. The internal API is exposed in a 1:1 manner with the external API, permitting the client to act much like an external process of the OpenTag kernel.

At the time of writing, most OpenTag hardware is implemented on the Texas Instruments CC430 or MSP430 devices, which are endorsed for use with OpenTag.[5] Current OpenTag source trees support many other MCUs and RF transceivers, however, such as various types of STM32, CC11xx, and Semtech SX12xx components.[6]