| |
 About SMX® v4
v4.1.0
Under development, near release. Significant new features. More soon...
v4.0.1
New Scheduler
The scheduler was rewritten so it is faster, cleaner, and more easily portable. This is a project that was done carefully over many months and thoroughly tested. Still, there is a single configuration option to restore the old scheduler and associated sections of code if a problem with it is suspected.
v4.0.0
Naming
ObjectAction naming is now used in the smx kernel and smxBSP APIs, such as smx_TaskCreate() and smx_TaskStart(). This groups related functions together naturally, making it easy to see what operations are possible for each type of object. smx Kernel API.
Prefixes such as smx_ and sb_ were added to these APIs, as were already present in many of our middleware products. This gives them their own namespace to avoid conflicts and also helps with code readability since it is immediately clear which product defines each symbol. The underscore helps to visually isolate the name from the prefix, and it is helpful in searches.
We have eliminated short names in preprocessor defines since they are more likely to clash with names in your code and third-party libraries, and errant preprocessor substitutions cause strange compile-time errors that are sometimes difficult to diagnose.
smx Kernel Improvements
Pipes were redone. Previously they supported only byte-sized data. Now they support packets of any size from 1 to 255 bytes, making it possible to not only send fundamental data types but also your own custom data structures. Pipes are equivalent to message queues in some RTOSes. (smx continues to provide more sophisticated messaging capabilities using exchanges.)
Scheduler locking has been changed to add a nesting count, and a flag was added to smx_TaskCreate() to specify whether to start the task locked or unlocked. Forgetting to unlock tasks inhibits preemptive scheduling, which has been the most
common support issue in v3. Now you must explicitly specify it when creating each task.
The heap now has a high water mark to show maximum heap usage since startup, making it easy to configure heap size. Also, a backward link was added to the HCB so blocks can be merged with the preceding block when freed rather than when scanning the heap during alloc or check functions.
The C++ features that had been used in some API functions have been removed. Some compilers are offered in lower-cost versions without C++ support. This was already handled in v3, but with conditionals in the code to call these functions one way if C++ and a different way for C.
Now all have a C interface in either case.
Future v4.x will add new features that have long been planned. We needed to release at this point to gain the benefits of the new codebase with all of its other improvements.
Centralized Porting Layer
We recognize that many projects have a need for the excellent SMX middleware, even though they have already chosen a different RTOS or no RTOS.
Previously, each middleware product had its own porting layer to handle differences in target hardware, OS, and tools. This meant it was necessary to port each product individually. In v4, all share a central porting layer, so that once it is implemented, all of our middleware products are supported.
(Note that when purchasing the smx kernel for a supported target board and tools, no porting is required.)
First we worked out a common porting layer. Then we implemented it for more than 10 common RTOSes. This revealed significant differences among them requiring changes to the porting layer to support them. (All RTOSes are not equal!) We went through several iterations of refinements to the porting layer to achieve this. Since it is a representative set of RTOSes, it is likely that the porting layer will support your custom RTOS or other RTOS if not one of these. Also, this means the work is already done for all of these RTOSes, and we will continue to port to others as well. In this case, our middleware is nearly a drop-in solution for your existing project!
Note that there are still a few product-specific things to port in each, as you would expect.
smxBase
This is a new module that is the foundation of all SMX products. It contains common definitions, macros, and functions so it is not duplicated in our different products. This reduces ROM space by eliminating redundant code; it improves reliability since there are not multiple versions of these that are possibly implemented differently; and it improves consistency and readability since familiarity with a definition in one product carries to others — there are fewer definitions, macros, and functions to be aware of.
smxBase also contains the porting layer just described and BSP code.
Compatibility with v3
Because it is common for our customers to order additional modules after their initial release, we made it possible to ship middleware from the v4 codebase to drop into existing v3 releases with few changes required.
This will shorten the time we need to maintain two codebases (which is error-prone). New orders of middleware for existing projects
will come from the v4 codebase, so the v3 codebase is only used to ship updates of products the customer already has (so they do not need to be ported again). For the v4 middleware added to an existing project, the porting will be done in smxBase, so if yet another product is purchased, the common porting will have been already done, giving a v4 benefit to existing customers using v3 releases.
Non-smx Releases
For those purchasing SMX middleware for another RTOS or standalone, we are now able to supply BSP code used by smx, reducing porting work further.
Code Cleanup
A great deal of cleanup has been done to the codebase.
Obsolete products have been removed, as well as conditionals for obsolete tools. Segmented x86 support has been removed, and with it arcane keywords and terminology, such as near and far. The smx kernel now supports only 32-bit flat architectures. (Middleware continues to be portable to any.) Historical quirks have been removed. Assembly support has been minimized except what is needed to write ISRs, and all definitions have been merged into a single .inc file for each architecture. This is less for us to maintain and less to distract you. Some files have been renamed for better consistency among products. smx kernel functions have been grouped into related files, since most modern linkers can deadstrip individual functions from object files.
All of these mean a cleaner and simpler release to work in.
Directory Structure
The directory structure has mostly remained the same, since it continues to work well. However, a few changes were made. All Protosystems were merged into one, now called APP. This eliminates a lot of duplicate code for us to maintain and ensures uniformity among different versions of smx. BSP code has been moved out of the Protosystem into its own directory which is more appropriate so libraries can access it, and since it is now supplied with standalone releases.
Documentation
All product manuals and BSP notes have been updated to v4. This was a large effort with all the name changes. The smx Reference Manual is easier to use due to the API renaming. Some simplification has been done to it and other manuals. Like the code, obsolete sections have been removed. SMX documentation continues to be among the best in the industry.
Conclusion
In summary, we have made significant improvements to the infrastructure of the SMX codebase as well as specific improvements to the smx kernel. We have both improved the integration among our own products and made it easier to use them ala carte.
Register now for access to the manuals and to be contacted by a product expert. Registration also enables us to mail you printed literature and is necessary to qualify for a free evaluation kit.
Back to v4 Home Page
1/26/12 |
|
............................................................... |
................................................................
|
| |
 |
Register now for more info. |
| |
| |
| |
| |
|
