As is typical of everything in the embedded world getting an OS up on the board presented a few challenges. I knew that I wanted to run debian on the board, I just had to figure out how to get it installed on to the microSD card. I picked up a 4GB class 4 card for the purposes of loading the OS and evaluating the board. Since there was no optical disk drive connected that ruled out the typical route of burning a debian install image. I couldn’t find a USB flash drive that I could format that was of sufficient size to load the install image on to. That left me with the option of putting the install image on a CF card using a USB CF card reader. Then, I booted the system with this drive and everything worked as though it would have with a USB flash drive. The only downside was the slow speed of the older CF card.

The install appeared to be going great, I got everything setup and I was ready for a reboot. So, I rebooted the system and I got nothing. Well technically I got the word “grub” printed on the screen and that was it. Thinking I had dorked something up I re-installed again, double checking everything. Same result! So, I decided to disconnect the USB CF card reader and try to boot up that way. Now I got even less! Just a flashing cursor. This told me that GRUB had some how gotten dorked up. So, I rewrote the installer image to CF card and booted up in rescue mode. I mounted my /boot partition by issuing mount /dev/mmcblk0p1 /boot. I looked at /boot/grub/device.map and I saw my problem immediately. My device.map read:

(hd0)   /dev/sda
(hd1)   /dev/mmcblk0

It was thinking that /dev/sda was my first disk, and that mmcblk0 was my second. It installed the MBR on /dev/sda (which is what was screwing up my CF card after the install), but didn’t create a partition for /boot. Which is why I only got “GRUB” on my screen. So, I changed the device map to reflect the true state of my system, and re-did a grub-install specifying the device map. Rebooted the system and I got a grub menu as I expected but still couldn’t boot! The grub menu was still pointing to (hd1) for the kernel image. A quick edit of the boot parameters and I was booting.

After a bit of frustration everything is up and going. So, now it is time to get my packages installed and make sure I can run the embedded app on this board! I’ll post some more benchmarks at a later date. I am expecting good performance given what I saw with the 1.1GHz board.

Most people apply this principle to code for decomposition and overlook the actual data being stored. However, this should not be the case! Performance can suffer greatly when we aren’t diligent in making our data as DRY as possible.

When dealing with software where objects have a long lifetime the cost of construction gets ammortized to the point of non-existenince. However, for short lived objects the construction/destruction my consume the majority of the objects lifecycle. For these types of objects keeping things DRY is very important. I’ll discuss a case where DRYing out an object has very real performance consequences.

One example, would be using an object as identifiers for data objects. Take the following code as an example:

CBaseState *statePtr = NULL; // CBaseState is the base class for all state variables
statePtr = stateList[0]; // stateList is a std::vector

// every CBaseState has an ID field of type CBaseID, this is used to ID different states at runtime
// CPositionXID is derived from CBaseID
if (statePtr->GetID() == CPositionXID())
{
   printf("We have a XPosition state\n");
}

The class CBaseID is defined as:

class CBaseID
{
   StateEnum StateType;
   int ID[8];
   std::string IDString;
}

The equality operator checks the StateType and ID fields for equality. The IDString is a textual representation of the StateType and ID array. The IDString member is only used for display purposes in the debugger, and never referenced in the program.

The program creates 380,000,000+ instances of CBaseID derived classes during a typical processing run. Due to the creation of IDString the std::string constructor/destructor consumes 12% of the processing time! A simple change to DRY out the class yielded a 12% reduction in run-time.

The take away, don’t repeat data unnecessarily! If you can say something using one declaration, don’t use two. Make your tools work smarter, not harder.

When you convince a manager to purchase an expensive development tool you should be committed to learning what the tool is, and what it can do for you. Recently I’ve been looking at some code that a developer worked on long and hard. He attempted to make performance an important issue. The performance of this application is absolutely critical, as it is a vital step in processing data collected by field operations. The field personnel need to know in short order if their data is complete so they can demobilize. This becomes very important when you are in a line of work that has a $3,000 per day field cost. The developer who is no longer with the company convinced his manager that he needed IBM’s QuantifyPlus package. His manager saw a valid case for the purchase since there were known memory leaks in the problem, and the code base was in excess of 150,000 lines of code.

After getting this new tool, and sharpening it he set to work eliminating those pesky memory leaks. With the immediate fire extinguished a manager would have hoped that the developer took some time to figure out what other tools where added to his toolbox. Sadly, that developer did not do so. The true tragedy is that this expensive tool set included a performance analysis tool in addition to the memory analysis tool.

After having the code base in fresh hands for 18-months the software package is now capable of more robust processing operations, and runs in 1/2 the time that it used to. Further to that, the new developers armed with a toolbox that they know the contents of are striving to decrease the runtime even further.

Remember developers you are craftsmen, a craftsmen is nothing if they don’t know their tools. Sure, some of you may say that everything’s a nail for your hammer. But know what hammers you have, the 16lb sledge hammer is a poor fit for hanging that $5,000 piece of art in the hallway.

A future series of articles will discuss some of the steps the developers took to save so much processing time.

• Full system backup (i.e. support bare metal restore)
• Hourly backups of changed files (kept for 24 hours)
• Daily tag of changed files
• Weekly full system backups
• Backup at system shutdown
• Restore selected revision of a file

This system will have two components, the client component that performs the system backup. The second component is a server component. The server will most likely be implemented on a distribution of Linux (perhaps using Ubuntu server as a starting point). I will initially write a client for the Windows operating system (targeting XP first, and then extending with functionality provided by Vista and 7). Eventually a client will be developed that runs on Linux systems using LVM.

As a side note, there a few new tweaks to the blog thanks to playing with jQuery. A few more will be coming in the little while.

We recently ran into the fun behaviour of having multiple heaps in a program. Somehow a project got built using one C run-time for the executable, and a DLL dependency got built using a different C run-time. Since, this change was not known to me, I didn’t flag it as a possible cause of the problem to the developer. Even the developer didn’t remember changing the runtime libraries.

The fun started as this. The DLL contained the definition of a couple of classes. Let’s call them CDataStream and CDataObject. CDataStream has a function called getNextObject() with the return type CDataObject*. The fun starts when the object is created on the heap created by the DLL’s run-time, and then you attempt to delete the object in the executable. Since the executable is using a different heap it obviously can’t delete the object returned by getNextObject(). This zapped about 8 hours of time from the developer before he finally realized what was going on.

No bonus points are awarded to those who point out that these sorts of problems are sovled by COM. Since this is legacy code that has been in place for several years, a rewrite can’t be justified.