A Micro Blog
By: Kevin Jones
Senior Consultant
11th October 2017
When I started my embedded systems career, microcontrollers had fewer embedded peripherals, reference manuals were delivered by post and Netscape was about to launch its first version of the Navigator web browser. A little more than twenty years later and microcontrollers are now complex devices with many highly-configurable peripherals. This has created a problem where it can take longer to write the microcontroller’s initialisation code than it takes to write the application.
Thankfully, silicon vendors have recognised this and many vendors now offer free tools that help developers through these early stages. Typically, these tools display a graphical representation of the microcontroller. The developer uses the tool to choose which embedded peripheral is connected to which pin and how the peripherals are configured. The tool then generates a set of source files, sometimes with a choice of target development environments, and the developer can begin to write the application without concerning themselves with microcontroller initialisation. But is this always the best method?
I recently investigated two different methods of implementing a simple flashing LED RTOS application on a small microcontroller. I first used the vendor’s tools to auto-generate the project. This took just a couple of hours and resulted in a ROM footprint of approximately 8kb. Then I hand-crafted the project from scratch which took just over a day to complete and resulted in a ROM footprint of 4kb (and most of the 4kB is the RTOS infrastructure).
This might not seem like a big difference until you consider that this example is simply flashing one LED. Imagine the savings in ROM footprint that could be gained in a real-world application that utilises many more embedded peripherals. Modern consumer devices are typically designed for the lowest possible cost. The smaller ROM footprint might permit the project to use a lower specification microcontroller which, in turn, might take a few cents off the bill of materials. This becomes significant when taking a development project to large volume production.
Plextek has the experience and skills of getting products into high-volume production and so we’re ideally suited to help clients choose either a rapid development using silicon vendor’s configuration tools or a bespoke development with its own potential advantages.
When I started my embedded systems career, microcontrollers had fewer embedded peripherals, reference manuals were delivered by post and Netscape was about to launch its first version of the Navigator web browser. A little more than twenty years later and microcontrollers are now complex devices with many highly-configurable peripherals. This has created a problem where it can take longer to write the microcontroller’s initialisation code than it takes to write the application.
Thankfully, silicon vendors have recognised this and many vendors now offer free tools that help developers through these early stages. Typically, these tools display a graphical representation of the microcontroller. The developer uses the tool to choose which embedded peripheral is connected to which pin and how the peripherals are configured. The tool then generates a set of source files, sometimes with a choice of target development environments, and the developer can begin to write the application without concerning themselves with microcontroller initialisation. But is this always the best method?
I recently investigated two different methods of implementing a simple flashing LED RTOS application on a small microcontroller. I first used the vendor’s tools to auto-generate the project. This took just a couple of hours and resulted in a ROM footprint of approximately 8kb. Then I hand-crafted the project from scratch which took just over a day to complete and resulted in a ROM footprint of 4kb (and most of the 4kB is the RTOS infrastructure).
This might not seem like a big difference until you consider that this example is simply flashing one LED. Imagine the savings in ROM footprint that could be gained for a real-world application that utilises many more embedded peripherals. Modern consumer devices are typically designed for the lowest possible cost. The smaller ROM footprint might permit the project to use a lower specification microcontroller which, in turn, might take a few cents off the bill of materials. This becomes significant when taking a development project to large volume production.
Plextek has the experience and skills of getting products into high-volume production and so we’re ideally suited to help clients choose either a rapid development using silicon vendor’s configuration tools or a bespoke development with its own potential advantages.
