Evolving the fundamental component and enhancing UX
Hi everyone,
today I am glad to write a post about an incremental upgrade to the HARDWARIO IoT Kit, however, a very crucial one for the overall user’s experience. I will discuss the new version of the fundamental component in the HARDWARIO system – the Core Module version 2. The first version of the Core Module has been with us for more than 2 years already and it has done an incredible job, providing brain and communication to thousands of wireless nodes.
So what’s this upgrade about?
First, let me briefly jump back in the history… We released similar product called Radio Dongle to the market in summer 2017. This item had implemented USB to UART chip from FTDI (FT231X) that is connected between the USB connector and the STM32 microcontroller. The purpose of this chip was dead simple – to provide a reliable serial communication on the host system (and without drivers issues). And that worked really well. But there was a problem – the form factor was a pen drive which did not offer any space for buttons. And we needed buttons to put the microcontroller into the bootloader mode as we did it in the Core Module version 1, right? So there was a need to implement RESET and BOOT signal control over the FTDI chip. Controlling these signals is all you need to invoke the MCU’s ROM bootloader. It was possible with a bit of help with a few discretes in the circuitry. There are several bootloader communication possibilities – the one used on the Core Module version 1 is called USB DFU Bootloader. Another possibility is the UART Bootloader – and that is what we have been using in the Radio Dongle.
After the very first verification, not only we have solved the problem – the absence of the mechanical buttons – but we have also observed increased speed in the firmware programming. It is worh noting that we have also avoided issues with the USB DFU drivers on the Windows platform. Obviously that was a must-have feature we had to bring to the Core Module and unify the programming technique.
So here we go! The primary reason for the Core Module version 2 is the unified programming and communication interface. But it brings more advantages than just button-less programming…
Let’s talk about the HARDWARIO tools for a while. Around the same time we finished the Radio Dongle development, we decided to create a CLI tool that will simplify the workflow with the HARDWARIO firmware in general. The HARDWARIO Firmware Tool (bcf) was born. It is a simple Python application distributed through PyPI and available to all platforms (it takes one command to set it up on your machine). This tool works like a package manager for the pre-compiled binaries available nt our GitHub, but also allows you to program custom firmware, search in firmware repository, list available serial devices and much more.
But there is one feature many people are not yet aware of and that is the logging facility. Thanks to the fact we have all the time available serial port, we can use it in a comfortable way for reading logs from firmware. We have support for this in the bc_log API and in the HARDWARIO Firmware Tool. You can hook to your firmware log with the simple bcf log –device <DEVICE> command. But you can also chain commands together, e.g. bcf flash –device <DEVICE> <FIRMWARE> –log, which will flash the device and immediately connect it to your logging console after releaseing the device from reset. The logging API has support for four log levels (DEBUG, INFO, WARNING, ERROR) and each log level has its appropriate color. Also, there is an option to switch the colors off, or record it to a file (see the bcf log –help for more details). Besides the log level information, you also know the timestamp of the logged event. This you can configure from your firmware whethere it should be in the absolute format (number of milliseconds from the reset), or in the relative format (number of milliseconds from the last logged event). This greatly enhances firmware debugging!
Here you can see output from the bc_log example code from SDK
bc_log_init(BC_LOG_LEVEL_DEBUG, BC_LOG_TIMESTAMP_ABS);
bc_log_debug("Debug output using %s", "bc_log_debug()");
bc_log_info("Info output using bc_log_info()");
bc_log_warning("Warning output using bc_log_warning()");
bc_log_error("Error output using bc_log_error()");
There are more enhancements than that. There is just one push button (for application purposes) that is more easily accessible right above the Micro USB connector. Also we have center-aligned the red LED, debug connector and the push button. The PCB layout is now using 6 layers (instead of 4) and better ground plane design has slightly improved the radio communication range.
The good news is that the Core Module version 2 is fully compatible with the version 1 and we are in no way abandoning support for the old good friend. On the other hand, our aim is to make the user’s experience as much seamless as possible and therefore we are updating the documentation with the main focus on the new version of the Core Module. However, we have a dedicated page comparing Core Module 1 and Core Module 2 differences altogether with the instructions how to work with the USB DFU mode on the old one.
Despite increased component cost on the new version, the price remains the same as for the old version.
That’s it for the moment and stay tuned!
