My projects – an overview

I actually work on different (privat) projects. They all circle around embedded-linux, baremetal and hypervisour (https://github.com/siemens/jailhouse).

Baremetal:

– avr_sdk (https://github.com/tjohann/avr_sdk): add support for a Arduino nano v3 as base device. The Arduino nano v3 has a quite nice form factor, so it makes a perfect base edge device (small sensor devices).  I want to use this device for audio controller of my clock (https://github.com/tjohann/led_dot_matrix_clock).

– arm_cortex_sdk (https://github.com/tjohann/arm_cortex_sdk): implement fundamental parts to use it as a more powerful edge device. Therefore i try to setup a cross-toolchain and some basic librarys for two Olimex devices (https://www.olimex.com/Products/ARM/Atmel/SAM3-H256/ and https://www.olimex.com/Products/ARM/NXP/LPC-P1343/).

– core/base library for my arm_cortex_sdk (https://github.com/tjohann/sam3_p256_libboard): based on the Atmel and Olimex parts i restructure everthing to make it build and useable on linux hosts.

– the stuff i learned from the cortex-m work will guide me to jailhouse baremetal. For that i will use my A20-SDK (https://github.com/tjohann/a20_sdk). For more info take a look at the end of https://github.com/tjohann/a20_sdk/blob/master/README.md .

– as a basic for more complex topic i want to implement a mini-operation-system (https://github.com/tjohann/miblos). I read a very interesting book about the engineering of reliable embedded systems (http://www.safetty.net/publications/the-engineering-of-reliable-embedded-systems).

Embedded-Linux:

– inspired from that book i also learn more about the linux real-time sheduler and play with it (https://github.com/tjohann/time_triggert_env).

– imx233/arietta (https://github.com/tjohann/void-packages): add arietta and imx233 to void-linux

– imx233/arietta (https://github.com/tjohann/arm926_sdk): after A20_SDK_V2.0.0 of a20_sdk I will sync the arm926_sdk

– a20_sdk/arm926_sdk/a64_sdk (https://github.com/tjohann/crosstool-ng): add support for the void-linux versions to crosstool-ng

– a64_sdk (https://github.com/tjohann/a64_sdk): build the same like a20_sdk for Pine64 (https://www.pine64.com/) and other A64 base devices.

Linux:

– CAN/LIN bus infrastructure (https://github.com/tjohann/can_lin_env): at least provide an infrastructure for Baalue (Bananapi – {CAN} – Cluster see https://github.com/tjohann/a20_sdk/tree/master/pics).

– libbaalue (https://github.com/tjohann/libbaalue): this is my lib where all i have learned (realtime, CAN …) will be implemented for a more productive system. It’s something like my „embedded-Linux-libc“. Baalue and Baalued (https://github.com/tjohann/baalue and https://github.com/tjohann/baalued) will use it.

– baalue(d): both are parts of my cluster infrastructure.

– mydriver (https://github.com/tjohann/mydriver): this is the basic for I2C, SPI, GPIO functions needed for my clock, baalue or other projects.

– SDK-Builder (https://github.com/tjohann/sdk_builder): the admin tool for my *_sdk’s will be further developed after A20_SDK-V2.0.0 release (before it makes no sense). This GUI provide a complete environment to work/use all of my SDK’s.

Some first measurements

I did some testing with my gpio driver (https://github.com/tjohann/mydriver/tree/master/gpio_driver/driver) used by one of my time triggert (https://github.com/tjohann/time_triggert_env/blob/master/example_gpio.c) examples.

As you can see in the picture below I use my new Osziloskop for the timing measurements. The probe is connected to a LED over a 1kOhm Resistor (see https://github.com/tjohann/mydriver/blob/master/schematics/GPIO_LED_blau.png). The bananapi runs a minimal RT-PREEMPT kernel config with FULL-preemption (https://github.com/tjohann/a20_sdk/blob/master/bananapi/configs/kernel_config_4.4.x_minimal_rt).

The examples cycle time of the example is 10ms instead of 750/500ms, so the LED is „on“:

I want to measure how large the jitter will be in that configuration. The result is okay: ~200µs with a cyclic time of 10ms.

Thoughts about embedded devices (Part II)

With my first blog entry (https://tjohann.wordpress.com/2016/05/01/thoughts-about-embedded-devices-part-i/) I tried to give a overview of the topics I want to talk about. So the next step is to do some definitions and describe the „old“ world.

There’re different architecture aproaches for deeply embedded devices. One is the Time-Triggert-Architecture (https://en.wikipedia.org/wiki/Time-triggered_architecture) which is a subset of the more general Event-Triggered-Architecture.

The smallest entity within a embbedded system is somthing like a block. Such a block represents some functionality (regulator, ADC, sensor calulation …) and is builded by a c-function. If you split you whole system in such blocks/functions you know the information flow and you can calculate to duration time. Now you have something like a block diagram. With the relation between blocks and functions you can do the same for the software and buildup a fist architecture.

The next step would be to decide which architecture we want to use. With an event-triggert-architecture you define some irq handler for the different functions. This could be really complicated if you have a bigger system. So you also use a timer interrupt and group some functions in it.

An another approach would be to use a time-triggert-architecture. With that you group your functions around ticks. Ticks are the cylcle time, it is build with timer interrupts. An example could be 25ms which is common in the aircraft environment. So every 25ms an interrupt will occur.  An example would be

…- IRQ – Function A – Function B – Function C – sleep – IRQ – Function A – Function B – Function C – sleep – IRQ – ….

The list Function A – Function B – Function C will be called tick-list.  Such a tick list could also represend something like a mode. If you have a household-good like a washing machine, the you have different washing modes. So every mode would be represented by a different tick-list.

The final step is to decide if the functions are preemptive or not. So TTC is a time-triggert-cooperative system and TTP is a timer-triggert-preemptive system. A problem with TTP is priority inversion (https://en.wikipedia.org/wiki/Priority_inversion).

Now we should have a common understanding for the next steps.

 

 

 

Thoughts about embedded devices (Part I)

As an electrical engineer I’m quite interrested in embedded device. Actual I read a book about reliable embedded systems (http://www.safetty.net/publications/the-engineering-of-reliable-embedded-systems). The basic ideas are around a time triggert operation systems. The linux kernel already provides all needed parts like SCHED_FIFO/SCHED_RR and so I like to check the capabilities Linux provides and the thoughts/ideas in the book.

In a realtime system only one task could have „real“ realtime capabilities, because every other task can be interrupted by the „real“ realtime task (priority based system). This leads to some problems if you have a bigger system with a lot of different jobs to do.

So one common approach is to split the realtime behaviour in two different levels, one which is interrupt driven and one which describes the system behaviour (such systems are classical embedded systems as decribed in M.J. Pont`s book). The interrupt driven part are the different sensors and actors, but they do not describe the complete system (think of a mars rover or simply the washing machine).

The system itself is defined through the controller and the other „high-level“ functions. They reflect the behaviour of the system as a hole. A calculation on an ADC value ends after some time and the it causes an interrupt, but the motor controller (https://en.wikipedia.org/wiki/Motor_controller) is what describes the performance of the system.

If you have a digital controller you need a fixed dt, otherwise you can’t rely on your calculations. If you have a bigger system then you maybe have different controller (-> functions) running on your system. Again you can found some detailed info about an operation implementation for microcontroller in Pont’s embedded C book (Pont, M.J. (2002) „Embedded C“, Addison-Wesley. ISBN 0-201-79523-X)

So one basic approach is to have an interrupt driven part, which of course interrupt everthing (an ADC value is ready) and then a periodic time triggert part (the motor controller). In the periodic part your group functions which represent a controller/functionality (or what your architecture needed) around an repetition/cyclic time like 100ms. With that you can calculate the latency (if you ignore that you dont know the FIRST occurence) of the whole path.

So what is the difference between a deeply embedded system an a linux based embedded system? In Linux based systems it’s not possible to handle hardware interrupts like ADC. So all hardware related topics should reside within the kernel. An easy way is to write a kernel driver which implements a character driver with an entry in /dev. Now you can simple make a blocking read/write and you have the needed bahaviour. As an example you can take a look on my driver repo (https://github.com/tjohann/mydriver.git and https://github.com/tjohann/lcd160x_driver.git).

For the cyclic parts (in deeply embedded device) you normally use a hardware timer which causes an interrupt after the time elapsed. On Linux you can use a lot of timer which all based on an high resolution timer (need RT-PREEMPT patch).  So this can simply be handled by userspace program (https://github.com/tjohann/time_triggert_env.git). You need root rights for that, but with linux capabilities it´s easy to drop the unneeded priviledge.

Due to the fact that more and more embedded system want/will use Linux it’s interresting to check how a migration between those two worlds can be handled. One of my projects is a led-dot-matrix clock (https://github.com/tjohann/led_dot_matrix_clock.git). This is a project you normally would do with a microcontroller like an cortex-m3/4, but I want to use a linux based system.

So I start with an infrastructure library (https://github.com/tjohann/libbaalue.git) which implement important functions needed for my approach. I also implement all relevant hardware related parts in form of kernel driver (see links above).

A common basement for development are my sdk`s (https://github.com/tjohann/a20_sdk.git). In the final version I want to use an arietta or imx233 hardware (https://github.com/tjohann/arm926_sdk and https://sourceforge.net/projects/arm926sdk/).

So within the nexts weeks I will show the results.

Interests of an EE :-)

As an electrical engenieer I’m quite interested in realtime topics … so I started to play arount with it on linux -> https://github.com/tjohann/time_triggert_env … my hardware plattform for it will be the imx233 and the olimex

Working RT-PREEMPT config for Olimex-SOM

RT-PREEMPT is working -> https://github.com/tjohann/a20_sdk/blob/master/olimex/configs/kernel_config_4.4.x_minimal_rt …

Working images will follow during the next days.

 

 

A led-dot clock

I started a new „project“ based on an arietta device -> https://github.com/tjohann/arm926_sdk/commit/32e3fcf5d4eac027c8a9a1b475e85b264d0ae68b …. It will be a clock with an led-dot matrix, a small lcd display, a lm75 temperature sensor and LIN (https://en.wikipedia.org/wiki/Local_Interconnect_Network) to connect to the radio/audio modul. I already started with the hardware. It’s nearly complete, the only missing part is a pcf8574 based keyboard to control the lcd output.

Some days ago I also ound an nice IR-Modul with the coresponding control unit. So that will be also part of the clock modul.