Be aware: Floating Point Operations on ARM Cortex-M4F

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:

#define NOF  64
static uint32_t samples[NOF];
static float Fsamples[NOF];
float fZeroCurrent = 8.0;

static void ProcessSamples(void) {
  int i;

  for (i=0; i < NOF; i++) {
    Fsamples[i] = samples[i]*3.3/4096.0 - fZeroCurrent;
  }
}

Continue reading

Tutorial: RAK813 LoRaWAN+BLE+GPS Sensor Node with Eclipse IDE

In the IoT world, it is all about security, connectivity and low power. LoRaWAN with the Things Network is able to connect devices over several kilometers, and I’m running my gateway for it already (see “Contributing an IoT LoRaWAN Raspberry Pi RAK831 Gateway to The Things Network“). This tutorial is about building a BLE+LoRaWAN+GPS sensor node with GNU tools and Eclipse:

LoRa+BLE with RAK813 and LPC845

LoRa+BLE with RAK813 and LPC845

Continue reading

Running FreeRTOS on the VEGA RISC-V Board

In “Debugging the RV32M1-VEGA RISC-V with Eclipse and MCUXpresso IDE” I described how to build and debug applications for the VEGA RISC-V board. In this article I describe how to enable FreeRTOS for RISC-V, based on the latest FreeRTOS V10.2.0 release.

Blinky with FreeRTOS on the VEGA RISC-V Board

Blinky with FreeRTOS on the VEGA RISC-V Board

Continue reading

Debugging the RV32M1-VEGA RISC-V with Eclipse and MCUXpresso IDE

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!

RV32M1

RV32M1 (VEGA)

Continue reading

Remote Debugging with USB based JTAG/SWD Debug Probes

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:

IP Based Debugging with USB Debug Probe

IP Based Debugging with USB Debug Probe

Continue reading