This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: looking for tips on programming in C for embedded systems
- From: David Oberbeck <dgo at microsynetics dot com>
- To: ecos-discuss at sourceware dot cygnus dot com
- Date: Thu, 20 Dec 2001 11:12:52 -0700
- Subject: Re: [ECOS] looking for tips on programming in C for embedded systems
- Organization: Microsynetics
- References: <200112201128.DAA03721@cygnus.com> <3C222724.29AD8C6A@redhat.com>
- Reply-to: dgo at microsynetics dot com
Greetings,
May I recommend 'Efficient C' by Plum & Brodie.
This less-than-well-known book was very helpful; it starts one
thinking about optimization, and what compilers do with what you tell
them. Very appropriate for embedded systems - where one does not have
infinite resources; definitely recommended reading.
It's at:
http://www.plumhall.com/effc.html
and also
http://www.plumhall.com/order.html
(for other books as well). Or at Amazon at:
http://www.amazon.com/exec/obidos/ASIN/0911537058/107-0606979-6050167
HTH,
David
P.S. Very good recommendations from Jifl.
On Thursday 20 December 2001 11:00, Jonathan Larmour wrote:
> psheer@icon.co.za wrote:
> > Is there a good article anywhere on tips for programming on
> > eCos (and low-memory/MIPS-scarce systems in general) ?
>
> There's maybe
> http://www.amazon.com/exec/obidos/ISBN%3D0122748808/107-6094942-1656500
> (haven't read it myself though).
>
> > I have been coding in C for years, but I found one
> > new thing already while working with eCos: don't -
> >
> > int foo ()
> > {
> > char data[1024];
> > ...
> > }
> >
> > - rather -
> > int foo ()
> > {
> > char *data;
> > data = malloc (1024);
> > if (!data)
> > ....
> > ....
> > free (data);
> > }
> >
> > - the latter doesn't eat precious stack space.
>
> but does require more runtime resources (time to allocate, space for code
> and the heap), and the risk of running out of memory. It's less
> deterministic. Maybe it would be better as a global even. So it's another
> approach, but not necessarily the best - it depends on the situation.
> Choosing a larger stack may still be the best option.
>
> A general principle would be to allocate up front what you know you'll
> need.
>
> > What I am looking for is the definitive top 20 tips
>
> If you're willing to collate a list, we could add it to the FAQ. I'll add
> one:
>
> For an embedded system, don't waste overhead with checking the validity of
> parameters all the time. Instead do it with asserts so it happens in
> "debug" builds, but disappears in "production" builds.
>
> Jifl
--
"Entropy Requires No Maintenance"