BOSTON, Mass. — There’s no question that the ARM Cortex-M7 — with its robust memory and processing power — extends the capabilities of the microcontroller in ways that would have been unimaginable even a few years ago. Significant is the fact that the processor is positioned to become a core building block in the Internet of Things (IoT).
To wit, ST Micro’s STM32 F7 won best-of-show at ARM TechCon in September. It's the first 32-bit MCU family to feature the ARM Cortex-M7 core and has 320KB of SRAM and 1024KB of flash. Atmel’s Cortex-M7 parts, not yet announced, are expected to have on the order of 384KB of SRAM and 2MBs of flash. That’s ten times more than for the typical MCU.
But, whether the Cortex-M7 has the necessary resources to “get the job done” depends an awful lot on who you ask. What is telling in itself: the giant hairball of decisions and trade-offs in hardware, software, and systems that today’s embedded developers say they wrestle with in a design space that seems almost unconstrained at times.
“For developers coming from Windows, Linux, IOS, Web service programming, and business logic programming, the Cortex-M7 is constraining and stifling. But, for the developer who has worked on 8051, any 8-bit micro, or Cortex-M0 through M3 parts, will view the Cortex-M7 as absolutely massive,” said Matt Liberty, founder of Jetperch LLC, which provides DSP and embedded software consulting services.
A real-time I/O processing powerhouse
“It’s a real-time I/O processing powerhouse. In fact, bare-metal executor loop programming, which runs on target hardware without an operating system and is efficient, simple to understand and easy to debug for small embedded programs like those written for many 8-bit microcontrollers, will likely fail to use this much processing and memory.”
In the case of the IoT, the adoption of a real-time operating system (RTOS) becomes critical, Liberty stressed, in order to manage the complexity of networking and the multitude of peripherals efficiently. But, the number of RTOS's has exploded over the last several years as the community struggles to find the right approach, and selecting the “best” RTOS has become a major challenge for developers.
“A quick glance at Wikipedia's “List of real-time operating systems” is enough to give an embedded software engineer nightmares,” stressed Liberty. “Although C and C++ will remain commonplace, both languages are lacking when considering multi-threading, safety, and security. Languages like D and Rust have the potential to fill the gap, but neither is ready today for embedded applications.”
Frank Hunleth, an embedded software developer who specializes in video processing and embedded Linux, agreed that the industry needs to prove out the use of higher-level languages on these platforms and help define their libraries.
“I’m sure that if I use an M7 on a project in the next year that I’ll still be using C or C++ on it, because that’s what most tools and libraries support,” he said. “Do I want it to stay that way? No, because we’re missing out on things like static-checked memory safety like you get from Rust, ease of development from Python, and the fault tolerance and concurrency of Erlang and Elixir.”
Coming up short
Others view the M7’s memory as coming up short for the Internet of Things, even with features intended to make the most of it, like ST’s Adaptive Real-Time Accelerator for internal embedded Flash and L1 cache for both execution and data access from internal and external memories.
“It’s a lot of memory and storage for a micro-controller. But, with even the smallest of Java VMs [an environment that interprets Java byte code, allowing the processor to perform the program’s instructions] requiring at least 2MBs to run, we’re not likely to see Java or any other VM-based platform running on these small CPU cores anytime soon,” said Michael Anderson, CTO and chief scientist for the PTR Group. “If you add a communications stack and an executive or an RTOS like ARM’s mbed, Micrium’s μC/OS-III, or FreeRTOS, your program space starts to look pretty small.”
Anderson emphasized that the lifeblood of many of these new IoT applications will be memory utilization. “Memory is precious. Encapsulating APIs inside of class libraries, while it may be good in the general-purpose computer, eats memory. There are few in the computing industry that are not aware of the memory bloat our code has acquired over the years. If we don’t think hard about what we’re developing and continue writing code the way many of us have become accustomed to when we have gobs of RAM, we’ll never be able to enable all of the exciting new possibilities for the IoT that use these tiny memory footprint microcontrollers.”