Platform Abstraction

The redBlocks platform abstraction concept that allows smooth integration of embedded software applications with the redBlocks WYSIWYG-SiL-Simulator separates the software on driver layer in a target platform dependent part and a portable platform independent part. It thus defines only a very thin low-level driver layer that is hardware dependent. All hardware-independent driver features (e. g. intermediate data buffering within a serial driver) are implemented in the high-level driver layer, which can be reused on different targets. With this separation in place, porting an application to a different target platform is really easy, because only the low-level driver layer needs to be substituted.

 

Block-Diagram: Platform Abstraction

 

SiL-Environment

Under this condition, the embedded software application can be smoothly integrated with the redBlocks Simulator: Instead of linking the embedded software application with low-level drivers that access the target's peripherals, it is linked with the redBlocks SiL simulation driver stubs . All source code above the low-level driver layer remains unchanged, no matter whether the application runs on the target hardware or within the SiL environment.

Simulation Driver Stubs

Hardware Support

While the redBlocks Simulator supports basic hardware peripherals (e. g. digital + analog IOs, displays, various communication interfaces) out-of-the-box, arbitrary complex hardware peripherals (e. g. RFID reader chips, sensor chips, ...) can be simulated with custom driver stubs. A custom driver stub is implemented in C or C++, needs to offer the same API as the real target driver and is linked with the embedded software application. It uses a communication channel of the redBlocks SiL environment to interact with a hardware simulation script, that can be implemented with the scripting language Python and runs within the redBlocks Simulator's environment on the host. The script can be associated with configurable interface controls in the redBlocks Simulator that provide a graphical representation of the simulated hardware device and allow the user to manipulate the simulated peripheral (e. g. press a button in order to simulate an RFID tag has been placed in the reader's field).

Hardware simulation scripts can also be used to emulate the behavior of the simulated device's environment (e. g. gradually decrement the analog input value of a temperature sensor, while a cooling actor is switched on).

 Hardware Simulation Scripts

SiL-Environment on the Target

During development it is very convenient to let the embedded software run on the host, without the need to even have the target hardware available. For software verification with automated tests however, the embedded application should be operated in an environment that is as close to the target hardware as possible (e. g. in order to detect bugs related to the target processor specifics, like endianess issues). At this stage in the development process, the SiL environment and the embedded software application can be run on the target processor (either on the real target hardware or an evaluation board). In this setup some peripheral drivers can access the real target's hardware (e. g. flash memory), while all peripherals that are needed for test stimulation and automated checks are still simulated in the redBlocks Simulator.

Automated SiL Test

The communication link between the target hardware and the simulator can be an arbitrary communication channel (typically a serial line or an ethernet connection).

 

No Overhead with C++

A very important aspect for low-resource embedded targets is the fact that the separation in a low-level and high-level driver layer does not introduce any overhead to the compiled target software. When implementing with C++, this is accomplished by the code generation features of C++ templates that are used throughout the whole redBlocks Component Library: During the code generation phase, the compiler seamlessly merges the source code of the high-level and low-level drivers, optimizing away all overhead. The redBlocks Component Library's callback mechanism makes function pointers or virtual methods for the callback functions between low-level and high-level drivers as well as between the driver layer and application modules obsolete. With this concept, driver callbacks to higher level software modules are more efficient than with function pointers that are typically used in many C programs.

 

Integration with existing Embedded Applications in C

However, it is certainly possible to integrate legacy C applications with the redBlocks Simulator as well. In this setup, the C Target Simulation API is used instead of the C++ redBlocks Component Library.

In embedded applications that are developed in C, there is often not such a clean separation between high level and low level drivers. Therefore, in C applications it is very common to  completely replace the driver layer (i.e. high-level and low-level driver functionality) with driver stubs in order to integrate the application layer with the redBlocks Simulator.