#38
avrtoolbox and C Standard Library
by Joe Pardue
Follow along with this
series! Joe’s book & kits
are available at
www.nutsvolts.com
Recap
This Workshop marks a milestone in the development
of the avrtoolbox. It is the end of the beginning. We have
discussed some useful software engineering concepts and
applied them to processes for an Open Source project
( http://code.google.com/p/avrtoolbox). We have applied
these processes to the development of the libraries in
libavr. Now, we will finish this beginning by learning about
the venerable C standard library. We will look in detail at
one of the venerable functions from that library: printf()
(as it has been tweaked by avrlibc to work on the AVR);
and we will look at some other standard functions that
we’ll apply to writing a simple command line interpreter.
Our demonstration program will prove very useful for our
future software development and testing.
The C Standard Library
58 September 2011
The C standard library isn’t actually a library, but is the
standard for an interface specification that library writers
must use to write C runtime libraries that conform to the
ISO C standard library specification. (There are other
slightly different standards from other organizations.)
These specifications are much like the functional
requirements specifications that we discussed in the June
‘ 11 Workshop. Even though it is a specification and not a
library, in general use when you see C standard library or
C library, folks are talking about a specific software
implementation. In our case, most of this is available in
avrlibc ( www.nongnu.org/avr-libc).
If you read a lot about generic C and the standard
library, you may be somewhat confused when you try to
use these standard functions with microcontrollers. This
will be especially true if you come from a background of
using C with PCs. The reason for this confusion is that C
was written for a computer with lots of RAM that held
both the program and the data. However, RAM is
expensive compared to ROM, so for microcontrollers —
that must be as cheap as possible — the use of RAM is
minimized and is only used for data while the program
resides in a separate part of memory (Flash EEPROM in
the case of the AVRs; see the Workshops from June
through October ‘ 10 for a detailed discussion).
