I have seen responses to previous questions of the week, most notably “What matters most when choosing an embedded processor?” and “Do you use or allow dynamic memory allocation in your embedded design?”, uncover at least two different developer biases with regards to memory management hardware. One type of developer considers the use of an MMU (memory management unit) an expensive and usually unnecessary component, while the other type of developer considers an MMU an essential and necessary component in their design.

After looking through the processors listed in the Embedded Processing Directory, I think it is safe to say that processors that include MMUs are predominantly limited to the 32-bit processor space. While there are some 8-, and 16-bit processors that lay claim to an MMU, the majority of these sized processors, listed across approximately 60 pages in the directory, do not include an MMU. These smaller processors support smaller memory sizes and are not likely targets for consolidating many functions within a single processing core.

Even in the 32-bit processor space, there is a lot of activity at the small end of the processing spectrum. Consider the ARM Cortex-M0 that only hit the market within the last year and does not include an MMU. The Cortex-M0 is the smallest 32-bit core ARM offers and it experienced the fastest adoption rate of any ARM core ever. The Cortex-M3 does not support an MMU, but it does support an optional MPU (memory protection unit). In fact, MMU support only exists in the Cortex-Ax class processors with the Cortex-Rx processors only supporting an optional MPU.

I do not believe there is a universal answer to using an MMU; rather, it seems that when to use an MMU depends greatly on the choice of processor and the type of software the end-device requires. Is using an operating system an essential ingredient to using an MMU? Is there a size threshold for when using an MMU makes sense? Does the use of dynamic or static memory allocation affect when it makes sense to insist on an MMU? Does an MMU make sense in systems that have deterministic hard real-time requirements?

In other words, where is the line between using an MMU and not using an MMU? The embedded space is too large to generalize an answer to this question, so I ask that you share what type of systems you work with and any specific engineering reasoning you use when deciding whether or not to use an MMU in your design.

If you have a question you would like to see in a future week, please contact me.

I remember the first embedded project that I worked on where I had visibility into choosing the processor. I was a junior member of the technical staff and I “assisted” a more senior member in selecting and documenting our choice of processor for a proposal. I say assisted because my contribution consisted mostly of writing up the proposal rather than actually evaluating the different options. What stuck with me over the years about that experience was the large number of options and the apparent ease with which the other team member chose the target processor (a 80C196KB). I felt that processor had been chosen mostly based on his prior experience and familiarity with the part.

Today, the number of processing options available to embedded developers is vastly larger; just check out the Embedded Processing Directory to get a sense of the current market players and types of parts they offer. While prior experience with a processor family is valuable, I suspect it is only one of many considerations when choosing a target processor. Today’s device families offer many peripherals and hardware accelerators in a single package that were not available just a few years ago. Today’s devices are so complex that it is insufficient for processor vendors to just supply a datasheet and cross assembler. Today, most processor suppliers provide substantial amounts of software to go with their processors. I view most of this software as “low-hanging integration fruit” rather than a “necessary evil” to sell processors, but that is a topic for another day.

I suspect that while instruction set architecture and maximum processing performance are important, they are not necessarily the same level of deciding criteria that they used to be. There are entire processor platforms built around low energy or value pricing that trade processing performance to enable entirely different sets of end applications. There is a growing body of bundled, vertically targeted, software that many processor platforms support, and I suspect the bundled software is playing a larger role in getting a processor across the line into a design win.

With the recent launch of the Embedded Processing Directory, I would like to ask you what matters most to you when choosing an embedded processor? Is having access to the on-chip resources in a table format still sufficient, or are there other types of information that you must evaluate before selecting a target processor? We have a roadmap planned for the directory to incorporate more application-specific criteria, as well as information about the entire ecosystem that surrounds a processor offering. Is this the right idea, or do you need something different?

Please share your thoughts on this and include what types of applications you are working on to provide a context for the criteria you examine when selecting an embedded processor.

