.png?width=180&height=67&name=Crank-AMETEK-HZ-Rev%20(4).png)
If you’ve been following our blog or have downloaded our eBook around best practices for embedded UI development on microcontrollers (MCUs) to microprocessors (MPUs), then you’ll know that squeezing your application into a microcontroller is one of the best ways to reduce your product’s bill of materials.
With a MCU-based design, you’re able to eliminate extra RAM and flash chips, and use on-board peripherals instead of off-board logic – all of which is becoming easier with today’s class of powerful chips. Of course, the MCU itself also provides an additional cost drop from a full-fledged microprocessor. All of these reductions mean a less costly product to manufacture, opening it up to mass-market volumes and higher profit margins.
The big question is: how do you know if your application can be shrunk down to microcontroller proportions? In other words, what factors are most important when considering building an embedded UI app on an MCU?
The 5 most important MCU considerations:
- Hardware bill of materials
- RAM size
- Flash size
- Voice recognition (VR)
- Embedded UI complexity
1. Hardware bill of materials
Part of the magic of microcontrollers is that they take the place of other logic on your electronics board. However, you need to have something to eliminate. If the bill of materials for your chips is already below $5 USD, it’s likely that you’re already quite lean. You’ll want to consider a microcontroller transition if you already have a number of other discrete components – especially RAM and Flash – that total $5 USD or more.
2. RAM size
Microcontrollers have built-in RAM but not a ton, so if your application’s RAM usage is high, it may not be a great candidate for squeezing onto a microcontroller. On-board RAM for the top-end MCUs is generally around 1MB although you’ll want to double-check with the micro’s datasheet to be sure. You’ll also want to shrink down default stacks by selectively thrifting out what you can from always-in-memory data structures, and checking your structures to make sure they’re not larger than necessary due to compiler and processor alignment requirements. RAM-hungry libraries like databases often have configuration settings and modes to specifically reduce RAM usage. Even if your program’s RAM high watermark is above the on-board RAM size by 10 to 15 percent, you may be able to shrink enough to fit without removing functionality.
3. Flash size
Similar to RAM, taking advantage of the MCU's on-board Flash is critical to eliminating the cost of extra flash chips. Flash sizes on MCU's vary significantly but usually range anywhere from 512K to 4MB. Shrinking code is sometimes a bit easier than shrinking data since you have the compiler’s help; turn on all compiler size optimizations including those that eliminate dead code and fold redundant subroutines. If you have a number of static data structures, it will probably pay to compress them even though you’ll need to add decompression logic. If your code uses lots of text-based files like XML or JSON, having a build-time “minify” tool that strips all comments and whitespace can also help you gain some space.
4. Voice recognition (VR)
Voice-recognition engines can use a lot of RAM and Flash, making it hard to fit them onto a MCU. If your application is dependent on VR, you’ll want to carefully consider how to best manage this when performing a MCU port. There are smaller footprint VR engines that can fit into a microcontroller’s onboard RAM and Flash, however choosing these engines might entail sacrificing recognition accuracy or natural language capability. Another strategy for IoT devices that have a continual Internet connection is to use an off-board VR engine. The audio processing front-end can easily be put on the microcontroller, while the resource-using backend resides in the cloud.
5. Embedded UI complexity
The number of individual embedded UI screens in your application can give you a rough idea of its storage requirements, however, you’ll want to consider all of the following:
- Number of unique GUI screens and screen templates
- Number of PNG, JPG, and GIF images
- Number of internationalization languages
- Number of fonts used and whether they are TrueType or bitmap
- Whether or not you need Asian language support
- Number of animations or transitions requiring graphics
- Size of display: width and height in pixels, and color depth in bits
If you are designing a new application, you won’t have a lot of concrete details to start with. However, with this checklist, you should be able to loosely determine whether or not your application is a candidate to port to a MCU. If the sum of your guesses is below 16MB, you can probably make it although you may have to significantly slim your app down.
Pushing boundaries with tight memory and resources.
With the same collaborative workflow and ease-of-use that developers and designers are familiar with in Storyboard, Storyboard Lite helps teams build applications that are tailor-made for their hardware platforms - especially for resource-constrained targets where every kilobyte matters.
Looking for expertise in scaling down from an MPU to an MCU? Dropping megabytes from your app is something that we help many customers do on a regular basis. From startups to Fortune 500 firms, our Professional Services team works one-on-one with white goods, consumer, automotive, medical, and industrial companies, to optimize embedded GUI products for high-volume, high-margin sales.