Jon Enz
I would like to keep this out of the core part of the library since it doesn't directly interface with an existing FreeRTOS interface, but I'm open to adding it...
Yes. It's part of the kernel namespace. [ FreeRTOS::Kernel::enterCritical()](https://jonenz.github.io/FreeRTOS-Cpp/namespaceFreeRTOS_1_1Kernel.html#a71df9b3921b7d8d1c25995a750f3609d)
The idea was to put things in the Task class operate on a specific instance of a task or take `TaskHandle_t` as an argument to the FreeRTOS function. Things in...
Because `taskENTER_CRITICAL()` is intended to be called from task context, it may make sense to move it to a protected function of the task class by the same logic as...
> Do you support the ENTER/EXIT critical with a scope_lock sort of class? No, but I would be open to adding some of these implementations in another folder.
FreeRTOS-Cpp is just a C++ 17 wrapper around the existing FreeRTOS functions. When you create task object, the constructor calls `xTaskCreate` and runs the normal FreeRTOS kernel function. https://github.com/jonenz/FreeRTOS-Cpp/blob/5194b2e7cb97d6747761bb80609b87752ec71b5d/FreeRTOS-Cpp/include/FreeRTOS/Task.hpp#L1437-L1443 In...
Yes, the instance of the task object must live somewhere, but there isn't any reason this can't be on the stack of another task if that task is responsible for...
If you want the code to look as similar as possible to the C example, then I agree with @electretmike, use `pvPortMalloc` to allocate the memory from the FreeRTOS heap...
This is something I would probably put in the `Kernel` or a `Kernel::Portable` namespace, but there are a few problems I see at first glance with some of the portable...
@lukasnee and @electretmike please add your review here.