cancel
Showing results for 
Search instead for 
Did you mean: 

'mutex' in namespace 'std' does not name a type

casaneva
Associate

Hi all,

Very new to STM32, day 2 now, managed to get some UART output and call into C++.

However when I try to use standard C++11 threads I get this error "'mutex' in namespace 'std' does not name a type". I believe this is bc arm-none-eabi-g++ is configured with --disable-threads (checked with "arm-none-eabi_g++ -v").

Any way to get (standard) threading support? Should I try to rebuild the toolchain with --enable-threads?

1 ACCEPTED SOLUTION

Accepted Solutions

Perhaps stick with the tools which are supported. Typically, FreeRTOS is used for multiple tasks which has its own mutex. Probably not the answer you want. In general, higher level OS functions don't operate on an MCU the way they do on a PC. I suspect the memory overhead in even creating a toolchain to support standard C++ std::thread/mutex would be prohibitive.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

7 REPLIES 7
TDK
Guru

Did you #include <mutex>?

Might not be in the reduced C++ implementation. You can change to the standard implementation in project properties.

Embedded C++ often implement only a subset of the full spec due to limited resources.

If you feel a post has answered your question, please click "Accept as Solution".
casaneva
Associate

Yes, ofc I did. Checked with uVision and CLANG, also no threading. Doesn't even allow the include.Tried the FreeRTOS mutex example and converted it to C++, no threading. The code works fine on other platforms including ESP32, and the FreeRTOS specific stuff also works fine on my U5 board, so limited resources is a poor excuse imo.

It would save me a lot of time and cursing if someone could share or point me to a prebuilt toolchain that does have threading enabled.

Not sure what setting is needed to switch from reduced to standard C++.

The setting is in project properties. This is for C. If you have C++ enabled, there will be a page for C++ as well.

TDK_0-1734123963702.png

Might want to be more specific about your case. "STM32" encompasses thousands of chips in wildly differing capabilities. In particular settings for MPUs vs MCUs will be quite different.

If you feel a post has answered your question, please click "Accept as Solution".

Thanks TDK, but unfortunately switching it to standard c++ didn't make a difference. Still no std::thread and friends.
I'm using a NUCLEO-U575ZI-Q board with STM32U575ZIT6Q MCU. Willing to switch to another MCU if it supports standard threading, but I think this is an issue for the entire STM32 family.


@casaneva wrote:

Willing to switch to another MCU if it supports standard threading


This would be  a property of the toolchain - not the target microcontroller.

Perhaps stick with the tools which are supported. Typically, FreeRTOS is used for multiple tasks which has its own mutex. Probably not the answer you want. In general, higher level OS functions don't operate on an MCU the way they do on a PC. I suspect the memory overhead in even creating a toolchain to support standard C++ std::thread/mutex would be prohibitive.

If you feel a post has answered your question, please click "Accept as Solution".
casaneva
Associate

Yep, looks like I'll have to go with the FreeRTOS equivalents. Luckily I already have a thread abstraction layer.

I disagree with the prohibitive overhead though, as I mentioned standard threading works fine on Espressif devices, which are even more constrained. My guess is they didn't implement it since it wouldn't work without FreeRTOS...

Anyway, thanks for your input TDK, and others.