Recently, I was working with a touch-interface development kit as part of a hands-on project that I am publishing about over the next few months. The out-of-the-box experience was clean (although there was a media hiccup), and the demos worked as advertised. The next step was to build a “hello world” version of a touch interface program to make sure I correctly understood how to operate the system from scratch.

The development kit offered several ways to initialize the target processor. Instead of manually setting all of the registers, I chose to use the supplied configuration wizard. Even though the configuration wizard supplied the source code to initialize the processor, I cannot say it greatly lessoned the learning curve for choosing what the initialization settings should be. However, it did allow me to focus on the settings without too much worrying about the coding mechanics.

The next step was to start using the supplied API (application programming interface) to activate and query the touch interface controller. For the hello world project, I decided to toggle a light on and off whenever I pressed a specific touch button on the development board. I loaded the program and began execution, but touching the button never activated a message for the application code to process. After a bit of trying this and trying that, I realized the timer that the touch controller used was disabled.

I had assumed that the configuration wizard and touch controller API were tightly coupled and that together they would select the appropriate default settings for a touch application on the target system. However, the configuration wizard disabled the timer and the API initialization call did not enable it. This is a simple problem to fix, and I suspect the support team for the development kit will either change the API initialization call to enable that timer or change the documentation for the API call to make it clear that the application code must manually enable the timer. I personally think the API call should abstract enabling and disabling the timer.

Enabling the timer however was not sufficient to make the button activate a message to the application code. It turns out the timeout delay for the touch sensor had been set too short to allow it to register when the user had touched the pad. The timeout delay was not a direct setting; rather it was derived from several other settings. While the configuration wizard simplified the coding for those settings, it did not abstract the derivation of the timeout delay and display that to me when I was choosing the values to use. A conversation with the support team for the development team suggests they will be adding that type of feedback to the wizard.

Initializing a processor that is not using an operating system has always been significant effort. Many companies now offer configuration or initialization wizards/tools to help developers use their processors. My question is, do you find that these tools simplify the learning curve for initializing your target processor? Do they make the process faster and more reliable? What lessons learned could you share about how to best use these types of tools?

If you have a question you would like to see in a future week, please contact me.

I recently spent a week at a friend’s house, and they have three small children. Living with young children is a stark contrast to living with teenagers. While my own children (both teenagers) impress me with their observations, their leaps of logic often make sense to me. Young children on the other hand make many leaps of logic that seem random or chaotic as they test their own models of how the world works.

During my visit, one of the young boys showed me Scribblenauts, a puzzle game on the Nintendo DS that presents you with a series of challenges (220 in total I believe). You are able to use any objects that you can think of to solve the challenge. You summon objects by typing the word for those objects, such as a ladder or a shovel. I might have been able to specify an object or two that the game was not able to create, but I am impressed by the vocabulary that the game supports – even singularities and Cthulhu.

Playing the game with the young boy was enlightening because he usually employed a different approach to solving each problem than I would. The game engine can support multiple solutions because it is a physics simulator, and the objects in the world interact with each other in a physical fashion. As an example, one of the problems in the world was to get a cat off the roof of a house. One way to accomplish that is to put cat food on the ground and the cat comes down to eat it. Another approach could be to place a dog on the roof and have it chase the cat off the roof. Yet another approach could involve catching the cat with a net, or even dropping rocks (most any object as a matter of fact) on the cat to knock it off the roof.

While playing the game with the young boy, I began to see how he approached problems and changed his tactics as his older approaches no longer solved the problem set before us. Seeing and being able to recognize his different way of seeing the world expanded my own repertoire of approaches and led me to this week’s question.

Has a child ever inspired a solution for you when trying to grapple with a problem? I suggest substituting anything for the term child, such as a pet, a spouse, a cat reaching through some bars to catch a mouse, or even an apple falling from a tree.

I suspect we find answers to problems all the time in the mundane observations of the world. I wonder if by sharing what led up to those inspirations we can accelerate or spot ways to make tools that can help us explore and inspire new approaches to ever increasingly complex problems.

If you would like to participate in this or other series, or provide a guest post, please contact me at Embedded Insights.

[Editor's Note: this was originally posted on the Embedded Master]