Direkt zum Inhalt

Hersteller

Micro Digital

Systemsoftware für Embedded Systeme

  • Micro Digital verfügt über ein vollständiges Produktspektrum an Softwarebausteinen für moderne (deeply) Embedded Echtzeit-Systeme
  • Out of the box funktionsfähig und sofort einsetzbar!
  • SMX ist bewährt und verfügt über einen vollständigen Funktionsumfang
  • No Royalties + Source Code: Damit Sie ruhig schlafen können, jetzt und in Zukunft!
  • Optimal für Deeply-Embedded Systeme geeignet: Hard Realtime, extrem ressourcenschonend, skalierbar
  • Umfangreiches Angebot an Middleware

Produkt

smx RTOS Kernel

smx ist ein zuverlässiger, hard real time multitasking Kernel für Embedded Systeme. Er kann alleine oder mit anderen Komponenten des SMX RTOS betrieben werden. Zu den unterstützten Architekturen zählen ARM/Cortex, ColdFire und PowerPC. smx bietet viele Features die es Anwendern erleichtern ihre Projekte termingerecht und ohne Probleme fertigzustellen.

smx 4.2 hat viel mehr Features als ein einfaches Standard RTOS, die helfen schnell und kostengünstig sichere und zuverlässige Systeme zu entwickeln. Für mehr Details empfehlen wir Ihnen das smx Special Features Datasheet in dem diese Features diskutiert werden.

Micro Digital
RTOS

MPU-Plus

MPUS-Plus bietet die Unterstützung der Memory Protection Unit (MPU) für ARM Cortex-M basierte MCUs und das SMX RTOS. Kurzum: Mehr Sicherheit für Ihr System!
Die Unterstützung andere RTOS ist möglich.

Die Cortex-M v7 MPU ist komplex und hat signifikante Beschränkungen. MPU-Plus ermöglicht die einfache Verwendung der MPU bei maximal möglichem Schutz. Wichtig ist dabei die Möglichkeit zur schrittweisen Erhöhung der Sicherheit des Systems, lesen Sie hierzu den Artikel "Step-by-Step MPU Security"

Micro Digital
RTOS

smxAware Live

smxAware Live - Kernel Aware Debugging

Mit smxAware Live steht ein Werkzeug zur Verfügung, welches es dem Entwickler ermöglicht in strukturierter und übersichtlicher Weise Einsicht in verschiedene Laufzeitdaten und -Strukturen des smx RTOS Kernels zu nehmen. smxAware Live kommuniziert mit dem Target über TCP/IP und arbeitet parallel zum laufenden RTOS mit Anwendungssoftware, d.h. Anwendern ist ein Einblick ins laufende System möglich.

Micro Digital
RTOS

TCP/IP Stack

smxNS ist ein robuster und kompakter TCP/IP Stack der speziell für Embedded Systeme von Micro Digital entworfen und entwickelt wurde. Mit smxNS6 steht ein Dual v3/v6 Stack zur Verfügung.

Er ist in C geschrieben und kann auf jeder Hardwareplattform eingesetzt werden. Obwohl er für das SMX RTOS entwickelt wurde, kann er auch einfach in Zusammenhang mit anderen RTOS wie z.B. FreeRTOS, verwendet werden.

Micro Digital
TCP/IP Stack

USB Host Stack

Mit smxUSBH steht ein USB Host Stack speziell für Embedded Systeme zur Verfügung. smxUSBH ist optimiert für den smx RTOS Kernel. Er ist vollständig in C implementiert und kann daher mit wenig Aufwand auf verschiedene Hardwareplattformen und andere RTOS Kernel portiert werden. Auch der Betrieb ohne einen Betriebssystem Kernel ist möglich.

Es stehen sehr viele Treiber für die verschiedensten USB-Klassen zur Verfügung.

Micro Digital
USB Stacks

USB OTG Stack

smxUSBO ist ein robuster USB On-The-Go Stack der speziell für Embedded Systeme von Micro Digital entworfen und entwickelt wurde. Er ist in C geschrieben und kann auf jeder Hardwareplattform eingesetzt werden. Obwohl er für das SMX RTOS entwickelt wurde, kann er dank eines Porting Layers sehr einfach auch auf andere Betriebssystem portiert werden bzw. auch "stand-alone" betrieben werden.

Micro Digital
USB Stacks

FAT Filesystem

smxFS ist ein FAT Dateisystem, dass Medien Kompatibel zu DOS und Windows ist. Es hat einen sehr kleinen Code und Daten Footprint, was es gerade für den Einsatz in Embedded Systemen geeignet macht.  smxFS unterstützt Flash-Speicher wie USB Sticks, CompactFlash und SD/MMC.

smxFS unterstützt FAT12/16/32 und VFAT (für lange Dateinamen). Es benutzt die Standard C Bibliotheksfunktionen als API (z.B. fopen(), fread(), etc.).

