ChibiOS Free Embedded RTOS

The reliable and slow way to convert from port to bit mask is creating an association table but I really dislike such a crude solution. I absolutely support this statement! A cumbersome LUT cannot be called a "good solution". Just a detail, you can map multiple event sources to the same e...

[...] there is no guarantee it wont change in future devices. I read this as "might break portability and will thus not be implemented in ChibiOS". I would be absolutely fine with that argument ;) BTW, why don't use one EventSource for each port? you could mask port bits 1:1 with event fl...

Such a solution would not be portable, as it highly depends on the memory layout of each platform. The mentioned hal_pal_lld.h is defined on a per-port basis, while the PAL_PORT(), PAL_PAD() and PAL_LINE() macros are part of HAL (even though they are implemented for each port specifically). Moreover...

Unfortunately, PAL_LINE() does not help me here, as it does not fulfill my flag-like encoding requirement. In my current solution, each pad is represented by an individual bit in the eventflags_t value. This is easy, since pads are numbered from 0 to 15, which can be used as-is for shifting. GPIO po...

tl:dr: I would like to encode GPIO ports as integer values [0, 1, 2, ...]. Is there an existing macro/function for this or can it be introduced? In my project, I use a central event source to inform the whole system about GPIO events. In order to distinguish individual sources (i.e. pins) that trigg...

Hi,

the fix works fine for me. Thank you!

Hi, I just encountered a compilation error when calling palIsLineEventEnabledX() using an STM32L476. The function is defined identically in all three GPIO LLD versions: #define pal_lld_ispadeventenabled(port, pad) \ (bool)((EXTI->IMR & (1U << (uint32_t)pad)) != 0U) Now the issue is, that IMR is ...

I see that there is some a priori knowledge used for thread handling, depending whether it is an AND or OR condition. I also understand that modifying all involved components is not trivial and is probably rather something that should be implemented for a major release. However, I disagree that my s...

Your solution requires the emitter of an event to know about the receiver, which is very bad code design, imho. An emitter must not care about other emitters or any receivers, it just informs about its own actions. Of course, I could introduce meta-instances, which accumulate subsets of events and f...

Hi, when waiting for events, I encounter situations in my project, where the available chEvtWaitXXX() functions do not provide an optimal solution. It's easy to understand with the following example: Let there be three events with the masks 0x01, 0x10 and 0x20. Depending on the events received, the ...