Is footprint still important for embedded devices?

Footprint, or the amount of memory your software use, has traditionally been a big deal for embedded devices. But nowadays, with RAM and flash memory cost being a fraction of what it used to be, surely footprint is a non-issue? Just throw in more memory. It's cheap, right?

Well, not so fast there Mr. (or Mrs.)

Call me old-school, but I believe that footprint is still a huge issue in many devices (not all, but many), and I'll tell you why.

When I got started doing serious (or not so serious) programming, my machine of choice was a TRS-80, also called Trash-80 by the Pet/Commodore/Apple crowd. Well, I actually didn't have a choice since this was the machine my father brought home, being a gadget freak. We are talking late 70's here and the system I used had a whopping 4KB of RAM, quickly upgraded to 16KB. The programming language (after a quick stint of MS Basic) was Z80 assembly language. With that kind of constrained environment, you develop a 6th sense of solving your programming problems in the simplest way possible, using as little code and data as you possibly can. I am mentioning this not only to show off my age, but also to put things into perspective.

In the PC/Workstation/Enterprise markets, footprint is clearly not the top criteria when developing software. Just compare the footprint of Office 97 to Office 2003. We are talking about at least a five X increase in space needed. This is not really a huge problem since the disk and RAM sizes on your average PC have increased at least as much.

But things are different in the embedded world. I'll give you three reasons for why footprint matters, but I am sure there are more:

1. The cost of memory is more important in a device compared to a PC
   Even though memory in the long run is getting much cheaper, so are other components too, and at the end of the day every dollar you save in hardware cost translates to profit when you sell thousands or millions of fairly cheap devices.
2. Power consumption
   More memory use more power.  Anybody who has cursed when their Windows Mobile device dies before the end of one day's use know why this is important. It is not just the amount of total memory you have in the device, it is also the amount of powered memory at any given instance. Smart devices turn off the memory they don't use.
3. Boot time
   Many devices, like digital cameras, need to boot really fast. On many systems, a big chunk of the boot time is to copy the software from a flash memory into a RAM memory. The smaller the code is, the faster it boots.

OK, so maybe footprint is still important, but what can I do to keep the size down on my device?

Here are a few random tips. Sometimes code size is a trade-off against other things, like number of features, performance, ease of programming etc., but I find that keeping the code size down also tends to keep the complexity down, which is a good thing for quality.

• Choose a programming language that is optimized for code size
  This is definitely a trade-off. Languages like C are excellent for footprint (you get what you expect) while Java would be at the other end of the spectrum. C++ is one of those languages that can be very effective if you know what you are doing, but I have seen so many examples of bloated C++ applications that I advise you to be careful. Read Stroustrup's (father of C++) insightful comments. In my mind (being a former compiler writer) C++ is a very complex language to write a compiler for and that translates into a lack of transparency when it comes to getting the code you expect. Don't use all the features of C++ just because you can.
• Choose a compiler that optimize for code size
  Most compilers optimize for speed. That is one of the bigger differences of an embedded compiler, that it also looks at code size. For example, one of the reasons we compile VxWorks with the Wind River compiler (formerly known as Diab), is not only that the code runs about 10% faster, it also is about 10% smaller compared to the gcc compiler.
• Choose an operating system that can scale and only include what you need
  This is a big difference between operating systems designed for devices (like VxWorks)compared to general purpose operating systems (like Linux). An RTOS (Real-Time OS) like VxWorks can almost be considered to be more of a library where you only get what you actually use into your code image.

But the most important way of achieving small footprint is to architect your code for simplicity and small size. This is easier said that done, especially when you are dealing with existing code.