About SMX® v5



See the smx datasheet and smx Special Features for a summary of the features that make smx unique versus other kernels.


v5.2.0

SecureSMX adds tokens to limit object access and runtime limiting. Safe LSRs have been added that each have their own stack and MPA. All LSRs now have a control block to support this, and it makes EVB logging automatic. RTOS porting layers were added to help FreeRTOS and ThreadX users migrate to SecureSMX.

Task callback functions replace hooked routines, to allow not only entry and exit, but also start, stop, init, and delete cases. Task timeouts now have tick granularity, and a default value is specified for each call that waits, to avoid INF timeouts. The OS porting layer has been removed from smxBase and all middleware. Various small changes have been made.

v5.1.0

SecureSMX is our next generation, secure RTOS for Cortex-M based systems using the Memory Protection Unit (MPU).

Partition Portals

Portals are a new method developed to isolate partitions better, and SMX middleware was modified to use it instead of the original approach used in v5.0.0. Portals use a message-based calling mechanism to permit client tasks to call server functions without having access to any regions in the server. For example, smxFS file system calls are made without having any smxFS code or data accessible to the client. This is a very strong method of isolation, and adds only a small amount of overhead. Tunnel portals support large data block transfer, while free message portals are simpler and offer more flexibility.

v8M

Cortex-v8M MPU support has been added, and many refinements have been made for v7M as well.

See www.smxrtos.com/securesmx for full information.

v5.0.0

Security

v5 is all about security. Cortex-M Memory Protection Unit (MPU) support has been greatly extended and improved, and a detailed manual has been written to show how to partition the application and all of the related concerns (available under NDA). SMX middleware was partitioned to run in unprivileged mode, while the smx kernel runs in privileged mode. The set of system services available and what some can do is limited in unprivileged mode. Task relationships further restrict unprivileged operation. smxAware was extended to show MPU details for the current state and every task, in a much more helpful way than the debugger shows. eheap was extended to support multiple heaps, and each middleware module now uses its own isolated heap. Protected blocks and messages can be created from unprivileged mode, and the latter with dynamic region creation are used for secure messaging between tasks. Task stacks are individually protected. A considerable amount of time and effort has been invested, which lays the foundation for interesting features to come. More information.


v4.4.0

Memory Protection Unit (MPU)

Cortex-M MPU support has been added. The Cortex-M v7 MPU is difficult to use and has significant limitations. The primary goal of MPU-Plus is to make using the MPU as easy as possible, while offering as much protection as possible. A key idea of our approach is to allow progressively increasing the security of a system. See www.smxrtos.com/mpu for full information.


v4.3.2

Heap

A few heap issues have been fixed and improved: Automatic chunk merge has been fixed to avoid downward bin leakage due to chunk splitting. smx_HeapBinSort() has been fixed and improved to reduce sort times. smx_HeapManager() was added to main.c and is called by the Idle task to handle auto merge control and heap and bin scanning and fixing.


v4.3.1

Heap

The heap has been greatly improved and now has comparable performance to dlmalloc and potentially greater performance when customized to specific embedded system requirements. In addition, fast large bin sorting during idle has been added and improvements have been made to debug support and self-healing. In the latter case, heap scanning has been simplified and heap bin scanning has been added. This heap, under the name "eheap" is being made available for free in source code form for non-commercial use in order to facilitate testing it in actual systems and experimentation.


v4.3.0

Heap

The heap has been replaced with our new bin heap for fast allocations vs. the linear heaps typically implemented by RTOSs. Its structure is similar to that used in GPOSs, such as Linux, but it has been designed to fit the requirements of embedded systems. It works with small to large amounts of RAM and offers high performance, deterministic behavior, small code size, ruggedness, and strong debug support. It is intended to provide very high performance for object-oriented languages such as C++ and Java, as well as for other intensive heap applications. It provides the standard heap services malloc(), calloc(), realloc(), free(), and init(), and it has various services to monitor the heap and optimize its behavior, such as to control bin population. It is self-healing and does scanning and fixing automatically during idle time. It also has a special HCB type that can be used for allocations to aid in debugging.

The heap has 3 main regions: small bins, upper bins, and top bin. For blocks in the small bins, it offers nearly the same performance as a block pool. Allocations from the upper bins use a binary search that is nearly as fast and deterministic. The top bin is for large allocations. Bin configuration is easily tuned to suit the application.

Timers

Timers have been enhanced with new operations, such as duplicate, reset, and start from an absolute time. A pulse timer is a new type that has been added to allow generating pulses like hardware timers and can be used in place of them for relaxed timing requirements. A new smx service, smx_TimerSetPulse() permits converting a cyclic timer to a pulse timer and is then used to control its pulse width and period simultaneously. This permits easily implementing pulse-width modulation (PWM), pulse-period modulation (PPM), and frequency modulation (FM).

