If you want to design and develop a device that includes a next-gen microcontroller (MCU), there are four key areas around which you’ll have to make important decisions:
- Hardware development
- Software development environment
At ICS, almost 25% of every project we work on includes at least one microcontroller in the system and many, if not most, incorporate several. Let me walk you through some of the key decision areas.
1. Hardware Development
If you buy a MCU — unless you purchase one of the NXP or STM evaluation boards — you basically get a chip that can plug into a breadboard. (Got one of those?) Want to blink some lights? Be sure to buy some LEDs and your favorite current-limiting resistor. Want to add some switches? Don’t forget to buy them, as well as some 100nf capacitors to reduce the bounce and some 10k pullup resistors. Want to monitor temperature, wetness, distance, etc? You got it. Just buy them.
See a trend? If you’re doing this for personal education, there are some decent kits for around $50 that you can purchase based on one of the Arduino products. There are also breadboard kits that can be used for multiple MCUs. Personally, I like the BenchDuino. (If you buy one, check out https://github.com/AJ6CU for some add-on boards I designed.)
The recent announcement of the Raspberry Pi Foundation’s Raspberry Pi Pico is likely to create its own open source ecosystem that might eventually rival that of the Arduino. A hobbyist friendly $4 dip package with exciting specs:
- Dual core 133mhz RP2040 ARM M0+
- 256k sdram
- 2mb (internal) flash expandable off chip
- 2x SPI, I2C and UARTS
The lack of wifi and Bluetooth options may hinder widespread industrial adoption for IOT uses until they get added in a future release.
Historically, microcontrollers usually ran headless with no user interface or a simple text-based interface with LEDs and pushbuttons. With the increased processing power of modern MCUs, many are now sporting bitmapped displays and touchscreens.
Your basic choices include LCD character displays (the near indestructible 16x2 displays), OLEDs (generally pretty small < 1.3 inch), dumb TFT displays with/without touch (2.8 -3.2 inch typical) and smart displays (e.g. Nextion with built in GPU). You can easily roll your own menu system. There are a lot of examples and libraries available with a quick Google search. In addition, there are commercial projects like Qt for MCU (the “hometown favorite” of ICS), MicroEJ, Storyboard (Crank), Embedded Wizard (Tara Systems). If you use a Nextion, they include a primitive GUI builder (Note to our friends and allies at The Qt Company no worries here. Qt Design Studio is far, far advanced over the Nextion offering.)
There is also a question on which interface you want to use. Parallel mode requires a minimum of 4 GPIO lines for data, and 2 more pins for Clock and Chip Select (RS). Depending on your LCD, this can be even more, I needed 11 GPIO pins for one of the screens I was using. GPIO pins tend to be a scarce resource on most MCU’s and routing 6-11 signals on a breadboard is a receipt for long nights of trying to figure out which line is either unplugged or mis-wired. (been there, done that…)
I2C (Inter-Integrated Circuit) bus allows you to put a local “backpack chip” on the LCD and then you only need 2 GPIO pins to put data on the LCD/TFT. That makes it a popular alternative but comes at a price of additional chips in the BOM. Simple decision for personal exploration, not as easy for a mass produced device.
SPI (Serial Peripheral Interface), and its multiple successors suchs as OctoSPI, etc.) are faster at the cost of only 4 GPI pins. But if you are filling a TFT screen, it is probably the right one to choose for best user experience.
3. Software Development Environment
The Arduino IDE is simple, easy to use and free. But don’t go looking for a debugger. Plan on dropping back to “println” statements to the serial console.
Is your development more complicated? Visual Studio Code from Microsoft (runs on Windows, Mac and Linux) with the PlatformIO IDE “topper” is the next step up. And of course STM and NXP provide their own environments that often hook into their chip programmers so you can peek at memory in real time instead of using println statements. There is also the ARM Keil toolset (keil.com) and if you are using a PIC or AVR MCU, I am sure you already know about the MicroChip MPLAB and some of its predecessors tools.
Like writing interrupt handlers? What about dealing with managing multiple tasks and prioritizing which can run when? For very small projects, which tend to be single tasks, you can easily write your own interrupt service routines and use busy waits and other mechanisms to ensure your right code gets executed when needed. One might even argue that the majority of Arduino programming books that make liberal use of the “delay(500);” function call are doing a terrible disservice to young programmers by suggesting that blocking statements like this are “best practices”.
So caveat emptor: don’t stretch this beyond the simple case. For more complex cases, visit FreeRTOS.org and find a lightweight MCU OS “alternative.” It is amazingly lightweight, runs on almost every MCU, and allows you to schedule real time tasks while providing idle time to less critical tasks. And be sure to check out our three part series Get Familiar with FreeRTOS.
If you’re thinking about how microcontrollers can fit into your device strategy, get in touch. We’ll connect you with a member of our engineering MCU interest group and you can delve into specifics. Reach us here.