ChibiOS Free Embedded RTOS

I think it's still incorrect. I edited my last reply to include a correct solution. Define another struct containing the common elements of both virtual_timer_t and virtual_timers_list_t and place that as a member in both. ch.vtlist.vt_next->vt_prev = (virtual_timer_t *)&ch.vtlist; /* If the lis...

It's not a compiler bug, it's a code bug. The code violates C aliasing rules. The type of ch.vtlist is virtual_timers_list_t, while vt_next / vt_prev point to virtual_timer_t. The compiler assumes that a pointer to virtual_timer_t cannot point to a virtual_timers_list_t, as they are different types....

They probably would be, but I'm swamped with work for the foreseeable future (aren't we all?). Most of the patches are rather simple fixes. The RX FIFO patch adds a larger receive buffer for UART_RX_IDLE / rxchar_cb mode. It makes the driver less prone to overrun, and the system is not interrupted f...

The time unit conversion macros give rather unexpected results when passing 0 as an argument. I know that 0 is not a valid argument for functions accepting systime_t, but the current behavior breaks valid code like this: uint32_t ms = 0; systime_t delta = whatever(); ... if (delta > MS2ST(ms)) blah(...

I think most, if not all, peripherals work this way. UARTs and SPIs sure do. http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/application_note/CD00256689.pdf Check out 1.3.1 on page 5 for an example. But yeah, the docs should make this more clear. There is no need to clear th...

Apparently that assertions is triggered by a spurious interrupt associated to a timer that has already reset, for some reason the interrupt remains pending and is triggered as soon the critical zone is left. Disabling the timer interrupt through DIER won't clear the pending status if the interrupt ...

This would suffice. It doesn't need to be split for v6m and v7m (same source will compile for both), and doesn't rely on undocumented compiler internals (which are not enforced by any contract and therefore subject to change from version to version). _init_process_stack and _start can use the stack ...

This doesn't look right though: /* * Area fill code, it is a macro because here functions cannot be called * until stacks are initialized. */ static void fill32(void *start, void *end, uint32_t filler) { uint32_t *p1 = start; uint32_t *p2 = end; while (p1 < p2) *p1++ = filler; } The comment doesn't ...

Yes, it's both faster and smaller. But that's NOT the main reason why it's worth pursuing. The problem is not that LTO breaks the code, but that the code is already broken, LTO just exposes the problems. Sooner or later they will come out and bite you anyway. Those are the sort of annoying problems ...

I see that problem too but so far I don't know a solution, I don't remember this from my previous attempt. Here, I fixed it for you: https://github.com/szmodz/ChibiOS/commits/fixes I need all of those to get ChibiOS working reliably on a disco f4 across optimization settings (including, but not lim...