Power Saving

smx_SysPowerDown(sleep_mode) was added to provide a power-down framework, at the RTOS level. It is called from the idle task when there is no useful work to do. It in turn calls sb_PowerDown(sleep_mode), which does the actual power down process and time recording. This is hardware and application dependent and thus must be user-implemented. When power is restored, control returns to the sb function, which must initialize the tick counter and return ticks lost to smx_SysPowerDown(), which then performs tick recovery. This process handles events which timed out during the power-off period in an efficient manner that preserves the proper order of timed events. Execution time for tick recovery is dependent upon the number of events that timed-out, not upon the number of ticks lost .

Other Improvements

Error management reports timeout as an error, and the TCB.err field was changed to indicate the result of the last smx service: OK, timeout, or error type. This makes it easier to determine the proper action at the point of call.

smx_QueueClear() has been replaced with specific clears for event groups, event queues, message exchanges, mutexes, pipes, and semaphores. This provides a more intuitive API, and each clear service is able to do a more complete job.

FPU register autosave has been implemented for the Cortex-M4 and Cortex-M7. This has also been retrofitted into v4.2.1.


v4.2.1

smx v4.2.1 is a minor release to fix and improve a few things. The block pool API changed slightly. More examples from the smx User's Guide were implemented in ESMX and corrected in the manual.

Free SMX Learning Kits were released for learning and experimental use.


v4.2.0

smx v4.2 adds significant new kernel features and improvements to existing code for size, performance, and reliability. These are summarized below.

Exchange Messaging has been extended to support broadcasting and multicasting. Multicasting is supported by proxy messages, which can be used for distributed message assembly. These capabilities are unique to smx. Resource exchanges have been eliminated; new messages are obtained from smx block pools like smx blocks, except they are mated with MCBs. (In fact, they can be obtained from the same pools as smx blocks.) smx_MsgMake() permits making messages from any source. This leads to the concept of "message migration". The idea is that an input ISR obtains a block from a base pool, fills it, and passes it to an LSR. The LSR makes it into a message and sends it to an exchange. From there it can be passed from task to task via exchanges. The final task calls smx_MsgRel() and the data block and the MCB are put back where they belong. The final task need not know where the data block came from. This is a no-copy operation from start to finish. Output works inversely. This is a ground-breaking concept, unique to smx.

Block Pools have also been extensively improved. smx raw blocks were replaced with smxBase blocks. Getting and releasing base blocks is interrupt-safe and thus amenable to being used from ISRs. smx block pools are based on base block pools but offer more safety and flexibility, e.g. the API is task-safe. Similarly to smx messages, smx blocks can be made from anything (base block, static block, heap block, etc.) using smx_BlockMake().

Event Groups have been completely redesigned. Slots have been eliminated to simplify usage. Pre-clear and post-clear masks have been added. The former permit dealing reliably with modes and the latter permit both modes and flags. Modes (mutually exclusive flags) are not auto cleared; flags can be auto cleared. In addition, testing for AND/OR combinations has been added, which is unique to smx.

Semaphores have been completely redesigned. Previously, the smx counting semaphore was used for different purposes. Now, there are 6 types of semaphores, each explicitly designed for a particular use:  Event (binary and multiple), Resource (binary and multiple), Threshold, and Gate. They introduce new concepts for semaphore usage.

Multi-Level Queues, except rq, have been replaced with priority or FIFO queues, as appropriate. This not only simplifies usage, but also ensures operations are done according to priority, as expected. Multi-level queues were designed for efficiency, but if the user didn't use them (and instead used a single-level queue), tasks and messages would be handled in FIFO order not priority order. These queues are typically small, so it was decided that search time is less of a concern than ease of use and expected operation.

One-Shot Tasks are now easier to use effectively. Stop calls were changed to stop the task in all cases, which simplifies use. They have been documented more clearly and completely in the smx User's Guide, and many good examples of using them have been peppered throughout. One-shot tasks offer significant RAM savings because they share stacks, and in many places their use is more logical than standard tasks.

Manuals have been substantially rewritten, particularly the smx User's Guide. Obsolete material has been replaced with accurate, detailed information on how to use smx effectively. Many new examples have been created.

General

Code size was reduced by about 40%, despite the increased functionality and the fact that smx was already efficiently implemented. This was achieved by sharing code by similar SSRs as much as possible, particularly in the suspend and stop versions of calls; by changing many macros to functions; and by making other similar changes after carefully studying the code. Sharing common subroutines is also safer since changes only need to be made in one place. Control block pools are now implemented with base pools, which resulted in further code simplification.

While implementing new features and streamlining existing code, significant low-level study and experimentation were done, including analyzing disassembly and testing performance while experimenting with details such as control block sizes and field sizes.