Micro Digital
File System

Flash Log Filesystem

Flash Log Dateisystem

smxFLog stellt eine Möglichkeit zum schnellen, einfachen und zuverlässigem Speichern von Log Daten in NAND und/oder NOR Flash Speichern zur Verfügung.

Das Speichern von Log Daten ist ein typischer Anwendungsfall bei Embedded Systemen und verlangt nach einer guten Lösung. Dabei werden Daten sequenziell an eine Datei angehängt. Dies ist bei klassischen Dateisystemen wie FAT, nicht besonders effizient, wenn dies auf Flash basierten Medien arbeitet.

Micro Digital
File System

USB Device Stack

smxUSBD ist ein robuster USB Device Stack der speziell für embedded Systeme entwickelt wurde. Er ist in C geschrieben und kann auf jeder Hardwareplattform eingesetzt werden. Obwohl er für das SMX RTOS entwickelt wurde, kann er dank eines Porting Layers sehr einfach auch auf andere Betriebssystem portiert werden bzw. auch "stand-alone" betrieben werden.

Es stehen sehr viele Treiber für die verschiedensten Funktionen zur Verfügung.

Micro Digital
USB Stacks

Flash Filesystem

smxFFS ist ein spezielles Flash Dateisystem für NAND und NOR Flash Speicher. Es hat eine zur Standard C Library kompatibles API und kann mit plötzlichem Spannungsverlust umgehen (power fail-safe).

Micro Digital
File System

NOR Flash Driver

Der smxNOR Flash Treiber stellt einem Dateisystem ein API zur Verfügung, dass es ihm ermöglicht ein NOR Flash wie eine Festplatte anzusprechen. smxNOR arbeitet mit dem smxFS Fat Dateisystem zusammen. Der Treiber ist in 2 Schichten aufgebaut. Der high-level Treiber stellt einem Dateisystem ein Sektor basiertes API zur Verfügung.

Micro Digital
File System

NAND Flash Treiber

NAND Flash Treiber

smxNAND ist ein Treiber der es ermöglicht, dass ein Dateisystem auf ein NAND Flash wie auf eine Festplatte zugreifen kann. Es unterstützt sowohl single-level cell (SLC), wie auch multi-level cell (MLC) NAND Flash Chips. Power fail safe sowie statisches und dynamisches Wear Leveling sind selbstverständlich.

Micro Digital
File System

Wi-Fi Stack 802.11 MAC

smxWiFi ist ein robuster IEEE 802.11 MAC Stack, der speziell für den Einsatz in Embedded Systemen entworfen und entwickelt wurde. smxWiFi ist vollständig in C implementiert und ist so universell verwendbar.

smxWiFi arbeitet mit USB WLAN Dongle und PCI Karten zusammen

Es stehen folgende Erweiterungen zur Verfügung:

  • SoftAP - Access Point Funktionalität
  • Wi-Fi Peer-to-Peer (P2P) - direkte Verbindung von Wi-Fi Geräten
  • Wi-Fi Simple Configuration - WSC, auch WPS genannt
Micro Digital
TCP/IP Stack

smxAware

Mit smxAware steht ein Werkzeug zur Verfügung, welches dem Entwickler ermöglicht in strukturierter und übersichtlicher Weise Einsicht in verschiedene Laufzeitdaten und -strukturen des smx RTOS Kernels zu nehmen. smxAware integriert sich in Entwicklungsumgebungen von IAR (Embedded Workbench) und Freescale (Codewarrior).


Micro Digital
RTOS

GoFast IEEE 754

GoFast IEEE 754 Floating Point Bibliothek

GoFast ist eine IEEE 754 konforme Bibliothek zur Verwendung von Fließkommazahlen auf Systemen, die über keine eigene Floatingpoint Einheit (FPU) verfügen. Da GoFast in Assembler geschrieben wurde, ist es deutlich schneller als die meisten, mit Compilern ausgelieferten Floating Point Bibliotheken. GoFast unterstützt: 68K, ColdFire, MIPS, NIOS II, PowerPC, SH, SPARC, V8xx, x86, Z80, 68HC, 8051, 80196.

Micro Digital

Ältere News Micro Digital

07.05.2007 | SMX.Blaze

Beratung

Lassen Sie sich beraten, nutzen Sie unser Formular, wir melden uns umgehend bei Ihnen zurück. Oder rufen Sie an:
+49 251 98729-0

NEWS

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.


Detailinformationen

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.)
    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.

Manuals

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.

What's Next

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.
    Power management.
    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.

Hersteller / Partner
Micro Digital
Funktion
RTOS

© Embedded Tools GmbH | Willy-Brandt-Weg 33 | 48155 Münster | Germany/Deutschland | Datenschutzerklärung | Impressum