The ecosystem view around an embedded system development

The design implements an intelligent open/close roof system to allow rainwater into a greenhouse. The post The ecosystem view around an embedded system development appeared first on EDN.

Electronics Nov 17, 2025 0 1 Add to Reading List

The ecosystem view around an embedded system development

Like in nature, development tools for embedded systems form “ecosystems.” Some ecosystems are very self-contained, with little overlap on others, while other ecosystems are very open and broad with support for everything but the kitchen sink. Moreover, developers and engineers have strong opinions (to put it mildly) about this subject.

So, we developed a greenhouse that sustains multiple ecosystems; the greenhouse demo we built shows multiple microcontrollers (MCUs) and their associated ecosystems working together.

The greenhouse demo

The greenhouse demo is a simplified version of a greenhouse controller. The core premise of this implementation is to intelligently open/close the roof to allow rainwater into the greenhouse. This is implemented using a motorized canvas tarp mechanism. The canvas tarp was created from old promotional canvas tote bags and sewn into the required shape.

The mechanical guides and lead screw for the roof are repurposed from a 3D printer with a stepper motor drive. An evaluation board is used as a rain sensor. Finally, a user interface panel enables a manual override of the automatic (rain) controls.

Figure 1 The greenhouse demo is mounted on a tradeshow wedge. Source: Microchip

It’s implemented as four function blocks:

A user interface, capacitive touch controller with the PIC32CM GC Curiosity Pro (EA36K74A) in VS Code
A smart stepper motor controller reference design built on the AVR EB family of MCUs in MPLAB Code Configurator Melody
A main application processor with SAM E54 on the Xplained Pro development kit (ATSAME54-XPRO), running Zephyr RTOS
A liquid detector using the MTCH9010 evaluation kit

The greenhouse demo outlined in in this article is based on a retractable roof developed by Microchip’s application engineering team in Romania. This reference design is implemented in a slightly different fashion to the greenhouse, with the smart stepper motor controller interfacing directly with the MTCH9010 evaluation board to control the roof position. This configuration is ideal for applications where the application processor does not need to be aware of the current state of the roof.

Figure 2 This retractable roof demo was developed by a design team in Romania. Source: Microchip

User interface controller

Since the control panel for this greenhouse normally would be in an area where water should be expected, it was important to take this into account when designing the user interface. Capacitive touch panels are attractive as they have no moving parts and can be sealed under a panel easily. However, capacitive touch can be vulnerable to false triggers from water.

To minimize these effects, an MCU with an enhanced peripheral touch controller (PTC) was used to contain the effects of any moisture present. Development of the capacitive touch interface was aided with MPLAB Harmony and the capacitive touch libraries, which greatly reduce the difficulty in developing touch applications.

The user interface for this demo is composed of a PIC32CM GC Curiosity Pro (EA36K74A) development kit connected to a QT7 XPlained Pro Extension (ATQT7-XPRO) kit to provide a (capacitive) slider and two touch buttons.

Figure 3 The QT7 Xplained extension kit comes with self-capacitance slider and two self-capacitance buttons alongside 8 LEDs to enable button state and slider position feedback. Source: Microchip

The two buttons allow the user to fully open or close the tarp, while the slider enables partial open or closed configurations. When the user interface is idle for 30 seconds or more, the demo switches back to the MTCH9010 rain sensor to automatically determine whether the tarp should be opened or closed.

Smart stepper motor controller

The smart stepper motor controller is a reference design that utilizes the AVR EB family of MCUs to generate the waveforms required to perform stepping/half-stepping/microstepping of a stepper motor. By having the MCU generate the waveforms, the motor can behave independently, rather than requiring logic or interaction from the main application processor(s) elsewhere in the system. This is useful for signals such as limit switches, mechanical stops, quadrature encoders, or other signals to monitor.

Figure 4 Smart stepper motor reference design uses core independent peripherals (CIPs) inside the MCUs to microstep a bipolar winding stepper motor. Source: Microchip

The MCU receives commands from the application processor and executes them to move the tarp to a specified location. One of the nice things about this being a “smart” stepper motor controller is that the functionality can be adjusted in software. For instance, if analog signals or limit switches are added, the firmware can be modified to account for these signals.

While the PCB attached to the motor is custom, this function block can be replicated with the multi-phase power board (EV35Z86A), the AVR EB Curiosity Nano adapter (EV88N31A) and the AVR EB Curiosity Nano (EV73J36A).

Application processor and other ecosystems

The application processor in this demo is a SAM E54 MCU that runs Zephyr real-time operating system (RTOS). One of the biggest advantages of Zephyr over other RTOSes and toolchains is the way that the application programming interface (API) is kept uniform with clean divisions between the vendor-specific code and the abstracted, higher-level APIs. This allows developers to write code that works across multiple MCUs with minimal headaches.

Zephyr also has robust networking support and an ever-expanding list of capabilities that make it a must-have for complex applications. Zephyr is open source (Apache 2.0 licensing) with a very active user base and support for multiple different programming tools such as—but not limited to—OpenOCD, Segger J-Link and gdb.

Beyond the ecosystems used directly in the greenhouse demo, there are several other options. Some of the more popular examples include IAR Embedded Workbench, Arm Keil, MikroE’s Necto Studio and SEGGER Embedded Studio. These tools are premium offerings with advanced features and high-quality support to match.

For instance, I recently had an issue with booting Zephyr on an MCU where I could not access the usual debuggers and printf was not an option. I used SEGGER Ozone with a J-Link+ to troubleshoot this complex issue. Ozone is a special debug environment that eschews the usual IDE tabs to provide the developer with more specialized windows and screens.

In my case, the issue occurred where the MCU would start up correctly from the debugger, but not from a cold start. After some troubleshooting and testing, I eventually determined one of the faults was a RAM initialization error in my code. I patched the issue with a tiny piece of startup assembly that ran before the main kernel started up. The snippet of assembly that I wrote is attached below for anyone interested.

The moral of the story is that development environments offer unique advantages. An example of this is IAR adding support for Zephyr to its IDE solution. In many ways, the choice of what ecosystem to develop in is up to personal preference.

There isn’t really a wrong answer, if it does what you need to make your design work. The greenhouse demo embodies this by showing multiple ecosystems and toolchains working together in a single system.

Robert Perkel is an application engineer at Microchip Technology. In this role, he develops technical content such as application notes, contributed articles, and design videos. He is also responsible for analyzing use-cases of peripherals and the development of code examples and demonstrations. Perkel is a graduate of Virginia Tech where he earned a Bachelor of Science degree in Computer Engineering.