OpenComRTOS Designer new support for ARC600, ARM-Cortex-R4 and ARM-Cortex-A9.

Altreonic has recently completed porting its OpenComRTOS Designer V.1.6 to new targets. The new ports illustrate again how with a single programming environment and small code size, OpenComRTOS Designer allows seamlessly connecting and supporting of low power ASIC cores, micro-controllers for safety critical applications and higher-end SoCs with multi-core processors with DSP and video processing capability. Contrary to many other solutions, OpenComRTOS allows to program multi/many-core in heterogenous configurations in a fully transparent way. Developers can remap Task and Interactions Entities  (semaphores, FIFO, etc. called Hubs in OpenComRTOS) in a fully transparent way, with no changes to the source code. The underlying implementation is based on prioritised packet switching, an approach that is not only scalable, but also it provides real-time behaviour across any communication medium ranging from shared memory to long distance networks.

1. ARM-Cortex-R4 Safety MCU

The Texas Instruments implementation of the ARM-Cortex-R4 is part of their Hercules Safety MCU product line, specifically targeting safety critical applications (IEC 61508 and ISO 26262). While transparent to the user, it features a dual-core CPU operating in lockstep and with fail-safe detection logic. See ARM website and TI website for additional details on these chips.

Altreonic has now ported OpenComRTOS Designer to the RM42x LaunchPad evaluation board. This board runs at 100 MHz and has 32 KB of ECC SRAM. 

Depending on the services needed, a minimal application requires between 17 and 22 Kbytes on the ARM-Cortex-R4 (compiled with 0s), including the C-runtime library and self-test code executed at boot time which takes about 10 KBytes. A typical semaphore loop requires about 33 microseconds (which means 4 context switches and 4 kernel services). 

Interrupt latency is around 2 microseconds to reach the Interrupt Service Routine and about 16 microseconds to reach a waiting Task.

2. ARM A9 on Phytec and Panda board.

The current port is using the well known Panda board as well as the Phytec phyCORE-OMAP4460 board. Both features the TI OMAP4460 Soc with a dual-core ARM A9 running at 700 MHz. 

Note that for the case of the TI OMAP SoC, OpenComRTOS is already available for the on-chip ARM-Cortex M3 and C6000 DSP cores. 

The figures below were obtained on the Panda board (700 MHz with 32Kbytes instruction and data cache).

Depending on the services needed, a complete minimal application requires between 17 and 23 Kbytes on the A9 (compiled with 0s), including the C-runtime (which takes about 4 Kbytes). A typical semaphore loop takes about 5 microseconds (which means 4 context switches and 4 kernel services). In multi-processor mode whereby the shared memory is used to communicate between the processing nodes, the same loop requires about 8.9 microseconds. 

Interrupt latency is around 150 nanoseconds to reach the Interrupt Service Routine and about 1.3 microseconds to reach a waiting Task. 

3. Synopsis ARC cores

Synopsys' DesignWare® ARC® 600 Family of 32-bit RISC processor cores are optimised for embedded applications and DSP tasks where high performance and low power consumption is required. The ARC cores are not stand-alone processors but IP-cores typically integrated in ASICs for customer specific applications.  These solutions include the DesignWare ARC 601, ARC 605, ARC 610D and ARC 625D.

Altreonic has now developed a Board Support Package for its OpenComRTOS Designer™ to the ARC AXS101 development board of Synopsis. This board has a dual-core 600 MHz ARC600 each having 16 KB of cache and c connected over a shared memory, This work was done in the context of the Artemis CRAFTERS project that focuses on the design and programming challenge of developing applications with many- and multicore architectures. 

Depending on the services needed, a minimal multi-tasking application requires between 29 and 32 KBytes on the ARC600 (compiled with 0s),including the C-runtime library which requires about 20 Kbytes. A typical semaphore loop requires about 6.4 microseconds (which means 4 context switches and 4 kernel services). In multi-processor mode whereby the shared memory is used to communicate between the processing nodes, the same loop requires about 15 microseconds. Interrupt latency is around 300 nanoseconds to reach the Interrupt Service Routine and 1500 nanoseconds to reach a waiting Task.