SMX RTOS V 4.1 verfügbar

Micro Digital Inc kündigte heute die Verfügbarkeit des SMX RTOS Paketes in der Version 4.1 an.

Der SMX Eval Kits für viel MCUs und Boards sind hier online verfügbar.

Ganz unten auf dieser Seite finden Sie das Datenblatt als pdf-Downlaod.

Über Micro Digital

Micro Digital, Inc. ist seit über 30 Jahren im Embedded System Software Geschäft tätig und verkauft Software seit 20 Jahren.

Micro Digital Leitlinie ist es qualitativ hochwertige Systemsoftware und Support zu moderaten Preisen anzubieten.

Detailinformationen zu SMX 4.1

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. See the smx Advanced Features whitepaper and smx datasheet for more information about these and other features.

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 and the stack pool, and it is small so it can be located in internal SRAM on most processors, for speed. The heap, event buffer, and error 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 give a high-level view of smx RAM usage. It shows bars indicating 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.