Using Newlib With Stellaris Launchpad


[Brandon] is taking us further down the rabbit hole by demonstrating how to use newlib with the TI Stellaris Launchpad. This is a nice continuation of the framework he built with his post about using GCC with ARM hardware. But it is most certainly one level of complexity deeper than that initial article.

Using newlib instead of glibc offers the option of compiling C code that includes system calls common when coding for computers but which are rare in embedded systems. Using something like printf is generally avoided because of the overhead associated with it. But these processors are getting so fast and have so much RAM that it may be useful in certain cases. We briefly thought about implementing malloc for creating a linked list when working on our STM32 snake game. [Brandon’s] work here makes the use of that command possible.

The process starts by adding labels for the beginning and end of the stack/heap. This makes it possible for functions to allocate memory. After taking care of the linker script changes you must implement a few system call functions like _sbrk.

20 thoughts on “Using Newlib With Stellaris Launchpad

  1. H.A.D. has some hard-on for the Stellaris Launchpad, so many articles about it… ok, I’ll bite… how does this board fair against other prototyping solution and why should I buy one over an arduino, raspberry pi, DE0-nano or papilio one?

    1. That’s a pretty loaded question. You should buy a Stellaris Launchpad over those others if it’s a better fit to your project, or because you want to learn about the Stellaris chips.

      If you’re able to make an informed choice between the Arduino, RasPi, DE0-nano and Papilio one, you had ought to be able to look at the specs and pricing on this launchpad and come to your own conclusion.

          1. Mine took about 2+ months but shipped to the UK just over a week ago. I ordered right before the cut-off for the pre-order.

            Mine shipped with the wrong firmware, but TI were extremely helpful in sorting that out. Works like a charm now.

    2. Id say the reason its so popular is that its the cheapest (by a fair amount) and easiest to setup ARM dev board on the market.
      Stellaris = ~$13 (Arm Cortex-M4)
      > A little more complex than the arduino
      > But you get a lot more horsepower
      > The comparable Arduino is the Due, its $50 and out of stock in most places, and doesnt have a FPU (? I think, its only a M3) or DSP extensions
      Arduino = ~$30 (ATmega328)
      > Very easy to use
      > Not a lot of processing power
      > Only 8 Bit
      RaspPi = ~$35
      > If you can find one
      > Most easily/commonly used for running linux
      > Not as open, more difficult to setup bare metal toolchains
      DE0 & Papilio one = ~$50
      > these are FPGAs, so its kinda apples to oranges

    3. I peruse the TI message boards pretty often, and I think that is a topic that addresses this pretty well (especially Andy Neil’s comments about three posts in).

      The long and short of it is that you should buy one if it fits the needs of whatever project you’re working on. Arduino boards, the Stellaris Launchpad, raspberry pi, etc.. all contain different hardware that makes them good for different purposes. Heck, even looking at TI products alone, you’ll find the MSP430 line better than the Stellaris line at somethings, the C2000 line best for other things. It all comes down to what you’re trying to do :)

  2. Again with the usual ignorance?
    I dare you to get glibc woking on the launchpad.
    No, most default (gcc based) embedded toolchains don’t have a standard C library.

    First you build a stage one gcc – that’s bare C compiler without std C library. This is what most embedded toolchains end up being.
    Then, using that, you build your native standard C library and other support stuff
    And finally, using that, you rebuild gcc again so that it can now use syscalls, floating point math, std C builtins, etc. properly.

    One thing to note when using newlib is that it should be up to you to ‘hook up’ standard C functions to your underlying operating system so that for example printf() can write to a serial port, display or a virtual terminal via your drivers and process control/IPC works, etc.

    That being said, I bet avr-gcc is source for your confusion because that one actually has its own tiny ‘standard C library’.

    1. >Again with the usual ignorance?

      It actually impresses me that these guys can get anything running on their boards at all.. there is a post about how hard it is to build GCC almost every week.
      The one that made me seriously confused was one about building openocd with the launchpad support.. it said something like “this process is only for people that like compiling code”. I couldn’t work out why anyone that didn’t want to compile code would want a debugger (openocd + gdb).

  3. I was excited to play with my m4 stellaris board and planned on incorporate the uC it into a product I am making… but then I found there were stock issues with them. Has this been addressed or do they still have supply issues with their lower pincount versions of the m4?

    It reminds me of maxim chips. Sometimes you can get samples more easily than you can source the chip to purchase in lower quantities! haha

  4. I was quite happy and really looking forward to doing fun things with it but got a little turned off by the mcu in Stellaris LP being part of the experimental, early batches that have a lot, and I mean a lot, of hw bugs in them. Check the errata.

    This doesn’t mean you can’t do cool things with it, it just means you are quite likely to end up having to write workarounds, ie producing tricky code that you can never re-use in other places (as they don’t have the same erratas/work-arounds).

    1. yeah they are experimental chips.

      But don’t forget these boards were darn cheap so it was a good occasion to start messing with bare metal arm code.

      Did you really have to code workarounds for the LX4F120 erratas ?
      Then you just have to #ifdef them so they can be disabled with newer chips.


  5. From the linked article: “So we have a working copy of printf and its friends fprintf and sprintf, we also have a working copy of malloc, but any self-respecting embedded engineer wouldn’t touch that with 10 foot pole.”

    That’s ironic. Last time I checked, newlib’s printf implementation contains calls to malloc.

    I don’t like being *required* to allocate a dynamic memory heap just to use printf, since I typically won’t be using malloc. Not to mention all the additional code dependencies it links in for dynamic memory, streams, and whatnot.

    So to rephrase the above quote, any self-respecting embedded engineer wouldn’t use a big library just to gain use of printf. Instead, use a standalone, lean printf function, like this:

    1. I went down this path myself because I needed to print floats, and this seemed the quickest way to do it. (printing floats is the only thing that printf uses malloc for, if you dont care about printing floats then you dont need to setup the heap symbols, just the _write function)

      My goal for writing this all down was to help get people unfamiliar with platforms like this up and running. I know that whenever I pick up a new platform its always nice to have a easy to use base to start from, and then as I need more functionality I can start moving to a more “embedded” approach as I become more familiar with it. And in the process, cut out the bloat.

      And I agree, using the stripped down versions like you linked or the one in Stellarisware is more than sufficient for 99% of use cases. On the flip side, this processor is more than capable of handling the extra bloat in the full blown printf, even if you only use it when you’re in the development stages of a project. (The biggest image i’ve seen is around 35K, and that was including a bunch of the DSP library functions)

      I could have made my intentions of what this should be used for a little clearer, as well as cut down on the commentary so I’ll probably add an update later today to stem any further confusion from those already in the know.

      If you happen to know of a standalone version of printf that handles floats let me know (I couldn’t find anything in the ~10mins i spent looking).

      1. If you’re not printing floats you should be using the integer-only versions (iprintf etc.) If that’s the only use of floats in your code it saves you from linking in the fp support routines (which can add up to a decent chunk on processors without fp hardware.)

      2. I realized I may have come across wrong. Knowing how to get newlib (or similar) working is always good info to have, even if you choose to use something else. You have a good point about getting things up and running quick, worry about optimization later.

        Seems to be common to omit floating point support from compact standalone printf implementations, since it would rely on the ftoa (and maybe dtoa) functions; which are both non-standard, and non-trivial compared to the other number-to-ASCII functions. I didn’t find anything either, but it was easy enough to add to “Tiny printf” after I also added the single-precision IEEE ftoa function found here:

        I’m not sure if this is the best one out there, in terms of speed or memory. But it does seem robust, and accounts for rounding/resolution errors nicely (ie, it won’t display 5 as 4.999999). And even including this, the standalone printf solution is still much smaller than the printf included with my GCC-based compiler’s library.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.