Microcontrollers (MCUs) come in a wide array of sizes for every application, from power optimized 8-bit to 32-bit high-performance MCUs running a dedicated operating system. The amount of MCUs needed to achieve a specific application is a difficult question with no correct answer. Going too high on the spectrum creates a more expensive design, while going too low makes it difficult or impossible to implement, wasting development time.
One way to help select a product is by seeing the reference designs and demos that someone else has already made. This provides a benchmark, or point of reference, that can be used to figure out if an application is feasible and cost-effective.
As an example of this, consider this IoT irrigation demo. The demo runs on the PIC32CM-GC00 family of MCUs, which sports an ARM Cortex-M23 CPU at 72 MHz. An M23 class CPU is an entry-level device architecturally, but the max frequency of 72 MHz is higher than most, which allows this part to perform tasks that are too intensive for entry-level, but don’t require the complexity of a mid-range or high-performance CPU.
In this demo, MQTT networking for smart connectivity, a 320 × 480 display over SPI with 16-bit color, and a capacitive touch keypad for user interactions were implemented on this device, as shown in Figure 1.
Figure 1 The unmounted demo includes MQTT networking, SPI-enabled display, and capacitive touch keypad. Source: Microchip
The reason this demo is achievable on an entry-level device is because of the high CPU clock speed, ample memory, and hardware peripherals. A similar device with a lower CPU clock would struggle in this application under the computational demands of rendering graphics and the latency of transferring data from the MCU to the display controller; or, in other words, the time it takes for a graphics packet to be sent to the display. These performance hits wouldn’t be a hard design failure; instead, it would be a “soft” failure from a usability perspective, which substantially impacts the user experience and perception.
Another performance benefit for embedded designs in graphics is the display controller. Unlike a larger television or computer monitor, the display controller can offload some of the more intensive tasks, like refreshing the display or storing the image buffer. Then, the embedded system only needs to send new pixel data for the changed sections in memory, saving a large number of resources.
Selective refreshing is simple in concept, but when there are a lot of assets moving around, it becomes much more challenging to implement in an efficient manner. Rather than reinventing the wheel, this application uses the Legato graphics library to handle the rendering, and Microchip Graphics Suite to design the graphic user interface (GUI).
Microchip Graphics Suite is a visual editor that allows designers to place objects and set up assets for use at runtime. The demo control screen in Microchip Graphics Suite is shown in Figure 2. When done designing, it generates code that invokes Legato underneath to handle the rendering operations.
Figure 2 Here is the view of the main screen in Microchip Graphics Suite. Source: Microchip
Moving on to the next major piece of this demo, networking. By itself, networking on its own is a herculean task. I’ve written and debugged bare-metal networking code before, and it’s a pain with hundreds of edge cases and little idiosyncrasies that break things. Besides the base complexity of implementing the protocols, the application code must format, send, receive, and parse data on a regular cadence.
Rather than go through that process again, networking and MQTT for this design were implemented by using an add-on board with a networking coprocessor that handles the network management for the main MCU. This greatly reduces the overhead on the main MCU, and it also reduces development costs. Rather than spending engineering time and (my) sanity troubleshooting a network stack implementation to figure out why the networking is not working as expected, the add-on is already tested and is known to be working.
And, to verify that this device would fit the demo needs, I verified it before writing code by using the out-of-the-box (OOB) sample for the module. The OOB program uses a PC to send commands to the add-on board and print the responses. These are saved to a log file which can be cross-referenced later to verify the sequence of operations needed to communicate with the board. Once I am confident that the module will work for this demo, development of a simple networking driver can begin. The RNWF02 add-on board (EV72E72A) uses AT commands to communicate.
Figure 3 The RNWF02 add-on board employs AT commands for communications. Source: Microchip
While the RNWF02 board handles most of the networking complexities, the networking driver on the PIC32CM-GC00 MCU still needs to keep track of the various states of connectivity the hardware is in. For instance, the Wi-Fi connection could be completed, but the device is waiting to receive a DHCP assignment. Without DHCP, an MQTT connection cannot be completed. Another possibility is that the networking is fully functional, but the MQTT broker did not accept the connection.
Finally, there is one more piece to the networking puzzle, the server side. This isn’t the direct responsibility of the main MCU, but it’s still needed to verify the module works as expected. For testing MQTT, I used the Eclipse Mosquitto plug-in broker running on a local network Home Assistant device.
Home Assistant has a few things going for it; it’s open source (Apache 2.0) and it creates a nice, visual remote GUI for the user to interact with, without going through the same process of designing and implementing an interactive user interface (Figure 4). In an end-product, a customized app would likely be used instead, but this provides a good proxy.
Figure 4 The remote GUI is built around the open-source Apache 2.0 tool. Source: Source: Microchip
The last noteworthy element to discuss in this demo is the capacitive touch keypad. This uses the MCU’s built-in peripheral touch controller (PTC) in conjunction with the touch library to determine which keys are being pressed on the keypad. Ordinarily, using the touch library is very simple, with a call to touch_process() in the main loop and checking if the measurements are done.
The touch library handles sample timings inside of its own functional calls. But in this case, since graphic rendering can take a lot of time (milliseconds), even when optimized, the touch library may not run as often as it wants, which leads to poor touch performance and, by proxy, a bad user experience.
To solve this problem, the application calls the touch library from periodic interrupt and queues but doesn’t process any touch events that occurred. Then, when the main loop is hit again, the events are dequeued and processed. This ensures the device maintains a responsive touch interface, even under heavy CPU load.
The takeaway from this application is that high-performance entry-level devices can fill a niche where an application needs to perform an intensive operation, like graphics or networking, while not being complex enough to justify a more sophisticated CPU.
At the end of the day, the point of an irrigation controller is to switch valves on and off on a timer, which is trivial for almost any MCU to accomplish. But the other value-added functions make this too intensive for entry-level performance parts, and that’s where MCUs like PIC32CM-GC00 fit in nicely.
Robert Perkel is a senior application engineer for Microchip Technology. In this role, he develops technical content such as App Notes, contributed articles, and videos. He is also responsible for analyzing use-cases of peripherals and the development of code examples and demonstrations.
Related Content
- MCUs for Space
- Connectivity invigorates MCU designs
- New i.MX MCU serves TinyML applications
- Getting started with ARM embedded MCU design
- How NoC architecture solves MCU design challenges
The post Implementing feature rich applications on entry-level MCUs appeared first on EDN.