For a research project, we are going to send a satellite with an embedded ARM Cortex microcontroller into space early next year. Naturally, it has to work the first time. As part of all the ESA paperwork, we have to prove that we tested the hardware and software thoroughly. One pice of the that is to collect and give test coverage evidence. And there is no need for expensive tools: Free-of-charge Eclipse and GNU tools can do the job for a space mission 🙂
The GNU tools include powerful utilities to collect coverage information. With coverage I know which lines of my code have been executed, which is a very useful test metric. The GNU coverage tools are commonly used for Linux applications. But to my surprise not much for embedded application development, mostly because it requires a few extra steps to have it available? Why not using free and powerful tools for improving software quality? This article explains how to install the GNU gcov tools into the Eclipse IDE.
For many projects it would be cool to build a custom USB Joystick device, either as custom game controller for Windows or any USB host which can be used with a USB Joystick. Instead buying one, why not build my version? All what I need is a USB capable board, some kind of input (potentiometer, push buttons) and some software, and I have my USB Joystick:
The MCUXpresso IDE (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“) has one great feature: it includes debug support for the popular LPC-Link2 debug probes. That way I have yet another powerful debug probe with extra features for ARM based boards. That LPC-Link2 circuit is present on many LPCXpresso boards from NXP. So why not using it to debug it my custom hardware?
In “Tutorial: Secure TLS Communication with MQTT using mbedTLS on top of lwip” I already used TLS for a secure communication, but I had not enabled server certificate verification. This article is about closing that gap.
One of the most important aspects of the ‘IoT’ world is having a secure communication. Running MQTT on lwip (see “MQTT with lwip and NXP FRDM-K64F Board“) is no exception. Despite of the popularity of MQTT and lwip, I have not been able to find an example using a secure TLS connection over raw/native lwip TCP :-(. Could it be that such an example exists, and I have not found it? Or that someone implemented it, but has not published it? Only what I have found on the internet are many others asking for the same kind of thing “running MQTT on lwip with TLS”, but there was no answer? So I have to answer my question, which seems to be a good thing anyway: I can learn new things the hard way :-).
MQTT is a lightweight and broadly used internet protocol (see “MQTT with lwip and NXP FRDM-K64F Board“). And probably the majority of IoT applications today are using Mosquitto as server (or ‘broker’ in MQTT language). By default, Mosquitto is using a protocol without encryption. In “Introduction to Security and TLS (Transport Layer Security)” I have covered the basics and needs for encryption. This article is about how to enable Mosquitto and clients to use the TLS protocol.
IoT (Internet of Things) is all about connecting to the internet. And even more it is about security. Without security and without encrypted communication, everyone possibly can see what I send or receive. And this is especially bad if passwords or user names are sent in an unencrypted way. So encryption and secure communication is key. The solution to that is to use a connection which uses the TLS (Transport Layer Security) protocol.
I want to use TLS for my MQTT communication (see “MQTT with lwip and NXP FRDM-K64F Board“). I’m still learning MQTT, and I’m even more learning about the fundamentals of security and security protocols. So this article is about what I have learned recently, and what I can use to make my data communication secure: Network stack architecture, symmetric and asymmetric encryption and certificates.
In the area of IoT (Internet of Things), one obvious need is to have a way to send and receive data with an internet protocol. MQTT (or Message Queue Telemetry Transport) is exactly like that: a light-weight Machine-to-Machine communication protocol. With the MQTT protocol a microcontroller (or ‘client’) can send data and/or subscribe to data. For example to the Adafruit.IO:
In “MCUXpresso IDE: Importing Kinetis Design Studio Projects” I explained how Kinetis Design Studio projects can be imported and used inside the MCUXpresso IDE. Processor Expert projects can be used, but no new components added, modified or new Processor Expert projects created. To fully use Processor Expert, two plugins need to installed, and this is what this article is about.
To me, software and tools are by far more important than the microcontroller. Because the silicon is a ‘one time kind of thing’, where the software has to be maintained and working over a longer time. And at least my software usually needs to be ported to a new device, so portability and available software and tools are critical to me.
The combination of MCUXpresso SDK (formerly Kinetis SDK) and Processor Expert is unfortunately not supported by NXP. But I have found a way to get them work together in a nice way, and this article is about making that combination possible :-).
The concept of Linux (Open Source, broad developer base and broad usage) is a success story. While there is a lot of diversity (and freedom) in the Linux world, Linux is Linux and again Linux :-). And the world has (mostly) standardized on Linux and its variants on the high embedded system side.
On the other side, the ‘middle and lower end’ Embedded world is fragmented and in many aspects proprietary. So it was no surprise to me when the Linux Foundation announced the ‘Zephyr’ project back in February 2016:
“The Linux Foundation Announces Project to Build Real-Time Operating System for Internet of Things Devices. Open source Zephyr™ Project aims to deliver an RTOS; opens call for developers to help advance project for the smallest footprint IoT devices.“
Ζεφυρος (Zephyros) is the Greek good of spring and the west wind. Obviously this inspired the logo for the Zephyr project:
When working and debugging a bootloader, debugging can be a challenge: During debugging the bootloader, a new binary gets loaded into the microcontroller address space which is unknown to the debugger. As soon as I step into the newly loaded binary, I only see assembly code, with that ugly “No source available” in Eclipse:
But wait: GDB is able to do pretty much everything you can imagine, so here is how to debug multiple binaries with GDB and Eclipse, and to turn the above into something which is easy to debug:
One of the biggest road blocks (beside of closed source) using the BLE (Bluetooth Low Energy) stack from NXP is that it requires expensive tools to compile and build the stack. The good news is that I have now the NXP BLE stack for the Mikroelektronika Hexiwear ported to Eclipse and GNU gcc build tools for ARM 🙂
Now I can use the data on the Hexiwear over BLE with the gatttool (see “Tutorial: Hexiwear Bluetooth Low Energy Packet Sniffing with Wireshark” and “Tutorial: BLE Pairing the Raspberry Pi 3 Model B with Hexiwear“). This article is taking things a step further and uses a Python script on Linux to access the sensor data on the BLE device:
The Achilles Heel of the Mikroelektronika Hexiwear is its charging: the charging and USB connector are only designed for a limited number of plug-unplug cycles, and it does not have a wireless charging capability like the Apple iWatch. Until now! I have built a DIY wireless charging system for the Hexiwear 🙂 :
For a university reasearch project I try to pair the Raspberry Pi 3 with a Mikroelektronika Hexiwear using BLE (Bluetooth Low Energy). Most of things worked after a lot of trial and error, but at a certain point I was stuck trying to write to send data from the Raspy to the BLE device.The Hexiwear BLE protocol description is very thin, so I ended up using a BLE sniffer to reverse engineer the protocol with Wireshark.
The Hexiwear (see “Hexiwear: Teardown of the Hackable ‘Do-Anything’ Device“) is a small and portable sensor node with built-in BLE (Bluetooth Low Energy) transceiver. In a research project we try to use multiple Hexiwear in a classroom environment and to collect sensor data on a Raspberry Pi. The Raspberry Pi 3 Model B running Linux has an on-board BLE transceiver too, so why not binding them (wirelessly) together?
Well, things seemed easy at the beginning, and as always, there are many things to learn on a journey like this…