2023-06-11 08:10 AM
It has many advantages over newlib and eliminates dynamic memory usage for printf and scanf of floating point data.
2023-06-11 09:15 AM
What's stopping you from linking whatever libraries you want?
2023-06-11 10:17 AM
So far as understood some discussions, thread level storage and locking has to be integrated with the operating system, e.g. FreeRtos or Azure/ThreadX. How do I do that with STs RTOS implementations?
2023-06-11 10:31 AM
For TLS that would be why you'd use the heap or stack rather than statics.
For context you'll have do that at a thread level, so yes the OS and perhaps at a register one too.
You could perhaps use a resource pool rather than the heap, but you'd need to guard against leaks.
2023-06-11 11:08 AM
Thank you for your response, but maybe I should explain my actual problem.
I need to implement a Json RPC interface listening to several communication channels. It should be able to handle floating point numbers, or we have to scale all data to integer which is here a rather complex problem.
The Json C++ library uses finally - of course - the low level C library functions to generate and parse strings and numbers. Newlib has a really awful float print and scan interface which uses dynamic memory. Picolibc is much better and doesn't use dynamic memory at all.
In both cases I need locking, because several threads are necessary to handle the communication. Newlib does this with the well known ******** code, and I am still not convinced that the actual ST toolchain provides a bullet proof implementation. Picolibc uses native Thread Level Storage and should avoid these problems.
Now, what do you recommend?