x86 code has been fully removed from smx and smxBase, significantly simplifying some files. x86 is where smx started almost 30 years ago and was the only architecture it supported for nearly a decade. Over many years, a great deal of energy was expended supporting this architecture.


v4.1.1

smx++

While updating smx++ to v4.1, it was simplified and improved (more info).
smx is one of the few kernels that also offer a C++ API.


v4.1.0

smx v4.1 represents a major step forward in simplifying smx, making it more user-friendly, and adding new features that will make your job easier. These are summarized below.


System Stack

All versions of smx now use the system stack for ISRs, LSRs, the scheduler, and error handling. This significantly reduces RAM usage since it is no longer necessary to increase each task's stack size to accommodate the worst case stack usage of nested ISRs and LSRs. Now task stacks can be sized for just the task's needs. This is especially important because we advocate designing your application to use many tasks.

In addition to RAM savings, this improves reliability, since changes to ISRs and LSRs that cause increased stack usage do not require adjusting task stack sizes. Also, stack usage during error handling is something one might not account for in sizing stacks, so running that code on the system stack could avoid a run-time failure due to an error. smxAware shows system stack usage in its task stack usage displays.

(Note that ARM-M (Cortex-M) versions have always had a system stack which was used for ISRs, LSRs, and the scheduler, because it is inherent in the architecture.)


Scheduler Ehancements

Implementing the system stack has required significant changes to the scheduler, including addition of the pre-scheduler. It improves efficiency by bypassing the task scheduler in cases where the sched flag indicates a reschedule might be necessary, but ct remains the top task.

Shared stack handling has been improved, in the case where a stack is unavailable at the time of task dispatch. Now if a stack is unavailable because it needs to be scanned, the scheduler bumps the idle task up to do (or complete) a stack scan, then proceeds to dispatch the task. Higher priority tasks that become ready will preempt this operation.

We expect these to be the last changes to the scheduler for the foreseeable future. As in v4.0.1, a single configuration option will restore the previous scheduler and associated sections of code, if a problem with it is suspected. This code will be removed in v4.2.


Event Buffer

The event buffer is used by smxAware to display graphical timelines showing how the system is running. The macros and functions used to add records to the event buffer during execution appear frequently in the code, so they have been streamlined to make them as efficient as possible. Part of this was creating additional versions of macros to store fewer parameters. Previously the record size was fixed; now it is variable. This allows storing all parameters of SSRs. New user macros were added to store from 0 to 6 values of interest in the application. Having variable-sized records makes it possible to store more records in a given amount of RAM. In a typical sample, we observed a density increase of 34%.

In addition, since SSRs are called frequently, we implemented a means to control which are logged, to avoid wasted records and time. Each can be assigned to 1 of 8 SSR groups, and a flag variable allows controlling which groups are logged. Group assignment is done statically, but selection of which to log can be adjusted for the current debug session using checkboxes in smxAware.


Protosystem Simplification

The Protosystem is the foundation for application development, so minimizing complexity benefits the application and helps users get a quick start. Several files were moved into the smx library, and files that remain have been simplified, particularly main.c. This makes it easier for new users to see how to build their application upon the Protosystem, and it improves the readability of the code for all users.

The number of (required) system tasks has been reduced to one: the idle task. Previously there were tasks for handling timeouts, profiling, stack scanning, and exit. Now all are handled by idle or LSRs. This gives significant RAM savings for those stacks and TCBs, which is important for minimal RAM systems.


Precise Timeouts

All smx services that wait have a parameter to specify a timeout, in ticks, when the operation will abort. In previous versions, the true accuracy of the timeout depended upon how often the timeout task ran (a configuration setting). To minimize overhead, this was typically set to multiple ticks (e.g. 10). The original purpose for timeouts was to be a safeguard to catch error conditions when a task waited much longer than reasonable. However, we found users were expecting tick accuracy, so we greatly improved the efficiency of timeout handling, and we made it an LSR to avoid task switching overhead. Now timeouts are tick-accurate and efficient.


Precise Time Measurement

API functions are provided to do precise time measurement of short sections of code (less than 1 tick), accurate to the input clock of the tick timer. Some places in the smx code are instrumented, such as the scheduler, and more will be added over time.


Precise Profiling

Previously, smx offered only coarse profiling, which showed %busy, %overhead, and %idle. Now it has task profiling that is accurate to a tick counter timer clock, which is typically one to several instruction clocks. Each task has a run time count field in its TCB, which accumulates incremental counts when the task runs. There are also run time counts for ISRs and LSRs. (ISR count is the total for all ISRs, and likewise for LSRs.) Remaining counts are attributed to overhead. All counters are cleared at the start of a profile frame and transferred to the run time count array, where they overwrite the oldest column. The profile frame is one second, by default, but it can be changed to any number of ticks. Profiling uses an LSR instead of a task.

The profiling information is displayed graphically and in tabular form in smxAware. The coarse profiling data is still displayed on the terminal (if present), but now it is calculated using the precise profiling data.


Error Manager

There is now a single error handler rather than individual error service routines. This eliminates the error jump table and generally simplifies the error manager. Also, error reporting to the terminal is now done through new console output routines that enqueue messages rather than sending them directly to the UART. When using a polled UART driver, the old way could cause long delays at critical times. This was a main motivation for creating the improved message output functions (see below). Other minor improvements were made, such as shortening error strings to save flash.


Message Output to Console

The smx kernel and middleware output error, warning, and status messages as appropriate for the debug level selected for each. These are very useful for diagnosing run-time problems. Previously, they relied on console output functions that directly wrote to the UART, which is a polled driver in many BSPs. This introduced long delays into operations, and could cause unbounded priority inversions. Even though diagnostic message output is used primarily during debug, we decided that these problems needed to be fixed.

The new console output functions are de-coupled from the UART. Fixed messages (in ROM) are output through the output message queue (OMQ), and variable messages (in RAM) are output through the output message buffer (OMB). A display function is called from the idle task (and can be called from other low priority tasks) to output messages that have accumulated. The OMQ has only pointers to messages, so this saves time and RAM for displaying them, so on limited RAM systems, it is preferrable to use fixed messages. The OMB is a ring buffer into which messages are copied, requiring a little more time and more RAM to hold the messages, but is essential for printing messages that vary, such as values read from peripheral registers, etc. Since buffer overflow can occur at a high debug level, configuration options are provided to control which facilities are available, and even to allow re-coupling to the UART in cases where it is necessary to avoid losing messages.


Stack Overflow Handling

More sophisticated handling has been added for stack overflow. If the scheduler is about to suspend a task, but the stack pointer has encroached into the Register Save Area (RSA) (which is "above" the stack), the context cannot be saved because it would overwrite the top elements of the stack, so the task is restarted. If the stack has actually overflowed above the RSA, the application is exited, to limit system damage. (These behaviors can be modified by altering the error manager. Also note that during development pads are typically used to prevent overflow from going outside the stack block, and by release, stacks should have been tuned to sufficient sizes based upon stack high water marks.)


SDAR and ADAR

DAR functions have been added to smxBase, and smx has been modified to use them. SDAR was created for smx system objects, and ADAR is primarily for application objects. They are allocated in separate sections and can be easily located separately for performance and safety. SDAR holds smx control blocks, ready queue, LSR queue, and error buffer, and it is small so it can be located in internal SRAM on most processors, for speed. The heap, stack pool, and event buffer are located from ADAR, which would be typically put into external SDRAM, if available. Otherwise, both are located in internal SRAM. The user can easily change their location in the linker command file. The separation of smx objects from application objects is a step in the direction of MPU or MMU protection.


smxAware

A Memory display was added to show a summary of smx RAM usage. Graphical bars indicate usage of heap, stacks, SDAR, ADAR, LSR queue, and each type of control block. For heap and LSR queue displays, the high water mark is indicated by a thin line past the end of the bar and a numeric value. The Profile display was replaced with one that shows the new smx profiling data graphically and in tabular form. The graphical display shows bars for each task, all ISRs, and all LSRs. The user can step forward and backward through the frames. The first display shows the average of all frames. SSR filtering has been added for SSR groups (see Event Buffer above). See the smxAware datasheet for details and for information about its other features. smxAware continues to be included with smx at no additional cost, to aid users in developing smx applications.


Other Improvements

• The tick timer is used for event buffer timestamps, precise profiling, time measurement, and polled delays, in addition to its main use to generate the smx tick. This means even with all these timing-related features, smx still uses only one hardware timer, leaving the rest for application use.
• app and smx config files have been compacted and simplified by moving descriptions of settings out to SMX Quick Start (Configuration section).
• Task state field was added to the TCB. Application code can check it, and it can be viewed in the debugger watch window. (smxAware has always displayed it, but a bit of code was required to determine it.)
• cbtype, state, and errno were made enums for debugger display of names rather than numbers.
• smx internal macros in xsmx.h were simplified and their number was reduced. As part of this, exits in SSR code were made explicit, not hidden in condition test macros.
• Several small improvements were made to the BSPs. One was to modify sb_DelayUsec() to use the tick timer counter rather than a dummy loop, which was highly inaccurate. Another was to create term.c in each BSP, a simple file to replace crt.c and kbd.c that were shared by many BSPs and had many conditional checks.
• Prefixes were added to a few more names for consistency and to avoid name conflicts.
• smxSim (Win32) code was removed to reduce clutter. smxSim has been discontinued.

• Adding new, powerful features.
• Enhancing Safey, Security, and Reliability (SS&R) features.
• Power management.
• Adding performance enhancements such as multicore support.
• Continuing to simplify and make smx easier to use.