My brand new NANO 33 BLE does not accept the standard libraries "ltoa (...)" and "dtostrf (...)". This is not a problem for the standard Arduino types UNO and NANO. But compatibility seems to be a problem for these new types.Where are manual changes necessary?Or where are these libraries hidden?
These functions are not standard parts of the C++ language. They were nonstandard functions provided by avrlibc, which was for the original AVR-based Arduino boards like the Uno. Because these functions were widely used in Arduino code, Arduino usually attempts to provide them in the non-AVR cores as well.
To get dstrtof, you need to add this line to the top of your program:
As you might guess from the path, the use of dstrtof is deprecated.
Although there is a declaration of ltoa in the Arduino nRF528x Boards core at api/itoa.h, which would make you think you could use ltoa by adding the line:
there is no definition of this function. This even breaks parts of the String class. I’ll submit a bug report to them about that.
I think the standard way to accomplish these things is sprintf:
The reason why avrlibc provided alternatives to sprintf for these common usages is because sprintf has a lot of overhead and the AVR microcontrollers are fairly resource limited. With the more modern microcontrollers like the nRF52840 of your Nano 33 BLE that is less of a problem.
The bug report for ltoa:
to : Thank you very much for this very helpful info. Yesterday I used the longer includes and ended up with the unknown ltoa in the linker process.The two functions are part of a “benchmark” I want to run for some NANO variants. Now I will wait for the ltoa correction.
Try changing ltoa to utoa.
itoa and utoa are indeed available already. I'd think itoa would be a more equivalent replacement for ltoa than utoa, since they are both for signed data types. I guess an int and a long are both 32 bits on the Nano 33 BLE, so the two are functionally the same.
And the problem has already been fixed. Pretty impressive response time, considering I reported it on the weekend!
The fix isn't publicly available yet, but at least we know it's in the pipeline to be in the next release of Arduino nRF528x Boards.
OK, the fix is now publicly visible if you're curious, though it's not yet available in a release version of course: