ChibiOS Free Embedded RTOS

Giovanni wrote:2.6.9, 3.0.1 and trunk were affected, fixed on repository.

Did the bug appear first in these revisions, or was it already there earlier (in 3.0.0 for example)?

Hello,

in an os-less small program (bootloader) using the os-less OSAL for the HAL, I wanted to use chprintf() at least during development. However, chprintf() has a very small (macro) dependency on chSequentialStreamPut. This means the build fails with this compiler error:


In function ...

Hi Giovanni,

again, long time but I see you have been carefully coding the 3.x kernel with tickless and high-resolution modes. Great timing, giving the STM32L parts but also SAML21 parts, or maybe even the nRF52xx part, all claiming around 37 uW/MHz. I was about to start playing with these parts ...

Giovanni,

wow, tickless!

It will probably open new cans of worms, but I think there may be added value to a tickless RTOS. Or do you think RT is contradictionary to tickless?

Random thoughts:

Do you know of any processors that can be waken from deep sleep from the internal RTC? (Instead of an ...

Hello guys,

thanks for sharing and finding all the lwIP/ChibiOS/RT issues so far.

I experimented with zero-copy on an AVR32 platform (i.e. DMA directly into pbuf buffers) and IP, UDP and TCP worked on the inbound path, but ICMP did not. I have done a lwIP code investigation and I do not think that ...

JetForMe wrote:Is this a toolchain that can run on Mac OS X?

Yes, should work for OS X if you rebuild it. I have a prebuilt one here, including the build script, for OS X and Linux: http://www.sidebranch.nl/cortexm3/

It is not bleeding-edge, but it is proven.

Regards,

Leon.

Scrap bug report, user error.

Now, to remove the copy loop in packet reception, I think PBUF_PREF will not do, as we never know when the pbuf is freed, and we need to maintain the descriptor along with the pbuf.

There is support for custom pbufs in lwIP, which can call a custom callback function ...

I ended up with this, as indeed the string appeared a few times in the .text section. This is for chcore_v7m.h|c:

.h:

#if defined(__DOXYGEN__)
#define port_switch(ntp, otp) _port_switch(ntp, otp)
#else
#define port_switch(ntp, otp) { \
THREAD_SWITCH_HOOK(ntp, otp); \
_port_switch(ntp, otp ...

Confirmed. I think having a panic_msg for "stack overflow" makes good sense, like the (newer?) non-GCC ports for ARM seem to have.

Regards,

Leon.

I think now that the "stack overflow" message is there, the stack check should be in the C _port_switch(), to prevent that string from re-appearing in different object files and functions through the macro, taking up extra memory.

The port_switch() macro is used 3 times in the chsch.c file ...