to_string() doesn't work

sstaub

Well-known member
the std string library function to_string() don't work, "not declared in this scope"
Teensy to_string().jpg
 
String(zahl) ? why are you using strings? use character arrays, uses less resources without the heap destructions
 
Here the code:
#include <string>
using namespace std;

uint8_t zahl = 10;
string zahlString;

void setup() {
zahlString = to_string(zahl);
}

void loop() {

}

I don't want to discuss the use of String, string or char arrays. It is simple why doesn't it work, it is standard c++11 function
 
AFAIK you need to use at least GCC 6 for this. I just tested your code with gcc-arm-none-eabi-9-2019-q4. And it compiles without issue. There are a few discussions about this issue on Stackoverflow.
 
Is there a simple way to change the compiler version? And why does Teensy use an old version? Normally I work on PlatformIO.
 
https://github.com/TeensyUser/doc/wiki/GCC

Scroll down to "Switching between different toolchains". I'm usually using VisualTeensy where switching is done by simply changing the setting for the GCC folder. If you find out how to do it in PlatformIO it would be great if you could add some info to the WIKI
 
Tried with following .ini on platformIO
Code:
[env:teensy41]
platform = teensy
board = teensy41
framework = arduino
platform_packages = toolchain-gccarmnoneeabi@>1.90000.0

getting following result
Code:
Linking .pio/build/teensy41/firmware.elf
/Users/sstaub/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld: cannot find -larm_cortexM7lfsp_math
 
I want to try it for Teensyduino app, but the wiki doesn't help me, I'm working on macOS. The path for Arduino/hardware/tools is different to windows.
On mac there is a user folder Documents/Arduino/hardware which is empty and in Library/Arduino15/packages I can't find the files for Teensy.
Maybe the Teensyduino IDE have another path on mac then the Arduino IDE.
 
Followed the wiki and changed to gcc-arm-none-eabi-9-2019-q4. No luck, I get always
Code:
cannot find -larm_cortexM7lfsp_math
 
Looks like you didn't copy the libraries to the correct path? Unless the GCC folder structure is different for a MAC, they need to go into the MAC equivalent of this WIN10 folder:

...\gcc-arm-none-eabi-9_3-2020-q2\arm-none-eabi\lib

Screenshot 2021-03-28 082935.jpg

Activating verbose output in Arduino and PIO should help finding the correct folders.
 
Last edited:
The file libarm_cortexM7lfsp_math.a is missing in gcc versions higher than 1.5 and must manually copied. wtf
 
The file libarm_cortexM7lfsp_math.a is missing in gcc versions higher than 1.5 and must manually copied. wtf

IMHO, If it is not there it should not be used!
the fact that Arduino/Makefiles are not adapting to changing gcc is not the problem of gcc
maybe there is an equivalent library, or installation of toolchain is not complete.

BTW, even if you abbreviate to three letters, it is NOT cool to use insults on a technical forum.
 
any news about change

I can comment on this, but it's not going to be the answer you want.

My 2 top priorities are flash encryption and debugging NativeEthernet. Both are large, daunting projects. I'm not even going to consider any toolchain change until both of those are done.
 
The relatively old compiler still works quite well. It may be lacking some newer C++ features and may miss a few optimizations in -03 mode, but we know it works and gives very stable results. A huge code base has been thoroughly tested with this specific old version.

So far, no newer version offers improved code speed. Frank and others have tested performance and found almost no improvement and in some cases slightly slower generated code by newer versions.

Every toolchain upgrade comes with substantial risk, usually by exposing subtle bugs in various libraries which never mattered under the old compiler. While that's technically not the new compiler's fault, the practical reality is upgrading the toolchain requires a lot of beta testing. If old code breaks with the newer toolchain, it all needs to be updated before we can make the switch in a stable release.

All that effort needs to be balanced against a huge list of other features, like improving MTP, many audio features people want, more USB host drivers, non-blocking I2C, and so on. While you probably feel these specific C++ features are important, in terms of making decisions where to invest limited dev time, those sorts of major features so many people want almost always take priority over messing with the toolchain.

The net result is we tend to stay on older but highly stable toolchains, especially when newer ones produce slower or at best the same performance compiled code.
 
So, regarding the compiler itself: I have seen that it sometimes generates faster code, but sometimes not. In total it comes out to about the same speed.
What I like is that it generates a lot more warnings. Many of these are now also fixed in the libraries and teensy core.
The stricter checking also produces (I'm just assuming) more "accurate" code that is closer to what the programmer tells GCC. Maybe this is the reason why some is compiled to slower code. Just a guess!

The old toolchain has bugs that are now fixed. Especially "bad" I find the newlib sinf(x)/cosf(x) bug which leads to very slow calculations when x is large. There are workarounds for this - or the corresponding CMSIS function.
This is fixed in newer versions. Probably new bugs were introduced for it. That's just the way it is. Old bugs are fixed and there are new ones.

I use GCC10 as "default" and have not had any bad experiences so far.
Besides, a lot has been done to C++. I personally haven't missed anything yet, and honestly - to_string() and similar are no reason to panic now.

At the end of the day I think that an update of the toolchain is not urgent. But maybe you shouldn't wait for years with it.
 
I use GCC10 as "default" and have not had any bad experiences so far.

Well.. a few minutes later:
Code:
Exception 0x8b04488b 0xccccccd5 0x8b64cccc 0x58004012
PC=0x58004012

runtime: unknown pc 0x58004012
stack: frame={sp:0x3eba5800, fp:0x0} stack=[0x12448000,0x1244a000)

runtime: unknown pc 0x58004012
stack: frame={sp:0x3eba5800, fp:0x0} stack=[0x12448000,0x1244a000)

eax     0x0
ebx     0x58003ffd
ecx     0x3ffed555
edx     0x55555555
edi     0x99999800
esi     0x99999999
ebp     0xbc084000
esp     0x3eba5800
eip     0x58004012
eflags  0x40088265
cs      0x57d93eba
fs      0xb800ffff
gs      0x0
C:\Arduino\arduino-builder gab 2 zurück
Fehler beim Kompilieren für das Board Teensy 4.1.
a GCC 10 crash ;)
 
Back
Top