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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.)
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.
The manuals have been carefully updated for all these changes. Additional improvements have been made to some chapters of the smx User's Guide, and the glossary in the smx Reference Manual has been rewritten.
Despite the significant gains made so far in v4, we are just getting started on the development we have planned for the smx kernel. Much of the work has been focused on infrastructure, the scheduler, and low-level details. These have been extensive and time-consuming changes to make.
We are now starting on smx v4.2, which will focus on the following:
Adding new, powerful features.
Enhancing Safey, Security, and Reliability (SS&R) features.
Adding performance enhancements such as multicore support.
Continuing to simplify and make smx easier to use.
Hence, you can expect smx to keep grwoing with your project needs.