The long Easter Weekend has its benefits, beside of preparing lecture material and writing up geeky technology articles :-). I love that view with meadows sprinkled with all the Dandelion, and the snow-covered mountains in the back. Back on the left the peaks of the Mythen.
I admit: my work laptop machine is running a Windows 10 OS by default. But this does not prevent me running Linux in a Virtual Machine (VM). Each host platform has its benefits, and I don’t feel biased to one or the other, but I have started using Ubuntu more and more, simply because I have worked more on Embedded Linux projects. While I have used mostly Windows with Eclipse for NXP LPC, Kinetis and i.MX platforms in the past, I started using Ubuntu too from last year with the NXP MCUXpresso SDK. I did not find much documentation about this on the web, so I thought it might be a good idea to write a tutorial about it. So here we go…
My mantra is *not* to use any floating point data types in embedded applications, or at least to avoid them whenever possible: for most applications they are not necessary and can be replaced by fixed point operations. Not only floating point operations have numerical problems, they can lead to performance problems as in the following (simplified) example:
The ARM Cortex cores are everywhere. I like (and use) them a lot. Don’t take me wrong: maybe ARM needs some competition? It is very refreshing to see that something new is getting a lot of attention: RISC-V!
For some projects it is not possible to have the device under debug available on my desk: the board might be in another room, on another site or in a place where physical access is not possible or even dangerous. In that case an IP-based debug probe (see Debugging ARM Cores with IP based Debug Probes and Eclipse) is very useful: as long as I can access its IP address, that works fine. It is an excellent solution even if the board is moving or rotating: hook it up to a WLAN access point and I still can use it as it would be on my desk.
But what if I have a debug probe only connected to USB? This article shows how to turn a USB debug probe into a IP-based debug solution: that way I can easily debug a board from remote, connected to the network:
LoRa and LoRaWAN is getting the de-facto wireless IoT network in my area. No surprise that traditional telecom providers like Swisscom trying to monetize the ‘Internet of Things’ area. Luckily there is an open and free alternative: https://www.thethingsnetwork.org/. Volunteers, enthusiasts and members in the different TTN communities build gateways and offer free LoRaWAN network access. I wanted to contribute to that grassroots movement with building my gateway, providing LoRaWAN access to my neighborhood.
Most of the time software needs some way to configure things: depending on the settings, the software will do different things. For example the software running on the microcontroller on top of the Raspberry might have the OLED LCD available or not:
Raspberry Pi and tinyK22 (NXP Kinetis K22FN512) with OLED LCD
Sometimes I start a project with an ARM microcontroller, and in the middle of the project I find out that it was a wrong choice at the beginning and I need to switch the microcontroller derivative or even the used ARM core. With little knowledge of the project structure and the files needed, such a switch is not the easiest thing, but definitely possible.
The NXP LPC845-BRK board is a tiny an inexpensive (sub $6) breakout board. The board includes a CMSIS-DAP (LPC11U35) on-board debug probe which can be used as a debug probe to debug any NXP LPC, Kinetis or i.MX RT device 🙂
One great thing with that new NXP LPC845-BRK board is that it is possible to use it with any standard SWD/JTAG debugger, as it has the 10pin debug header present on the board. It is not populated by default, because the LPC845-BRK includes a CMSIS-DAP debug probe already. But if I want to use a SEGGER J-Link, a P&E Multilink or the NXP LPCLink2, this is certainly something to consider: