How to integrate FreeRTOS ?

[fastlock]

I'm having trouble integrating freeRTOS from the porting and example of https://github.com/yunkya2/pico-freertos-sample made for pico-SDK.
Any ideas?

[earlephilhower]

Moved this to a discussion since it’s not really a core issue.

You’re going to have to rewrite the whole core to build it under freertos. It’s not impossible, but you can’t just include a header or source file to make it work.

[earlephilhower]

For the bootsel crash, can you give #572 a try? I am pretty sure I've had the IRQ/idle order wrong since the beginning, but MT w/FreeRTOS would exacerbate the issue.

About the #include <task.h> need, isn't that standard to use FreeRTOS? We haven't touched the base includes at all.

As for the setup/loop and setup1/loop, I am not so sure there's a logical way to get where you're going. It doesn't make any sense to start setup1 only after setup has completed...that's the point of the simple MT way. Same argument for loop1 waiting until setup has completed.

AIUI there is only one ApplicationIdleTask so I'm really not sure how you'd move both loops into it. If you just moved loop in, it would run at the lowest prio while loop1 would be above it and executed much more frequently. And loop1 would be a task and able to use vTaskDelay for delay() while loop would crash the system if it used that call (ask me how I know... 😢)

Maybe a weak global could be introduced, say __enablePureFreeRTOSMode which you could override in your sketch to give you the very un-Arduino config you need?

[hfellner]

I tried the change from #572 but it didn't really change anything. If I have the tasks sleep for 1 ms, the controller hangs at the first cycle, and if I have them sleep for 4 ms, it runs seemingly stable until I whenever actually press the boot selector button and hangs then. At 10 ms, everthing runs stable.

About #include <task.h>, you're right, when using standard FreeRTOS one is expected to include the header explicitly some way like #include <FreeRTOS/include/task.h>, but with an Arduino library all the files are at the first level, but they are named far too ambiguously for that to be sensible, which probably is why the AVR FreeRTOS library restricts the include to the Arduino_FreeRTOS.h file, which includes all the necessary header files.

As for setup/loop, I see your point about not wanting to run setup1 after setup has completed. Maybe we can find some compromise by adding a weak symbol setup0 that, if present, will be run before the RTOS scheduler is started and that can be used for initialization that absolutely must be run before anything else. I would still very much like to make setup and loop weak symbols, too, and not create the CORE0 task, like you already do with setup1 and loop1, as that task is just wasteful, if loop is not used.

About the idle task I think you misunderstood me.. I did not mean for loop and loop1 both to be called in the idle task, if it's used for that, loop would be enough, and there wouldn't need to be a loop1. But since you used them to provide multicore support, I had suggested something like an idle function, that could be called from the idle task.

As for this being a very un-Arduino config... this is just how any of the FreeRTOS libraries for Arduino work, most of them even explicitly state you're not supposed to call delay(), yield() or anything that might somehow block, and you're not supposed to use loop at all (unless they provide idle task support through it). If you're using an OS, with any microcontroller, and even any computer, you're always supposed to work the OS specific way. I think it's good you're providing a simple, comfortable, Arduino-like way to use FreeRTOS, but it is my opinion that people, who actually want FreeRTOS for its actual multitasking and/or realtime capabilities would be little interested in using that, as it takes away control over stack size and task priority from them, and just wastes the memory for the task and its stack, if unused. So, by making setup/loop weak symbols, everything will just work, if used the Arduino way, but it won't get into the way or waste resources if you actually want to work the FreeRTOS way.

[earlephilhower]

Wow, I guess my idea of Arduino-like and what the other ports are doing are way out of step! It just seemed very natural to have a task per core setup/loop (and one for the USB handler).

Do you think you'd be able to rough out a PR to make it the way you know other Arduino FreeRTOS ports do it? Or, do you have any SMP FreeRTOS Arduino ports I should look at? I think the ESP32 has it's own port and doesn't behave like you're saying (since they need to have WIFI and peripheral tasks), so that's probably not a good example.

Even if not, the includes I can see a simple way to fix it. Now I have task.h (and the other headers) redirected in the src/ dir. It would be a simple thing to remove them and then add the proper, #include ../lib/FreeRTOS-Kernel/... to the base FreeRTOS.h. Let me give that a go as a simple start.

For the crash, can you post some sample code or do some investigation as to what's going in via GDB? I spent far too much time in the guts of FreeRTOS fixing my mistakes (which caused random memory corruption, the most fun kind of memory corruption) so have some idea round the internals now.

[hfellner]

But if you just have one task per core (and furthermore, with the task pegged to the cores), then you don't actually have any advantage from using an RTOS, you could just as well use this Arduino core without FreeRTOS. Using a preemptive multitasking OS allows you to use one task for each function the controller is performing, and solves the problem associated with a central loop function, where everything has to be broken up in state machines, to allow for other actions to be performed while waiting on things to happen. This isn't necessary if each task is dedicated to a specific function the controller needs to perform, and a task can just simply wait/block, while other tasks are still able to run, contributing to less error prone and more easily readable code.

