Why Move From a Microcontroller to the STM32MP1?

You might have seen the OSD32MP1 System in Package (SiP) built around the new STM32MP1 microprocessor from ST Micro and wondered, “Why should I care? I’ve been using microcontrollers for years- I’m an expert at programming bare metal, a regular register ninja.” In this article, I will paint a picture of why even the simplest of microcontroller applications can benefit from the Octavo STM32MP1 System in Package.

To back up just a bit though, what are the STM32MP1 and the OSD32MP1 System in Package? The STM32MP1 is the first mass-market microprocessor from ST Micro. It builds on their very successful line of STM32 ARM Cortex-M Microcontrollers by adding Dual ARM Cortex-A7 Cores to an M4 Core. This integration allows you to run Linux while still taking advantage of the real time capabilities of the Microcontroller.

The OSD32MP1 SiP is the first System in Package built around the STM32MP1. As you may know, when you move a design from a Cortex-M microcontroller to Cortex-A microprocessors a lot of complexity gets added to the system. The biggest addition needed for a microprocessor is external RAM, DDR3 in this case, which can be extremely difficult to route. A microprocessor also has multiple power domains and power sequencing requirements that must now be managed. These are just a couple of the things that make it difficult to go from a nice single-chip microcontroller solution to a multi-chip microprocessor solution requiring management of high-speed signals and power.

• The OSD32MP1, the STM32MP1 System in Package, removes these complications and makes the Cortex-A Microprocessor a single chip solution just like the microcontroller!
• The OSD32MP1 integrates theSTM32MP1, DDR3 RAM, Power Management, Oscillators, and over 100 passive components all into a single BGA package that is only 18mm X 18mm.
• The OSD32MP1 delivers all the performance of a Dual Core Cortex-A system in the package of a microcontroller.

Now, you might be saying, “Great, sounds neat… but why do I need this again? I’ve been using microcontrollers for years, and they work just fine. I don’t need all that performance; my application is simple. Why should I care?”. While this may have been true before the rise of Analytics, Big Data, Edge Computing and Artificial Intelligence (AI), it’s only a matter of time before the trends of higher performance applications permeate your industry as well. When that time comes, your trusty microcontroller alone just won’t make the cut. You are going to need increased performance capability, and more importantly, you’ll need to be able to run Linux.

Why Linux?

I know that for a lot of people who are transitioning out of the microcontroller world even the mention of Linux in the same sentence as embedded systems may be a trigger. The two main complaints I hear when I talk about Linux for embedded applications are:

• “Linux isn’t deterministic, and I need real-time control of my system” and
• “I don’t have control over the hardware anymore; it’s been abstracted away”

To the first, I reply that the MP1 has both a Microcontroller and an Applications Processor specifically so that you can run Linux and still achieve real-time control in the M4. To the second, I concede that direct control over all the hardware is indeed abstracted away in Linux, but I contend that this abstraction is a benefit and not a drawback. Application processors are extremely complex devices, and Linux has been successfully running embedded devices for decades. Why not leverage the work completed and verified by thousands of people and corporations around the world to make your life easier?

Our applications engineer, Eshtaartha, wrote a nice article some time ago outlining the main reasons to use Linux on our OSD335x SiP for your next project. Most of those reasons hold true for the OSD32MP1 as well, and I want to focus on a couple of points that I believe are the most relevant. First is this issue of abstraction. When you use Linux, you are removed from the actual hardware; you don’t have to configure registers, you just write your code to take advantage of the hooks Linux provides for you. This can significantly cut down on the amount of time required to get your application running. Why do you need to waste time figuring out how to configure another I2C interface or how to properly set the direction of a GPIO pin? As systems get “smarter,” they get more complex, and the amount of firmware/software needed to run them increases significantly. Making sure these low-level functions work doesn’t help you differentiate your project. A Linux operating system handles all that and allows you to jump right in and spend time on the part of the application that does differentiate your product.

The second significant benefit of Linux ties closely into the first one, and that is the idea of reuse. I like to look at reuse from 2 primary perspectives: external reuse and internal reuse. External reuse is the idea of leveraging the large community of people already using Linux who are solving similar problems. They create tools and libraries that you can take advantage of in your system. For example, there are libraries for simple string manipulation, image processing, building Graphical User Interfaces, and many more. Linux itself, in fact, is an example of reusing the work somebody else has done. Leveraging this rich and active community will enable you to create feature-rich applications faster.

