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…
For many of my applications I need to measure a distance. I have used ultrasonic sensors, but there view angle (beam) is not able to detect smaller objects, it very much depends on the object surface and angle, it is slow and not very precise. I have used infrared sensors, but here again it depends on the infrared reflection of the object in range, it depends the amount of reflected light is not really telling much about the distance, and yet IR reflection is subject of material and object targeted.
But there is yet another sensor type to consider: ToF! ToF (or Time-of-Flight) sensors have a built-in LIDAR: The sensor is sending out light pulses and measures how much time it takes for the light to come back. Similar to ultrasonic sensors (see “Tutorial: Ultrasonic Ranging with the Freedom Board“), but instead of ultrasonic it uses an infrared laser light. Or think about a radar system using an infrared laser light.
The year is coming to an end, the Holiday season is approaching. In case you are looking for a nice present: I have completed my version of a sand clock: a clock writing the time into sand:
If you are interested to build your own version, I have documented the different steps with tips and tricks…
It seems to me that not many developers use hardware trace? ARM indicates that maybe only <5% of developers are using trace. Too bad! Why are all the ARM Cortex microcontroller vendors putting a powerful hardware (and complicated!) trace engine into their devices, if only few developers are using it? Seems like a waste of silicon and an unnecessary price adder? Well, hardware trace can be a life saver: Because only with hardware trace the most complicated bugs and problems can be solved. And maybe because only the best are using it ;-).
Command line tools to build applications are great. But productivity goes up if I can use the standard Eclipse environment with GNU tools. This tutorial is about how to use standard and free GNU and Eclipse tools to build my FreeRTOS application for the ARM Cortex-M4 on i.MX7 🙂 :
My Toradex i.MX7Dual module comes with a preflashed Linux distribution (see “Tutorial: First Steps with NXP i.MX7 and Toradex Colibri Board“). As with any other things, Linux gets updated from time to time, and Toradex publishes new firmware. In this article I’m documenting how I can update Linux in the external FLASH on that module.