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).

measure_10ms_bananapi.jpg

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

measure_10ms_bananapi_04.jpg

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.

measure_10ms_bananapi_02.jpg

Bananapi-GPIO calculation

To use a PIN for gpio you have to calculate the relevant value for sysfs. As an example we use IO-0 of CON3 (see http://www.bananapi.org/p/product.html and picture of CON3 below).

The relevant information is that PIN11/IO-0 is PI19 on the processor. So the calculation follows a quite simple scheme (http://linux-sunxi.org/GPIO):

P = Port (32 Pins)
I = Connector-Line 9 (A = 1, B = 2, C = 3, … H = 8, I = 9)
19 = Pin 19 of 32

Number = (I – 1) * 32 + PIN
PI19   = (9 – 1) * 32 + 19  = 275

So the value 275 correspond to PIN11/IO-0. The rest is like every other device.

Activate PI19 for output
echo „275“ > /sys/class/gpio/export
echo „out“ > /sys/class/gpio/gpio275/direction

Set 3.3 Volt to PI19
echo „1“ > /sys/class/gpio/gpio275/value

Set 0 Volt to PI19
echo „0“ > /sys/class/gpio/gpio275/value

For testing I use a blue LED and a 1k resitor:

overview_05.jpggpio_led_04.jpg

I also wrote a simple script to let the LED toogle (https://github.com/tjohann/mydriver/tree/master/userspace_examples/gpio_script).

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.