Of course I haven't tried newlib for msp430 since I'm waiting until the
entire toolchain is available in released versions of the required packages
(which I expect won't be until late March 2014 when gcc 4.9.0 is
released). However, I too have found newlib completely unsuitable for
embedded programming on MCUs with less than 128KB of flash.
To that end I split off the string formatting infrastructure from
msp430-libc into https://github.com/pabigot/embtextf about a year ago, and
have been using that effectively on small EFM32 Cortex-M3 devices with the
Mentor Graphics/CodeSourcery GNU toolchain builds. It gets tricky
sometimes to keep all newlib's trendrils from sucking in the universe when
touching anything related to stdio, but if your main focus is printf-style
formatting embtextf will cut newlib's footprint by 20KB. It doesn't
support floating point at the moment, but that's pretty irrelevant to
MSP430 and will probably be fixed if I ever do anything serious with an M4F
device.
I have also heard rumors that ARM folks are working on alternative to
newlib that is suited for true embedded development, but haven't taken the
time to track that down yet.
Peter
On Mon, Jul 8, 2013 at 9:43 AM, Grant Edwards <grant.b.edwa...@gmail.com>wrote:
> On 2013-07-08, Brendan Conoboy <b...@redhat.com> wrote:
> > On 07/04/2013 07:10 PM, Peter Bigot wrote:
> >> I have no information about Red Hat's toolchain other than what's been
> >> announced here, but:
> >>
> >> Red Hat's MSP430 toolchain is entirely unrelated to mspgcc. I am
> unaware
> >> of any information having been provided related to support for libc or
> >> specific MCUs in this new work. While msp430mcu and msp430-libc might
> work
> >> with some fiddling, it's not clear they're needed, I very much doubt
> >> they're the intended solution, and they certainly don't incorporate any
> >> changes to accommodate Red Hat's implementation.
> >
> > There is now msp430 support in newlib:
> >
> > http://www.cygwin.com/ml/newlib/2013/msg00362.html
> >
> > Since we did a clean re-implementation of the MSP port we can't comment
> > on the pre-existing mspgcc library solutions: We really don't know. Our
> > plan is to support and enhance standard upstream infrastructure. For
> > libc this means newlib.
>
> How does newlib compare with the old msp430 libc when it comes to
> size? In the past, when I've tried newlib for embedded work it was
> _huge_.
>
> --
> Grant Edwards grant.b.edwards Yow! Th' MIND is the
> Pizza
> at Palace of th' SOUL
> gmail.com
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
