Hello,

I'm new to FreeRTOS so I apologize in advance if this is a silly question. Are there any plans to support statically allocated memory features (i.e. xTaskCreateStatic) for the FreeRTOS C++ wrappers? There are a number of situations where this functionality can be a benefit. I did not find this functionality in the FreeRTOS C++ V1.6.0 source.

Regards,

Tom Doyle

Hi,

Thats actually might be not an issue. I want to ask why there is malloc instead of pvPortMalloc?
I found it here:

regards
Kamil

Hey! Recently I've started using Linux port to run my application under CI system. The problem appears when I want to stop the scheduler by invoking vTaskEndScheduler. I do this in such a way:

static void testing_task(void *params);
const char testtask_name[] = "Testing";

int main()
{
	xTaskCreate(testing_task, testtask_name, 1024, NULL, 1, NULL);
	vTaskStartScheduler();
	return 0;
}

static void testing_task(void *params)
{
	run_tests();
	// Finish running the scheduler as we want only to run the tests and exit
	vTaskEndScheduler();
}

The problem is that an assertion fails:

Cleaning Up, Exiting.
intercom_plus-freertos_test: /home/user/MyProject/mdw/FreeRTOS/Source/portable/GCC/Linux/port.c:313: TickSignalHandler: Assertion `success' failed.

And valgrind says that he has found a memory leak:

==9224== 272 bytes in 1 blocks are possibly lost in loss record 5 of 9
==9224== at 0x4C2F988: calloc (vg_replace_malloc.c:711)
==9224== by 0x40138A4: allocate_dtv (dl-tls.c:322)
==9224== by 0x40138A4: _dl_allocate_tls (dl-tls.c:539)
==9224== by 0x4E4226E: allocate_stack (allocatestack.c:588)
==9224== by 0x4E4226E: pthread_create@@GLIBC_2.2.5 (pthread_create.c:539)
==9224== by 0x4082FC: pxPortInitialiseStack (port.c:466)
==9224== by 0x401943: prvInitialiseNewTask (tasks.c:1010)
==9224== by 0x40179D: xTaskCreate (tasks.c:808)
==9224== by 0x408EA9: main (tests_local_freertos.c:14)

Do I have to perform any additional steps to gracefully stop the scheduler?

Hi Michael,
as I was looking for a freeRTOS simulation on top of Linux I found your repo, which looked very interesting.
Also the C++ wrappers are a nice gift.

I can compile and run the code within CodeLite.
But the code seems to freeze until I click "Start or Continue Debugger".

I notice 6 threads ( 2 of which are created by using paho.mqtt.c Linux version ), I see that the main task is hanging in :
0 0x00007ffff707e2d1 __pthread_kill /build/glibc-OTsEL5/glibc-2.27/nptl/../sysdeps/unix/sysv/linux/pthread_kill.c 57
1 0x000055555558259d SuspendThread /home/lieven/workspace/freertos-addons/Linux/portable/GCC/Linux/port.c 166
2 0x000055555558372d vPortYield /home/lieven/workspace/freertos-addons/Linux/portable/GCC/Linux/port.c 755
3 0x00005555555799f1 xQueueReceive /home/lieven/workspace/FreeRTOSv10.1.1/FreeRTOS/Source/queue.c 1378
4 0x000055555555ccc2 Mailbox::dequeue /home/lieven/workspace/microAkka/src/Akka.cpp 290
5 0x000055555555eb17 MessageDispatcher::execute /home/lieven/workspace/microAkka/src/Akka.cpp 692
6 0x000055555557f4ab main_task /home/lieven/workspace/microAkka/src/main.cpp 39
7 0x0000555555582d55 ThreadStartWrapper /home/lieven/workspace/freertos-addons/Linux/portable/GCC/Linux/port.c 440
8 0x00007ffff70766db start_thread /build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c 463
9 0x00007ffff6d9f88f clone /build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S 95

Any idea what could be wrong ?
Maybe the combination of a linux specific MQTT ?

Code is partly here : https://github.com/vortex314/microAkka

regards
Lieven

Hello,

I have added your posix port to my codebase because I wanted to do some TDD using GoogleTest.
The first test runs just fine: at the end of the unit tests I can destroy all my tasks and call vTaskEndSheduler().

The problem is that vTaskEndSheduler(), beside stopping the scheduler, it also destroys some variables statically initialized (a pair of mutexes and something else). I've tried to add a new function to initialize again the static variables declared in port.c with the idea of calling it at the beginning of each unit test, without success.

As workaround I could use the GoogleTest --filter functionality to execute each test in a dedicated process, but I don't like this option a lot.

Any idea?

Thanks,
Marco

Hi,

I am trying to create two Thread objects running their own code in parallel. I am using one of the examples with simple threads for g++. Whenever Thread objects do get created as a global ones, then they do run with no issues. The problem is whenever they do get created on the main stack. During context switch their content does seem to get corrupted and filled up with "random" values. I wonder what might be causing this kind of problem? Creating threads globally is not the best option as tasks do get initialized before the main() function gets triggered, way before any MCU hardware initialization in my code and I would like to have them created later on after the system becomes ready for multitasking.

I am using:
STM32F429 MCU
FreeRTOS 10.2.1
arm-none-eabi-g++ 7.2.1

Example code that shows the problem:

class TestThread : public Thread {

    public:

        TestThread(const char* name, int i, int delayInSeconds)
           : Thread(name, 100, 1),
             id (i),
             DelayInSeconds(delayInSeconds)
        {
            //
            //  Now that construction is completed, we
            //  can safely start the thread.
            //
            Start();
        };

    protected:

        virtual void Run() {

            while (true) {

                TickType_t ticks = Ticks::SecondsToTicks(DelayInSeconds);

                if (ticks)
                    Delay(ticks);

            }
        };

    private:
        int id;
        int DelayInSeconds;
};


/* Declaring them as global objects works */
TestThread thread1("Thr_Name_1", 1, 1);
TestThread thread2("Thr_Name_22", 2, 2);


int main (void)
{
	/* Declaring them as local objects triggers Hard Fault due to memory corruption */
	//TestThread thread1("Thr_Name_1", 1, 1);
	//TestThread thread2("Thr_Name_22", 2, 2);

    Thread::StartScheduler();

    return 0;
}

Hi! It's me again with problems with valgrind.

When I run an application under valgrind the application hands on the first xTaskCreate. I debugged the port code and noticed that the code stalls here:

portSTACK_TYPE *pxPortInitialiseStack( portSTACK_TYPE *pxTopOfStack, pdTASK_CODE pxCode, void *pvParameters )
{
    ...
        pthread_mutex_unlock( &xSingleThreadMutex );

        while ( xSentinel == 0 );
    ...
}

xSentinel is set inside SIG_SUSPEND signal handler.

Does valgrind spoil somehow the use of signals?

Would it be possible to make the Wait method in the Thread class static so that condition variables could be utilized by threads not instantiated via the Thread class?

In your ReadWriteLock you should check the return values of your xSemaphoreTake() calls to be prone against spurious wakeups. For example if you call vTaskAbortDelay() to wake up a sleeping task from another, it will also cancel your waits on the semaphore. Unfortunately that behaviour is not really documented, but I've ran into it - took me a while.

I do it like so

while (xSemaphoreTake(sem, portMAX_DELAY) != pdTRUE) {}

Could you make a quick hands-on example to start with RTOS Linux port simulator on Eclipse cdt ?

Called at this point, this returns the ID of hSigSetupThread which is different from the MainThreadID.

Breaks vTaskSchedulerEnd() as the actual main thread is never woken.

I am trying to apply your c++ code to windows msvc demo of freertos without no luck. Do I supposed to rewrite sections like creating thread, semaphores etc. ?

I really miss a guide for how to integrate the addons with freertos on linux, compile and run a demo. I have tried to build Linux/Demo/Linux_g++_queues_simple_producer_consumer but get the error:

make: *** No rule to make target 'event_groups.c', needed by 'event_groups.o'

Since I'm trying to develop the application on Linux I use William Davy's port (Posix GCC Eclipse FreeRTOS 6.0.4 Simulator). It does not have the module event_groups.

... after reading the first pages of the FreeRTOS book I realize what is involved in setting up a FreeRTOS project for a particluar port and compiler.

BTW, tremendous work you have done with the addons!

/AJ

I would like to have this wrapper available for Arduino platform. It would be very interesting to have Arduino + FreeRTOS + freertos-addons. We already have Arduino + FreeRTOS and FreeRTOS + freertos-addons. All we need is to glue them together.

hi. Dear expert:

I tried to run the demo freertos-addons/Linux/Demo/Linux_g++_dynamic_tasks on NXP frdmk64f.
But I found when the dynamic CPP task start in another CPP task, it will report HardFault_Handler error.

Can I run the linux example on frdmk64f?

Thanks.

[/c/Source/include/version.h] is still at 1.1.0
[/c++/Source/include/version.hpp] is still at 1.5.0

How can I run a thread from another thread ?

Hello. Are your wrappers and your Linux port compatible with FreeRTOS 10.2.1 or we must use them with 10.0.0 version?

I think it would be a safer and more C++ style usage of the Queue's to take a template argument T and a runtime queue-size as the only constructor argument.

Something like:

struct MyEvent {
  uint32_t id;
  uint16_t element1;
  uint16_t element2;
};

...

cpp_freertos::Queue<MyEvent> event_queue(5); // Event queue that holds 5 MyEvents

The rationale here is the specialization makes the type that is inside the queue well known, and functions that return objects can now take T& instead of pointers, preventing null pointer errors at compile time.

Hi Michael,
1rst of all: nice work on this c++ wrapper stuff. Really good job. Thx for sharing this to the world!! Hopefully I can help to improve. ;-)

All of the freeRTOS handles (semaphore, mutex etc.) are declared as protected for "non application" use according to your doc. Is there a special reason for this?

Background: freeRTOS supplies vTraceSetQueueName(), vTraceSetMutexName() and vTraceSetSemaphoreName() methods to set the trace items names. Really helpful for using TraceAnalyzer from percipio.

So making this items public would get access to this properties.
Of course also a possible solution would be to implement a public "get()" method for the private pointers e.g.

SemaphoreHandle_t *get_Semaphore() {return &handle}

The application could then use

vTraceSetSemaphoreName(MySem->get_handle(), "MyName");

How do you think about this one? Would improve this nice wrapper classes from my kind of view.

Cheers

Sebastian

I wish to use your wrappers in my project. I might need to make changes to the wrappers and the API. Can you please provide an open source license in the project?

...as described here: https://www.freertos.org/Static_Vs_Dynamic_Memory_Allocation.html ?

thanks!

Hi Michael,

I had a question about the license used by the Linux port, now that AWS has released FreeRTOS under the MIT license. I noticed that you had started modifying the headers for the C++ wrapper to reflect the MIT license, but the Linux port still remains under the old GPLv2.

Are there plans on relicensing the Linux port under the MIT license?

Also, your README still indicates that the C++ wrappers are GPLv2 licensed, should that be changed to reflect the use of the MIT license?

i am low level to use freertos, so i can not do this job. but i think this is very good function

I didn't see an examples of using GiveFromISR() for a binary Semaphore within an interrupt... I would love to see how to handle the parameter pxHigherPriorityTaskWoken (for ARM) and how to handle the Semaphore object in a "C" ISR.

Michael,

Thanks for the continued support of your POSIX/Linux port of FreeRTOS. I was browsing the new source for FreeRTOS v10.4.4 and realized a NEW "official" Third-Party Posix port is being tracked. Here is documentation that seems updated: https://www.freertos.org/FreeRTOS-simulator-for-Linux.html

And here is the source: https://github.com/FreeRTOS/FreeRTOS-Kernel/tree/main/portable/ThirdParty/GCC/Posix.

I'm wondering what your thoughts are on this port. There seems to be a lot of similarities both in port.c and portmacro.h.

Thanks!

I may be missing something, so this is a question, not a bug. Say I have the following program:

#include <stdio.h>
#include <iostream>
#include "FreeRTOS.h"
#include "task.h"
#include "thread.hpp"
#include "ticks.hpp"
#include "semaphore.hpp"

using namespace cpp_freertos;
using namespace std;

class RunForeverThread : public Thread {
  public:
    RunForeverThread() : Thread("RunForeverThread", 100, 1) {
      i = 0;
      Start();
    };
  protected:
    virtual void Run() {
      while(1) {
        cout << i++ << endl;
      }
    }
  private:
    int i;
};

int main (void) {
  RunForeverThread rf_thread;
  Thread::StartScheduler();
  return 0;
}

void vAssertCalled( unsigned long ulLine, const char * const pcFileName )
{
    printf("ASSERT: %s : %d\n", pcFileName, (int)ulLine);
    while(1);
}

unsigned long ulGetRunTimeCounterValue(void)
{
    return 0;
}

void vConfigureTimerForRunTimeStats(void)
{
    return;
}

extern "C" void vApplicationMallocFailedHook(void);
void vApplicationMallocFailedHook(void)
{
  while(1);
}

When I run this, it starts printing incrementing numbers but then just stops. And it doesn't stop at the same number each time...it stops at anything from 221 to 1709 (the lowest and highest I've gotten over 25 tries). By "stop" I mean threads seem to halt or get stuck, but Thread::StartScheduler() doesn't return, so I'm assuming the scheduler is still running.
I tried using GDB, but to be honest, I'm not that good with GDB and I could only so far find that 4 threads were being created and a single thread was getting stuck trying to write to IO (the other threads were waiting:

  Id   Target Id         Frame 
  1    Thread 0x7ffff7fea740 (LWP 4302) "main" do_sigwait (sig=0x7fffffffe2c0, set=<optimized out>)
    at ../sysdeps/unix/sysv/linux/sigwait.c:64
* 2    Thread 0x7ffff6f4f700 (LWP 4306) "main" 0x00007ffff7b64449 in std::ostream& std::ostream::_M_insert<long>(long) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
  3    Thread 0x7ffff674e700 (LWP 4307) "main" do_sigwait (sig=0x7ffff674d80c, set=<optimized out>)
    at ../sysdeps/unix/sysv/linux/sigwait.c:64
  4    Thread 0x7ffff5f4d700 (LWP 4308) "main" do_sigwait (sig=0x7ffff5f4c74c, set=<optimized out>)
    at ../sysdeps/unix/sysv/linux/sigwait.c:64

I'm running in a Vagrant box, Ubuntu 16.04. If there's anything else you think I should try, let me know. Or if there's something I'm totally missing, I'd love to learn.
I've tried so far (and doesn't help):

• Putting in a small delay inside the while loop
• Using cout << flush(). Just a hunch that maybe the IO buffer was overflowing....idk
• Checking if vApplicationMallocFailedHook was being called using breakpoints and/or print-outs. It isn't being called (at least I think).
• Trying to run multiple threads. All the threads halt at some point (but usually at different points per thread).
• Trying to increase the stack size. This has no effect on when the thread halts (aka, the threads don't halt at a larger number given a larger stack size)

Any ideas on further tests, or possible problems (especially with my code) would be really appreciated. If you need to to run some tests, just let me know!
Thanks for all the help!

Hello Michael,

I hope I find you and your well.

I'm teaching Embedded Systems at university UAB in Barcelona, Catalonia.
Due to the lockdown because of the COVID-19, I've force to redesign my Labs to be virtual They were based on FreeRTOS running in different HW platforms (Atmel & SiLabs mainly).
Thanks to your Linux porting, I've been able to change to virtual labs and my students can still work on FreeRTOS without having the physical HW.
More than 40 students are learning FreeRTOS in my course using your work.

So this issue it's only to thank you for the work and for to publish the repo.

Bests regards,

Màrius

Michael,

First off, thanks so much for maintaining this port! I like this better than this one at https://github.com/megakilo/FreeRTOS-Sim (which also supports newer v9.0, etc) since it seems to be a little more sane with pthread calls. I just wanted to include a small bit of code that worked for me and wondered if you saw anything wrong with it.

In port.c you have the block near line ~360 commented out - which as you noted, changes the thread's scheduling policy (main thread primarily, but all child threads by association) via pthread_setschedparam. I change it to the few lines below:

int iResult;
struct sched_param iSchedulerPriority = { 1 };

iResult = pthread_setschedparam(pthread_self(), SCHED_RR, &iSchedulerPriority);
configASSERT(iResult == 0);

The suggestion you had about using SCHED_FIFO is too greedy I believe. I couldn't get it work work at any of the prios listed in chrt -m. SCHED_RR on the other hand makes more sense conceptually and happened to work without any other changes. Also using pthread_getschedparam would make no sense since by default, via SCHED_OTHER, the priorities are out of range of SCHED_FIFO and SCHED_RR - see chrt -m. Maybe just forcing the prio low would be fine (or making it configurable).

Anyway, not many people have a use for changing the scheduling policies, but it makes me feel better that things seem to be more preemptive ;) .

Hi,
Thanks, for making freertos-addons. I would have tried and had even more trouble without this project.
I tried implementing a very basic program using freertos-addonons. It tries to set up a timer task that toggles a GPIO. I'm finding that I get an exception the first time the timer expires. TimerCallbackFunctionAdapter tries to call the Run() method, but it is jumping to a random location in memory. So far, I've been able to tell that it seems to be derefencing a bad pointer to the vtable. Please take my analysis with a grain of salt; I'm only getting this familiar with the internals of compilers while debugging this.
My biggest suspicion is this: The derived object "twiddler" in my code appears to be in the stack right before I call Thread::StartScheduler(). I can call it a couple of ways and watch it behave normally. My guess is that "twiddler" is no longer in stack when the timer expires.
I looked in your Timer example to see if I'm naively missing some qualifier while instantiating the object or defining the class. Nothing jumped out at me. As a follow-on comment, I'll post some details about my code.
Do you see what I may be missing here? Do you think this is a latent bug in the C++/C interface where the compiler is unaware of continued use of the object?

I am wondering how to use the work queue in the right way. I would be great if you can share some mini example.

many thanks
mathias

Hi Michael,

It is a great job what you have done! I have used your FreeRTOS Wrapper to test and with some foo project (hobby) and I have one question, do you intend to make a wrapper for EventBits?

What's the status of FreeRTOS C++ wrappers? Has it completely implemented FreeRTOS?
I see the project is not updated for a while and there are pull requests that have remained open.

I had a look at the source code and I think this is a great wrapper, thanks for writing and sharing it! I'd like to utilise it on a modified version of FreeRTOS. I took the simple task example and it has been compiled successfully but when it comes to run on an ESP32 chip it crashes with the following output:

Testing FreeRTOS C++ wrappers
Simple Tasks
configMAX_TASK_NAME_LEN = 16
C++ Thread names can be greater than 15 characters long.
CORRUPT HEAP: multi_heap.c:429 detected at 0x3ffb9f5c
abort() was called at PC 0x40086a37 on core 0
0x40086a37: multi_heap_assert at /Users/ist1/esp/esp-idf/components/heap/multi_heap_platform.h:54
(inlined by) multi_heap_malloc_impl at /Users/ist1/esp/esp-idf/components/heap/multi_heap.c:429
...

I guess this might be due to differences in singe and multi core versions of FreeRTOS. Can you share your thoughts on this? I'm not an advanced C++ developer. Thanks.

We're evaluating the freertos-c++ lib for possible usage. Can you explain why Tasklet involves a Mutex? That doesn't seem to be the typical usage pattern in the underlying FreeRTOS C implementation.

The header files with the version numbers is out of sync with the tags / releases: C++ Wrappers 1.6.0 <-> header file 1.5.0

Hello,

This is less of an issue and more of a question. Is there any way you could also post the source code of the FreeRTOS library you're using? Many of the function names differ from my version, but I want to port over to your version as its fantastic! Thanks for all this great work, I really appreciate the time put into this.

-Thomas

Hello,
First off, thank you so so much for all the work you've put in - this library is AMAZING. Saved me so much time, and it's so simple to use.
However...I can't seem to get Critical.hpp to work. First, there seems to be a semicolon on line 120 that shouldn't be there...just a guess, but I could be wrong. Once I delete that, I still can't get it to build, with errors such as:
portmacro.h:133:71: error: too few arguments to function ‘void vPortClearInterruptMask(long int)’
#define portCLEAR_INTERRUPT_MASK_FROM_ISR(x) vPortClearInterruptMask(x)

Any ideas on what's going on or what I should look into to fix it?

Hi,

many thanks for the great work!

Any chance to get the simulation work under MacOS?

regards

spachner

Thanks for the great work!
I'd like to use the C++ Wrappers to start a new project on nRF52840 together with freertos 10. For a first test i wrote an example similar to Linux_g++_simple_tasks:

class led_toggle_task : public Thread {
    public:
        led_toggle_task(uint32_t led = 0) :
            Thread(1024, 0),
            led_number(led)
        {
            Start();
        };

    protected:
        void Run()
        {
            while (true) {
                Delay(70);
                bsp_board_led_invert(led_number);
            }
        };

    private:
        uint32_t led_number;
};

int main(void)
{
    ret_code_t err_code;

    /* Initialize clock driver for better time accuracy in FREERTOS */
    err_code = nrf_drv_clock_init();
    APP_ERROR_CHECK(err_code);

    /* Configure LED-pins as outputs */
    bsp_board_init(BSP_INIT_LEDS);

    /* Create task for LED0 blinking */
    led_toggle_task task1(1);

    /* Start the FreeRTOS scheduler */
    Thread::StartScheduler();

    while (true)
    {
        // this should never be reached
    }
}

The project compiles. However, the evaluation of the member led_number inside Run() does not yield the expected result (should evaluate to 1). I can write and read the value but initially it does not have the value which is stored into the variable by the constructor.

Declaring the variable as static and and initializing it in the global context yields the correctly initialized variable.

Also, declaring Run() in the public section and calling task.Run(); instead of Thread::StartScheduler(); results in a correctly initialized member led_number. The same holds for moving TaskFunctionAdapter() into the public section and invoking Thread::TaskFunctionAdapter((void*) &task1); instead of Thread::StartScheduler();.

My assumption is that when called by freertos, the binding between the variable led_number and its correct memory address somehow gets lost. But I'm not really sure what happens here...

It would be great if you could give me some hints on what is going wrong here.

The code is compiled using arm-none-eabi-c++ with -O3 -g3 -DCPP_FREERTOS_NO_CPP_STRINGS -DCPP_FREERTOS_NO_EXCEPTIONS -mcpu=cortex-m4 -mthumb -mabi=aapcs -Wall -Werror -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -fno-strict-aliasing -fno-builtin -fshort-enums.

Hello, I'm trying to add these addons to platformio which is a embedded cli for building and dependency management. I already forked this project and tried integrating it, but I need help, as there are some issues that I cannot solve.
https://github.com/DanaDynamics/freertos-addons