[En-Nut-Discussion] Runtime library dependencies

Ole Reinhardt ole.reinhardt at embedded-it.de
Fri Sep 28 16:18:04 CEST 2012

Hi Harald,

> Yes, I agree. We should try to keep it compatible. But in the next
> > moment I'm thinking about other tools as well (Keil etc...) we don't
> > have specific support for these tools yet. But it might be a good Idea
> > to get in contact with these companies to get at least mentioned as
> > supported OS. Unfortunately this will take some effort to make NutOS
> > compatible with their tools but also might increase the user base.
> May I remind you, that I was recently looking for someone, who would
> have been able to respond to the request from STMicroelectronics
> regarding Nut/OS support for the STM32?
> http://lists.egnite.de/pipermail/en-nut-discussion/2012-August/013764.html
> Uwe was so kind to post a status to this list, but no one finally
> answered STM's request. Nut/OS marketing is really lousy. ;-)

Yes, sorry, but I don't have any STM32 hardware so did not feel to be
the right person to ask. And further more you did not post any contact
information of the STM32 guys, so I thought _YOU_ would answer them
after getting an overview about the STM32 port from Uwe or Ulrich.

However, I really would like to act as contact person for STM or other
manufacturers, but I don't have the contacts. So feel free to introduce
me and I'd be pleased to talk with them and to do some marketing there.

> > Do we really _need_ the newlib features? I can not remember to use any
> > newlib specific code, at least in the code I wrote. All functions we use
> > are just "normal" libc functions. And if there is any function that is
> > not yet available in our small libc implementation we could think about
> > adding these specific functions as well.
> You're right, in general we are not using newlib specific code.
> But there is an unsolved problem with newlib's dtoa(). The issue is,
> that this function uses newlib's internal malloc, which finally results
> in a call to _sbrk. To solve this dependency, Nut/OS provides a
> simplified crt/sbrk.c, just to please newlib.
> Floating point to ASCII conversions (and vice versa) are typically not
> well implemented. Newlib uses some really ancient code. I's really like
> to have an independent replacement...well...24h per day is not enough.

You say it :) At least sleeping is overrated.




Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting


Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 

More information about the En-Nut-Discussion mailing list