Internal reuse, on the other hand, is the idea of reusing code that you have created on different projects and platforms. The fact that Linux abstracts away the details of interfacing with the hardware means that with a little forethought you can build applications easily compatible with different processor platforms. You no longer have the painful process of starting from scratch every time a processor goes to end-of-life status. You can pick the new processor, boot Linux on it, and port your application over. No more having to reinvent the wheel!

The third point I will address regarding Linux holds especially true for the STM32MP1 from ST Micro, namely that Linux is open source. This means that you can see what each piece of code is doing. So if you really want to control and understand how the hardware is being manipulated, you still can, even on a microprocessor. This is even more true for the STM32MP1 because ST Micro has made a conscious effort to push all their drivers and code for the MP1 into the mainline open source Linux. With these resources, you can dig deep into how the hardware is used and gain the control you want. This level of control probably isn’t necessary for most designers, but for some it may be vital.

Why Migrate –Example of Moving from a Microcontroller to STM32MP1

So far, I have told you about the MP1 and addressed the benefits of Linux for embedded systems. But perhaps you still aren’t convinced you need to take advantage of it. You still think that your industry and application won’t succumb to the push of Big Data and AI. To understand why you should migrate, let’s look at an apparently simple application and see how the demands of Industry 4.0 or Industrial IoT and Analytics require it to be so much more than its basic criteria imply on first glance. I will also discuss how the OSD32MP1 enables it to easily achieve these new requirements.

For this example, we will look at a straightforward motor driving a conveyor belt in an assembly line. For decades, it has been enough for the motor to turn on when the line starts, run at a constant rate until the line stops, and then shut down. This is a perfect application for a microcontroller. All it has to do is start when the technician presses a button and run a Field Oriented Control (FOC) algorithm to drive the Brushless DC Motor. The microcontroller will monitor the speed of the motor and make sure it stays constant. Then when the day is over the technician presses another button, and the motor shuts down. This system has only three inputs: an “ON” button, an “OFF” button, and the current motor speed. It only has one output: the signal driving the motor.

Same Application, but More Data and More Processing

Those were the good old days. Now, this simple application must do so much more. To reduce conveyor down-time and increase productivity, the controller must now monitor the motor, predict when it will need maintenance, communicate its health to the operator, and report statistics to the company cloud server for more detailed analytics. Oh, and it still needs to run that motor. Can a microcontroller really do all of this? Maybe, but it would be very difficult, not to mention time-consuming to implement. A much easier solution allows a microcontroller to continue the basic motor-control process and off loads all the other processes to a higher-level operating system like Linux. This is where the OSD32MP1 really shines.

Leveraging a Familiar Microcontroller for Realtime applications

As I mentioned much earlier in this article, the STM32MP1 builds on ST Micro’s very successful line of STM32 microcontrollers. At its core lives a Cortex-M4 microcontroller that is compatible with ST’s standalone M4s. So if the old motor controller was a standalone ST M4, we could seamlessly migrate the existing motor control application to the MP1, using the same familiar CubeMX tools. You would have to spend very little time getting the FOC program up and running on the new processor.

If the old controller wasn’t an ST M4, then you can leverage the decades of experience ST has with microcontrollers. Referencing a few of the thousands of examples available for the ST Microcontrollers, you can be up and running with a new FOC program in no time.

Notice that in this section that I didn’t mention Linux at all. The M4 can operate completely independent from the A7’s which are running Linux. It is a true microcontroller capable of managing real time tasks.

So far, we have replicated all the same functionality that we had in our original conveyor belt application.  However, we have much more to add to meet the demands of today, so let’s keep working.

Local Analytics and Maintenance Prediction

As most of you probably know, down time in a factory is a big deal. Unscheduled down time is an even bigger deal, disrupting operations and potentially causing a major loss of productivity. Minimizing the amount of unscheduled downtime is key to keeping any assembly operation moving. To do this, companies have started to develop predictive algorithms to anticipate when and why a machine might fail so that they can preemptively do maintenance on it to make sure it doesn’t fail unexpectedly.

