ChibiOS Free Embedded RTOS

Hi, I'm new to ChibiOS. I compiled and run the RTOS on a STM32F103 dev board with simple ADC via DMA, multithreading demos etc. Now I wrote a simple own async implementation for sending RC switch-compliant commands to wireless AC sockets which is based on GPT callbacks/bitbanging.
The code works ok, the time diagram the method produces is perfect, yet I was slightly surprised by the fact that the OS concept dictates the callback code being executed in an ISR context - this is generally ok when the callback is fast and simple nor there's a need to use general API functions, but might be a problem otherwise. Moreover, the programmer has to always keep in mind which callback functions are called from an ISR, and which - from thread contexts.

I remember I used a ISR return address forging technique on a x86/MS-DOS to release the ISR context (store and patch ISR return address in the stack) - which frees the ISR context and runs the interrupt-driven user function in the user context. I wonder if such technique can (or planned to) be used in this RTOS for the callbacks? I understand that besides bringing in the cross-thread execution there might be platform-dependent restrictions from doing this - but on the other hand, you should be switching threads the alike manner in the scheduler.

Thank you,
Gleb

Hi,

In ChibiOS all callbacks are always called in ISR context, no exceptions I would use a different term for a callback called by a thread, a "notification" for example.

Note that from an ISR callback you usually wakeup a worker thread that does the actual handling, you can decide in which context handle the notification.

Giovanni

Giovanni, thank you for instant reply!

Thank you, the callback concept is now clear. Yet I would not use ISR-driven code to just signal the thread one to do smth that has to do with bitbanging port pins due to introducing signal edge jitter. The overall time synchronization in my code is ensured by the GPT being run in continuos mode, with forming pulses and interval correction for the next pulse in the callback func. The callback is close to the start of the ISR code chain, so the delay should be small and steady (provided that you disable nested IRQ's in the kernel) - which enables making stable time diagrams programmatically at the OS level.
What regards to cross-thread messages - I experimenting with them using a scope - the delay was about 3-4 uS on a 72Mhz STM32F103 (did not notice delay jitter though), which should not obviously affect the RC Switch protocol with its 500-uS pulses, but might be critical in faster protocols.

That is why I prefer the ISR-based callbacks, those leave all options open.

You should give a look to the IRQ-STORM demos under ./testhal too, very interesting stuff about GPT, callbacks, messages and threads.

Giovanni