STMicroelectronics recently launched STM32CubeMonitor, a runtime variable monitoring and visualization tool that offers a web interface for remote connections as well as a graphical interface to create custom dashboards. It ensures developers can efficiently monitor their application through a graphical interface that relies on Node-RED, a flow-based programming tool that enables users to create complex representations of data with no coding at all. It will enable them to more easily debug their software, and analyze behaviors, without having to disrupt an existing code base. Additionally, users can share their dashboard on the Node-RED and ST communities to build on one another, and we wrote a detailed Wiki, which covers the major concepts behind the application, its installation, and how to get started.
When developers start their project, they very often gravitate toward STM32CubeMX. The graphical user interface helps them start configuring the pinout and clock tree of their MCU, and the software generates headers files. The next step is writing the application. STM32CubeIDE is free and integrates STM32CubeMX so users can go back and forth, easily scaling their project up or down. Once the code is ready, STM32CubeProgrammer facilitates flashing operations. STM32CubeMonitor becomes another milestone in the developers’ journey as they can now run their software in the wild and monitor its behavior. Despite anyone’s best efforts, it’s impossible to squash every bug or plan for every use case. It is thus crucial to be able to monitor a device to resolve issues and improve the final user’s experience proactively.
STM32CubeMonitor, Using Node-RED to Make Runtime Monitoring More Accessible
Keeping track of registers, variables in memory, interrupts, and the myriad of events that take place at any given moment is daunting. Hence, coding any sort of tool to monitor them all is often so demanding that teams do not have the resources to invest in this type of endeavor. It’s the reason why STM32CubeMonitor relies on Node-RED, which works by simply dragging and dropping graphical representations of a program’s element onto a canvas to create a flow, meaning a sequence of events. Without entering a single line of code, users can create graphs, chart plots, or generate gauges that will help them visualize values in a counter, data from a sensor, or many other aspects of an application. And since STM32CubeMonitor includes a web server, it’s possible to enjoy these visualizations on any PC or mobile browser, whether on the local network or remotely.
Writing a similar program from scratch, even with the most popular scripting languages today, would take significantly more time and require a lot more programming expertise. The graphical nature of the platform bypasses all this and the remote connectivity of the solution vastly increases its usefulness. Moreover, thanks to the Node-RED and ST community, users can start by simply looking at dashboards from other users and organically learn by studying other people’s example. The Node-RED interface is extensive and allows to easily take advantage of common networking protocol. Since there are modules to send alerts by email or push data to a cloud platform by using MQTT, developers can do more than traditional monitoring. For instance, one could use STM32CubeMonitor to send sensor data to a cloud with an ST development board and a simple Linux machine to act as a gateway.
STM32CubeMonitor, Relying on the entire ST Ecosystem From Prototyping to the Final Design
To make the first experience with STM32CubeMonitor more intuitive, the ST Wiki explains in detail how developers could monitor a variable within an application in just two straightforward steps. Users select the start address of the data they are tracking in memory and its type. To assist in this task, we have a guide showing how to get addresses from ELF files. The interface will then ask the user to select a STLINK probe among the list of detected devices. This method could be highly valuable to determine if a parameter is behaving as developers expect or if a condition triggers a surprising behavior. It is also possible to create alerts. For instance, one could create a flow to receive an alert when the system throws an interrupt to detect a malfunction.
The blog has been republished with permission. For more information kindly visit: ST Blog
