ChibiOS Free Embedded RTOS

I saw somewhere using a sleeping high priority thread with a periodic wakeup timer to simulate the system tick (although I haven't done it myself, so YMMV).

~t

Hi,

If I want to write to shared data from a normal IRQ (non-"fast") what is the correct way to access it safely without using chSysLockFromIsr? I want to use a semaphore but my code keeps crashing, so maybe I am using the wrong calls. (chBSemWait & chBSemSignal use chSysLock internally instead of ...

Awesome! That's the kind of solution I was hoping for. Thanks a lot,

~t

Hi,

I am using a "fast irq" for comm and inserting data into a lock-free queue as it comes in. So far so good...

I would like to signal a sleeping thread that there is data available, from inside the "fast irq". I know of two ways: (1) having the thread busy-waiting checking on the queue, or (2 ...

Hi Geovanni,

I have to say, ChibiOS is one of the most beautiful designs and code bases I have seen. I would like to know more about how it came to be.

Can you tell us a bit more about its history? Are there other projects or books that influenced your decisions in terms of coding style and RTOS ...

I went and read a bit about masking out interrupts. How about locking interrupts specific to the specific driver, or above certain priorities?
It seems like a recipe for "a lot of pain" but it would allow leaving the kernel and some interrupts untouched while doing atomic updates in other less ...

I am worried that in some cases those locks turn off interrupts for quite a bit of time (for example, when doing low level driver "start()" calls).
I have "fast interrupt" that I really don't want to miss. Would it make sense to enclose those calls in a mutex instead? (I don't really know, I'm just ...

Hi Giovanni,

Why do all the HAL calls wrap the sub-calls to the lld_fn() functions around chSysLock(); fn(); chSysUnlock(); ? Could there be a problem if these calls are unprotected?

Thanks,
~T

How about STM32-F4 statements like these?

#define STM32_UART_USART1_RX_DMA_STREAM STM32_DMA_STREAM_ID(2, 5)
#define STM32_UART_USART1_TX_DMA_STREAM STM32_DMA_STREAM_ID(2, 7)

Are these ignored by the Cortex-M3 initialization?

I noticed that the mcuconf.h for the M4's is pretty different from the Cortex-M3's. Is there a way of creating one that works for both or should I just stick with using 2?