Programming on Carmine Noviello

How to precisely measure microseconds with STM32

Fri, 04 Sep 2015 09:41:12 +0000

I received this apparently simply question from a reader of this blog: how can I delay a fistful of microseconds in STM32? That is, how to measure microseconds precisely in STM32?

The answer is: there are several ways to do this, but some methods are more accurate and other ones are more versatile among different MCUs and clock configuration.

Let’s consider one member of the STM32F4 family: STM32F401RE, the MCU that equips the STM32Nucleo-F401RE board. This micro is able to run up to 84Mhz using internal RC clock. This means that ever 1µs, the clock cycles 84 times. So, we need a way to count 84 clock cycles to assert that 1µs is elapsed (I’m assuming that you can tolerate the internal RC clock 1% accuracy).

Adding ethernet connectivity to a STM32-Nucleo

Fri, 28 Aug 2015 05:23:37 +0000

One drawback of the Nucleo ecosystem is the lack of a version with ethernet connectivity or a dedicated shield officially supported by ST. There are 90 different STM32 MCUs available that provide an Ethernet MAC interface (this means that only an external ethernet transceiver - also called phyter - and few other things are required to bring your MCU to the IoT world). STM32Cube (the HAL officially supported by ST) also provides support for lwIP stack. But, all the current Nucleo boards are designed with a MCU without an Ethernet interface (I think that the main reason is that only two STM32 MCUs with Ethernet MAC are available in LQFP-64 package and the Nucleo boards are designed to be pin-to-pin compatible between its releases - L0, F1, etc). This means that without a dedicated expansion shield it is impossible to add network connectivity to our Nucleo. And this is a sin considering what that MCU can do.

Getting started with STM32F746G-DISCO

Mon, 13 Jul 2015 05:06:56 +0000

ST Microelectronics recently expanded its portfolio of STM32 microcontrollers with the new STM32F7 family. These are the new best-in-class MCUs from ST, with a Cortex-M7 core able to run up to 216Mhz (future releases will run up to 400Mhz with 2000 CoreMark index), with an internal flash up to 1Mb and 360Kb of RAM. STM32F7 is also able to run from external flash memory without performance penalty, thanks to a L1 cache (this is probably the most interesting aspect of these MCUs). STM32F7 are targeted for High-end embedded applications, especially to multimedia ones, and I think that it’s far from low-budget applications and hobbyist uses. At the time of writing, these MCUs are quite pricy, ranging from 12€ to 20€/pcs for low-volume orders. This is definitely a really high price, especially if you consider that you can find around Cortex-A7 MCUs for less than 10€. But I think that the price will be dramatically reduced in the future.

Running FreeRTOS on a STM32Nucleo using a free GCC/Eclipse toolchain

Mon, 22 Jun 2015 05:50:14 +0000

Using a micro like the STM32F4, able to run up to 160Mhz, with 512Kb of flash and about 100k of RAM, without using an operating system is a nonsense. Although it’s perfectly possible to use some forms of cooperative scheduling to execute firmware activities, basically this not convenient especially when dealing with low level events related to hardware (eg. interrupt handling) and aspects related to synchronization. As long as your firmware starts to grow, you’ll need constructs to synchronize firmware activities, like queues or semaphores. Moreover, especially when dealing with low-power devices, a busy spin (while(some condition);) it’s not the best solution if you have to fight with mAh.

Conditional breakpoint while debugging STM32

Tue, 09 Jun 2015 16:34:33 +0000

It’s a really common situation when working with hardware (especially while debugging asynchronous events): to stop execution while debugging only if a given event occurs. This is also called conditional breakpoint.

If you are working with the STM32 family and the CMSIS ARM package for Cortex-M processors, and your toolchain is GCC-based with GDB as debugger, you can place in your code this instruction:

#include "cortexm/ExceptionHandlers.h"
...
if(condition) {
 __DEBUG_BKPT();
}
...

GDB will automatically stop when the event occurs at that line.