SMX RTOS V 4.2 verfügbar

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

Für SMX 4.2 wurden große Teile des RTOS optimiert und neu geschrieben, die Codegröße konnte um 40% reduziert werden. Des weiteren wurden wichtige RTOS Funktionen weiterentwickelt.

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-Download sowie eine Übersicht über die speziellen Features in SMX 4.2.

Hier der Link  zum Hersteller Micro Digital.

Ü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.2

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.

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.