OpenComRTOS Designer new v.1.6 release

Altreonic has recently added new features to its network-centric RTOS that make programming systems with multiple, even heterogeneous processors even easier than before. The new support extend the virtual shared memory and virtual single processor support.

Supports system-wide shared data structures: virtual shared memory model
OpenComRTOS is the unique formally developed RTOS that can program seamlessly even heterogenous systems from a single processor to 1000's of processing nodes. It comes with a visual modeling environment whereby the developer independently specifies his parallel multi-processor target system and application architecture. Tasks and interaction entities can then be transparently mapped to any node in the system, even when the processors are of a different type. With prioritised scheduling and support for distributed priority inheritance, the system remains real time predictable with a typical code size of less than 10 KB per processing node. From v.1.6 of the OpenComRTOS Designer environment on, the developers benefits from a streamlined kernel source code and new features. OpenComRTOS Designer is however a lot more than an RTOS. Read further ....

Share |

OpenComRTOS: Middleware as Extended OS: virtual single processor model
One benefit of developing OpenComRTOS as a network-centric RTOS from the very beginning is that it provides a very lean and transparent communication layer also when used on top of other host operating systems. This is typically Windows or Linux on a host machine but it can run on most other operating systems or RTOS as well. Developers can use this in 3 ways:
•    Cross develop a multi-processor target application on a development machine.
•    Simulate a multi-processor target application on a development machine.
•    Integrate seamlessly existing host machines with an attached embedded and networked system.
Contrary to traditional middleware layers, there is less scheduling overhead and less memory required. In addition, the developer benefits from the automatic routing so that his code is mostly independent from the multi-processor architecture and communication infrastructure. On the embedded targets, even with just a few KBytes of RAM, tasks can invoke host-OS services like using the keyboard and screen or reading files or writing new data into them. This approach makes all services system-wide available even on small processing nodes with just a few Kbytes of memory. Altreonic calls this the Virtual Single Processor approach.
The MS-Windows and Linux (Debian) version of OpenComRTOS Designer is available free of charge from Altreonic’s website to try it out.

Converting legacy POSIX style RTOS applications.
While POSIX is widely used as a standard programming interface, it often requires relatively large commercial RTOS that don't support distributed and many-multicore systems in a transparent way. This partly comes from the fact that these RTOS were derived from desktop or server UNIX-style operating systems. And while they can and are used to develop real-time applications, they require much more memory than is really used by the application, which further increases the cost and power consumption. In addition, certification is a lot more expensive and complex.
Altreonic recently helped a customer in converting his application from such a COTS RTOS environment. The original application contained about 400000 lines of C-code and used several Mbytes on a 1 GHz PowerPC. The conversion was done in 2 weeks using the Linux OpenComRTOS cross development and simulation environment, resulting in a total code size reduction of about 50%.  In combination with an Open Technology License, the customer is now happy as he has no longer any strings attached while he is free to distribute the application over multiple smaller processing nodes. The technical benefits are scalability, more freedom in placing the subsystems in a confined space and less heat and power issues. In addition, the application can now be made more robust by adding redundancy in the system with little programming effort.

Blackboard-Hub
A difficult issue in networked systems, many- or multicore systems, is to share data structures in a reliable way. Even when shared memory is available, the problem remains that the datastructure must be in a unique state and protected to use it globally. OpenComRTOS has since its creation the necessary services to achieve this by exchanging packetised messages from dedicated sender to receiver tasks. The BlackBoard hub is a way to achieve this in a global and more flexible way. Data-structures are written onto the BlackBoard by dedicated Tasks and can be read by any other Task in the system, whether on the same processing node or geographically fully separated. Additionally, the service allows to verify the version of the datastructure that was updated and how many updates were missed. The BlackBoard-Hub is in particular interesting if the system needs to broadcast periodically new system-wide parameters and global datastructures. Further extensions are feasible such as invoking a call-back function that further processing the data, a feature very useful in parallel supercomputing.

Improved distributed priority inheritance.
While already integrated awhile the distributed priority inheritance protocol implementation was reviewed and updated. Support for priority inheritance is crucial for predictable real-time systems as it reduces and often prevents the resource blocking of high priority tasks by lower priority tasks. No real-time system should be without it and it was made famous in the 1970's when the first Mars Rover kept resetting itself due to priority inheritance being disabled. While the algorithm is relatively trivial on single processor systems, in distributed systems resources and tasks can be located anywhere in the system. OpenComRTOS facilitates this because all tasks and interaction entities are global and can hence by easily located, which a traditional RTOS solution with a dedicated middleware layer can't provide except with a large overhead. The OpenComRTOS extension for this support is also less than 1 Kbytes (measured on an ARM implementation).
The new implementation paves the way for a more general dynamic resource scheduling as Altreonic researches in the Crafters Artemis project.

Build-in workload monitor
Being able to measure the application workload can be very handy to verify if the target processor can handle the application workload. This can be achieved by measuring how much of the time the processor is in the so-called idle Task. The issue however is that such a measurement is time dependent. While the average workload can be relatively low, the application might need full power when executing a high priority task. The OpenComRTOS was extended with the capability to measure the workload on any processor in the system whereby the measuring interval can be selected. The measurement itself is essentially non-intrusive and the local workload can be read by a monitoring task or using a J-TAG based debugger.

Standardised interrupt latency measurement
A very important parameter for real-time applications is the interrupt latency. Contrary to what some vendors provide, this is actually not a single figure but a measurement that is statistical in nature. It not only depends not on the hardware set-up but also on the application activity. OpenComRTOS comes with a pre-configured test program to measure it in real-time. Two measurements are defined. The first one is the IRQ (interrupt event) to ISR (Interrupt Service Routine) latency and defines the time it takes to read a timer value in the ISR. On most targets this is below one microsecond. The second measurement is the IRQ to TASK latency. Hereby the interrupt is picked up by the ISR who then signals an Event to a high priority waiting Task. This takes typically a few microseconds. Both measurements have a statistical profile that depends on the application load. In the test set-up the system is stress loaded by two tasks that continuously synchronise and switch context, but in a real application also other driver activity will affect the worst case latency. Important is that the worst case latency is strictly bounded, even after millions of measurements. The maximum latency measured provides a reliable parameter for dimensioning the application and determines how fast the system can handle I/O requests.     
The OpenComRTOS set-up uses an on-chip timer to generate the interrupts and a small visualisation program on a host machine to display the histogram.

More information:
www.altreonic.com

Contact:
Eric Verhulst +32 477 608 339
info.request (@) altreonic.com