OpenTag 0.4 will be the last 0.x version before 1.0. It is also a big improvement over all past versions, because it is the first version with a real RTOS, a task-driven native API, and a way to cleanly integrate other low-level libraries (e.g. Energia/Arduino). I will describe a few of these new features.
There are three intrinsic I/O drivers for OpenTag: Flash/Filesystem, MPipe, and Radio. The FS driver has not changed much, but the MPipe and Radio drivers have been developed into fully pre-emptive exotasks (more on exotasks later). They are more responsive, more efficient, and more fault-tolerant than ever before. Additionally, there are some intrinsic kernel support drivers: the kernel timer, RTC, true random number generator, and some others. Notably, the RTC scheduler and TRNG are now implemented and working. The kernel timer now has zero software latency, so events and tasks that occur repetitively will not slip.
OpenTag now implements an exokernel for multitasking management. Aside from being an incredibly cool-sounding word, an exokernel is an OS concept that allows application code running on the device to use the built-in libraries and abstraction layers, or not.
Specifically, the OpenTag kernel is less important than the OpenTag tasking libraries are (logging, wireless session control, etc). These are what provide the abstractions to DASH7 communication and other features. You can actually use different kernels to optimize performance on different platforms, or for different sorts of product requirements. The standard kernel is optimized for low power, low latency (i.e. real-time), and low resource usage. It uses co-operative multitasking for processing-oriented tasks and pre-emptive multitasking for I/O oriented tasks (these are called exotasks).
The 0.3 and 0.2 APIs are difficult to use and not especially fault tolerant. 0.4 now includes true, task-driven APIs for communicating over DASH7 or MPipe (MPipe is an NDEF-based wireline control interface). Because they are task-driven, you can call the API functions anytime in your application, and the kernel will execute them as soon as the required resources are available. Moreover, the kernel can manage task timeouts for fault tolerance.
Applets are functional routines that perform some part of an application, and they are an important part of OpenTag 0.4. Small devices like MSP430s don’t have the resources to do interprocess communicating, so instead of binding messages to a task queue, we bind applets. For example, I can write a task that is activated pre-emptively by a button press, creates a DASH7 communication session, and binds an applet to the new session. Every time OpenTag accesses the session, the applet runs, and the applet can decide to continue or discontinue the session based on its application-layer logic. Applets are also used for various other system callbacks.
When an exotask is not enough, it is possible to implement a fully preemptive exothread, which operates in a separate context as the rest of the system but still can be administered by the kernel. The first exothread example I will be developing is a fully transparent Energia environment that runs alongside OpenTag.
Still the Lightest
Right now I’m alpha testing OpenTag 0.4, and I’m posting the updates on my GitHub experimental branch (for the CC430 it’s actually in a workable Beta state). Despite all of the extra power and features, the ROM footprint is only 1-2% bigger than before. RAM use is basically the same, too. Comparing compiled code vs. compiled code on an embedded MCU, smaller code size equates to faster, more efficient code. These attributes allow batteries to be smaller, chips to be smaller, and the total product to be cheaper.