About the way other cores (or rather, libraries) are implementing FreeRTOS for Arduino, I did not mean other SMP cores, but rather FreeRTOS libraries for other cores in general - to my knowledge, there is only one other microcontroller with more than one core and FreeRTOS support for Arduino - ESP32 - but that is a bad comparison, since FreeRTOS is not optional on ESP32 - it always runs on top of it. Also, FreeRTOS for the ESP32 is not based on FreeRTOS SMP, but rather a custom implementation that predates the FreeRTOS SMP branch, and with a different API for SMP specific functionality. (But even the ESP32 specific FreeRTOS example states you're supposed to use tasks, and not the loop function.)

Regarding making setup/loop weak symbols, I am leaning towards a compile option like "Include CORE0/CORE1 default tasks" (enabled by default) rather than making setup/loop weak symbols, since that would lead to successful compilation of an Arduino sketch without a setup or loop function even when not using FreeRTOS, which for a typical Arduino sketch, is a clear error. What do you think?

I've tried different approaches regarding the #include for the FreeRTOS files, but it seems that FreeRTOS itself is meant to be compiled to a library, rather than included by source, as the implementation files misuse #include <...> and #include "..." statements, leading to compilation errors when the header files are not available at the first level. But I've found out I was under the wrong impression that the Includes-directive of the library.properties file allows only that particular file to be included - which is not the case, it just restricts the library to be included in the sketch only via this specific file, and that is exactly what is probably best in this case, as it allows for a subsequent #include <task.h>, but prevents FreeRTOS from being included in the sketch, if some other library also has an include file "task.h". So I'd recommend keeping the library as it is, and just re-add the Includes=FreeRTOS.h directive in library.properties.

I can prepare a PR with the changes I described, that would default to the most Arduino-like way for an easy start with FreeRTOS, but with an option for more fine-grained control.

As for the crash.. that it is dependent on whether the boot selector button is actually pressed in certain situation has led me to believe that the problem is actually an electrical one, rather than a pure software problem, and that it might have something to do with a residual charge or signal slope being too slow on an enable pin (or something like that) after access to the flash memory is restored. So I added a short delay in Bootsel.cpp after re-enabling flash memory access, but before the other core and interrupts are resumed, and this seems to have solved the problem. I have 8 tasks constantly checking the boot selector button and then just sleeping for 0 milliseconds, i.e. switching to the next task without waiting. While this led to an immediate crash in every single case before, this way it has been running stable for almost a whole day, so far - regardless, how many times or how long I press the boot selector button.

As for the length of the delay - my tests have shown that 100 µs is too short, and still causes crashes/hangs sometimes, but 200 µs is enough for it to run really stable. However, if this really is the cause for the problem, this might mean that different RP2040 boards might behave differently in regards to this problem, as different capacitor/resistor values might change the required delay time. My tests were done with a standard Raspberry Pi Pico board.

Lastly - I'm really sorry about the long post.

[earlephilhower]

Lastly - I'm really sorry about the long post.

Thanks for taking the time to make the core better, no worries! 👍

I get your discussion except for one point: the CORE0 and CORE1 tasks now are at prio 4. So, higher prio tasks will always get scheduled ahead of it of course. And on any delay() lower priority tasks can be called (delay == vTaskDelay). It seems to me with this kind of setup you can still get the hard realtime behavior by using prio >= 5. (Note that USB is IRQ based on a 1ms increment so in FreeRTOS mode it's a prio-7 task to mimic that....which may be trouble if you're doing somethign depending on us-level accuracy on core0...)

A simple check shows I was wrong about renaming includes. It's not so easy and would require patching FreeRTOS. It's definitely doable but not as simple as git mv.

BOOTSEL is kind of a HW/SW hack the Pico guys came up with. It pauses all other core0 and core1 operations while executing (which takes a non-trivial time IIRC), so honestly I think you'd not be able to use in any critical FreeRTOS app like you were discussing. So it might not be worth looking into too hard.

[ogatatsu]

Hello
The SMP branch of FreeRTOS has an option to make sem/mutex/queue and sleep of Pico SDK work with FreeRTOS tasks

configSUPPORT_PICO_SYNC_INTEROP
configSUPPORT_PICO_TIME_INTEROP

https://github.com/earlephilhower/FreeRTOS-Kernel/blob/f3612388755827dbc3ac48f40764045f4897986f/portable/ThirdParty/GCC/RP2040/include/rp2040_config.h#L47-L64

but it seems that you need to include freertos_sdk_config.h in your Pico SDK build for this to work.

https://github.com/earlephilhower/FreeRTOS-Kernel/blob/f3612388755827dbc3ac48f40764045f4897986f/portable/ThirdParty/GCC/RP2040/CMakeLists.txt#L27