cancel
Showing results for 
Search instead for 
Did you mean: 

Are there any plans to integrate Picolibc into the GCC toolchain?

Scotty55
Associate III

It has many advantages over newlib and eliminates dynamic memory usage for printf and scanf of floating point data.

4 REPLIES 4

What's stopping you from linking whatever libraries you want?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Scotty55
Associate III

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?

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Scotty55
Associate III

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?