Embedded Muse 63 Copyright 2001 TGG May 7, 2001
You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
EDITOR: Jack Ganssle, email@example.com
- Whatís up with The Embedded Muse
- Memory Allocation
- Thought for the Week
- About The Embedded Muse
Whatís up with the Embedded Muse?
Iíve heard from quite a few readers who are wondering if the Muse is still being sent. Well, it is, but rather infrequently! The last issue was almost two months ago.
Iím now writing a weekly column for embedded.com (http://www.embedded.com), whose charter somewhat overlaps that of this newsletter. So, with a weekly deadline thereís less time to produce Muses. The Muse isnít dead, just running behind for a while, till I get comfortable with the deadline demands.
If you use malloc and free in embedded systems Iím sure youíre aware of the perils of heap fragmentation Ė even perfectly-balanced mallocs/frees may result in a heap with plenty of available memory, but broken into chunks too small to be useable.
Some folks donít use these constructs at all, a very safe alternative. Yet sometimes we donít have much choice. What do you do if youíve purchased a package (say, a protocol stack) that uses these?
I figure if weíre going to use a potentially-problematic resource weíd better instrument our code to find the problems before they turn into deadly bugs. One free allocation monitor is ďmem.cĒ, which replaces the C libraryís malloc/free with instrumented versions. It will detect most common problems. It is usually available at http://www.snippets.org, but this site has lately been down as itís being re-engineered.
An alternative is at http://www.fourmilab.ch/smartall/. Itís just a few hundred lines of C that very intelligently picks up all sorts of memory allocation problems. While targeted at workstations and MS-DOS, porting the code to an embedded application is pretty trivial.
Thought for the Week
Programmer to Team Leader:
"We can't do this proposed project. **CAN NOT** It will involve a major design change and no one in our team knows the design of this legacy system. And above that, nobody in our company knows the language in which this application has been written. So even if somebody wants to work on it, they can't. If you ask my personal opinion, the company should never take these type of projects"
Team Leader to Project Manager:
"This project will involve a design change. Currently, we don't have any staff with experience in this type of work. Also, the language is unfamiliar to us, so we will have to arrange for some training if we take this project. In my personal opinion, we are not ready to take on a project of this nature."
Project Manager to 1st Level Manager:
"This project involves a design change in the system and we don't have much experience in that area. Also, not many people in our company are appropriately trained for it. In my personal opinion, we might be able to do the project but we would need more time than usual to complete it."
1st Level Manager to Senior Level Manager:
"This project involves design re-engineering. We have some people who have worked in this area and others who know the implementation language. So they can train other people. In my personal opinion we should take this project, but with caution."
Senior Level Manager to CEO:
"This project will demonstrate to the industry our capabilities in remodeling the design of a complete legacy system. We have all the necessary skills and people to execute this project successfully. Some people have already given in-house training in this area to other staff members. In my personal opinion, we should not let this project slip by us under any circumstances."
CEO to Client:
"This is the type of project in which our company specializes. We have executed many projects of the same nature for many large clients. Trust me when I say that we are the most competent firm in the industry for doing this kind of work. It is my personal opinion that we can execute this project successfully and well within the given time frame."