FreeRtos stopss logger Stream

[brinzebuah]

Board: Nucleo F439ZI
I have a class which prints strings via the modm logger. As soon as i add a Mutex as an Class-Attribut I receive with hTerm only the first letter of the String, even if i not use the Mutex at all. If I initilazie the Mutex with an nullPtr I receive the whole string.
Why is this happening?
I'm a FreeRtos Noob, so i'm happy for every input.

Class "testMutex.cpp" :

#include <modm/board.hpp>
#include <modm/processing.hpp>

class TestMutex
{
public:
    TestMutex() = default;

    void
    hello()
    {
        modm::log::debug << "Welcome to Debug Stream example modm" << modm::endl;
    }

private:
    modm::rtos::Mutex mMutex;
    int mValue;
};

main:

#include "testMutex.cpp"
#include <modm/board.hpp>

#undef MODM_LOG_LEVEL
#define MODM_LOG_LEVEL modm::log::DEBUG

int
main()
{
    Board::initialize();
    TestMutex helloMutex;
    helloMutex.hello();
}

[salkinium]

Probably best to start with this example of FreeRTOS integration in modm.
Here's another example of using FreeRTOS without a heap.
Here's also an example of using the FreeRTOS UART queues introduced in #1156.

Here you can find all FreeRTOS examples.

[brinzebuah]

I Found the problem in the modm::platform::Usart3::write(uint8_t data) methode. As soon as the UsartHal3::isTransmitRegisterEmpty() is false, the buffer gets filled. But the Interrupt, which should empty the txBuffer will never be activated, as soon as I initilazie a Mutex anywhere.
My solution was to add a new Function emptyBuffer() to the Usart3, which does the same as the MODM_ISR(USART3) Interrupt. It enables the possibility to empty the Buffer without an ISR, and switch it into a Thread if needed. I don't really now how this ISR works and if i disablede/acknowledged all of them. Could you give me some feedback, if this is a possible solution or opens new problems? And where should I disable/acknowledge the ISR?

Usart3::emptyBuffer()
{
	while(!txBuffer.isEmpty())
	{	
		if (UsartHal3::isTransmitRegisterEmpty()) {
			UsartHal3::write(txBuffer.get());
			txBuffer.pop();
		}
	}
	UsartHal3::disableInterrupt(UsartHal3::Interrupt::TxEmpty);
	UsartHal3::acknowledgeInterruptFlags(UsartHal3::InterruptFlag::OverrunError);
}

[salkinium]

Are you using the FreeRTOS UART queues?
I'm not super familiar with FreeRTOS (or the UART code), I'm using NuttX at work, so I cannot tell what the potential issues are off the cuff.

Tbh, if you're looking for a C++ RTOS, modm is not going to make you happy, it was not designed with that in mind. We integrated FreeRTOS to be able to schedule "long running" tasks (historically an A* route planner) in a background thread while the main tasks are scheduled cooperatively using Protothreads or Fibers. So the peripheral drivers are all polling based, thus incompatible with RTOSes, which are event based.

[brinzebuah]

No i use the Logger, which is implementet directly with Borad::initialize().
Could the polling based thing be a reason, why Multithreading don't work? When i only use the main to initilaize Threads and start the scheduler, it only runs for 1 or 2 rounds, than i get an assertion error or end in a deadlock.