Some of these algorithms can require a significant amount of data and processing power. To add this capability to our system, we are going to need more horsepower than the microcontroller can easily provide. Again, this is where the OSD32MP1 shines. The Dual ARM Cortex-A7’s run Linux and can interface with large external non-volatile memory like eMMC. This memory can store months of data tied to the performance of the motor, including vibration, current draw, temperature, and anything that would need to be trended over time to help model the health of the motor.

Acquiring the data is step one, but we still need to analyze it to predict if the motor is going to fail before the next scheduled maintenance. Now, we will leverage the 2470DMIP capability of the A7’s to do some complex number crunching on large sets of data.

Managing and manipulating all this data can be a daunting task, but leveraging pre-existing Linux libraries make it much more manageable. As a result, we have moved far beyond the simple motor control application at this point, using Linux-based microprocessors to rapidly implement non-trivial algorithms for predictive maintenance, all without disrupting the basic microcontroller function

Human Machine Interface

We’ve successfully determined the health of the motor (or lack thereof), but what good does that do if we can’t tell anybody? So, we need to add a display screen so that the operator can check the status of the motor and receive alerts if anything goes wrong. For this, the OSD32MP1 has an OpenGL-compliant GPU. The presence of the integrated GPU off-loads the processing-intensive task of generating graphics from the A7 processors. We can create nice User Interfaces without adding a lot of load to the processor.

Again, we are going to leverage Linux and pre-existing tools and libraries to speed up the development of the Graphical User Interface. I personally have always hated making GUIs, so being able to leverage OpenGL tools like Crank makes me much happier and makes the GUIs much easier to build.

As if that wasn’t enough, the MP1 also includes a touch screen controller so making a responsive User Interface becomes even more trivial.

Communicating to the Cloud Securely

Recall the four requirements that we established for this updated and modernized application: control a motor, monitor its health, report the health info to the operator, and send the health info to a cloud server for further analysis and tracking. At this point, we have the first three of our four requirements completed. The last requirement, cloud connectivity, remains to be done.

To implement this, we are going to have to connect our controller to the internet. Thankfully, because we are using Linux and the MP1 has a 1Gb ethernet Mac, this process isn’t difficult. The bigger problem is now that we are on the Internet, we have opened ourselves up to a big scary world. How do we protect our application and our data?

There are two primary aspects to security in our motor control application: securing the data that we send and making sure our system itself is safe from uninvited interference.

Securing the data being sent to the cloud is straightforward. We will have to encrypt the data before sending it to the main server. For this, we can take advantage of the MP1’s encryption accelerators for AES 256 or a similar protocol. Again, Linux provides nice hooks into this making it extremely easy to implement.

A harder task is figuring out how we will protect our little motor from being taken over by evil doers on the internet. We don’t want somebody without the proper authorization accessing and speeding up or shutting down our conveyor belt. To do this, we can utilize the STM32MP1’s TrustZone. TrustZone allows us to segment our application into protected areas and general areas. We can very tightly control the code that gets executed in the controlled area. This will ensure that critical aspects of our system are protected and can’t be taken over by hackers. Here we will want to use the OP-TEE.org framework to make sure we properly sign and protect our application.

The MP1 contains all the necessary pieces for us to secure our system and protect our data while enabling cloud connectivity.

More Features Same Form Factor

We have now completed all requirements for our new conveyor belt controller. In the process, we added a lot of functionality to the original microcontroller based design. Normally, this would also add a lot of hardware complexity to the system and drive up the cost. Using the OSD32MP1 System in Package, however, enables us to achieve all this extra functionality with minimal hardware overhead.

The OSD32MP1 integrates the processor, DDR3 memory, and power management into a single package, making it look like a microcontroller. Even better, we don’t have to deal with high-speed routing or multiple power rails. Just like designing with a microcontroller, we put down a single device and hook up a single power rail. And because of the integration, we don’t have to use different PCB design rules, go to more layers, or increase our size. It is fundamentally a smarter system in the same package for very little effort.

Wrapping It Up – Why Move from a Microcontroller?

After reading this rather lengthy story, I hope I have exemplified the value of the OSD32MP1 System in package and the STM32MP1. While your application only needed a microcontroller when you designed it yesterday, there will come a time when it requires more. Just like our simple conveyer belt motor application, the demands for more data and more analytics drive the need to migrate into the world of Linux. When that day comes for you, you will be prepared with the OSD32MP1 to easily make the transition.

Get updates to the OSD32MP1 System in Package