Object-oriented firmware (2)

Dynamic memory is a common feature of OO implementations. Typically, an object instance is created and used. Some time later, it is destroyed, and its memory returned to the pool. This is a perfectly good way to work, but it can introduce problems of its own, notably memory fragmentation. This is more serious the smaller the available reservoir of memory.

In firmware, fragmentation could lead to a system crash, and that’s a serious matter. Especially as the use of dynamic memory is not necessary. In some applications, it is actually unhelpful. In our development environment, it would only have introduced new problems, with no clear benefit.

Our applications started by initialising the system (the microcontroller and its peripherals), and then initialising the application itself. Execution continued by means of (RTOS and application) tasks, created and scheduled during initialisation. Because these tasks executed repeatedly, with time in between for other tasks to run, their variables needed to be static (persistent across task invocations).

The same applied to other system resources, such as timers. Creating and destroying them was a needless overhead, when many (all?) of them were required to function across task invocations. So we decided to allocate all necessary memory during initialisation, and make it persistent. Thus we avoided the problems associated with dynamic memory by simply not using it.

Don’t misunderstand. We didn’t avoid problems by crippling our applications, or the way they worked. We didn’t run away from problems, or hide from them. Rather, the way we worked allowed the simplification of not using dynamic memory. And firmware is, or should be, as simple as it can be (but no simpler). The lack of resources (principally memory) that our target platforms exhibit makes this necessary. But we take advantage of this simplicity to improve our firmware, working with it to keep things as simple as they can be.

Even the smallest firmware application is a complicated thing, perhaps too complicated for the human mind to encompass all in one go. Any simplification is a bonus, something to be sought after. So avoid dynamic memory, or any other problematic feature, if you can do so without compromising your end product. The simpler you can keep things, the easier it will be to add those unexpected new features that the Product Manager now wants. [How could she possibly want to use the product like that?!!!]


As ever: please leave a comment, and thanks for dropping by. The purpose of this blog is to stimulate discussion of all things firmware. Will you gift us with your thoughts?

Object-oriented firmware (2)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s