STM32 Nucleo Boards

I have just received two nucleo boards: the L152RE and the F401RE. This is my first impression.

The Nucleo boards are the last entry level boards in the STM32 family.

STM32 Nucleo advertising

In the last years ST has provided the fantastic Discovery boards. Those boards, specially the STM32F3, STM32F4, STM32F401 and STM32F429 pack a lot of power for their price. Unfortunately they are not easy on the beginners. Of course there are projects like ChibiStudio or CoIDE that ease the programming of these boards but they are not as easy as Arduinos, for instance.

But that changes with the Nucleo boards. Those boards are mbed enabled. Mbed is a development platform for ARM microcontrollers. It started with the ARM Embed board based on NXP LPC microcontrollers. What is special about this platform is that it is web based. You don't need to install any toolchain in the computer and the source files are available everywhere. And, as in the Arduino case, you get libraries for all the board peripherals. Off course, a web based compiler is not the solution for everyone. For instance you cannot work offline.

mbed web compiler

You write the code from scratch or from one of the examples available. Hit the compile button and a binary file is generated that you can directly drop on the mbed board that shows on the PC as a mass storage drive. Quite easy.

The Nucleo F401RE Board

The nucleo boards are not the only mbed boards. They are only the last ones in the mbed world but are well positioned next to several cheap boards from Frescale that are mbed enabled too and range from the basic 32KB Flash FRDM-KL05Z to the 1MB Flash Ethernet enabled FRDM-K64F.

The original LPC mbed boards are not so well positioned in price or specs.

In this article I will talk about the F401RE Board that is the best specified nucleo board available. I don't have first hand experience on the Freescale mbed enabled boards buy they seem to be very interesting boards too.

Nucleo F401RE board

The Nucleo F401RE board includes an ARM Cortex M4 STM32F401RET6 microcontroller with 512KB of flash memory. As all nucleo boards are equally priced I see little point in buying any other nucleo board unless you have very special requirements.

In the above figure I have encircled the two clock crystal empty slots. Some figures show them populated but you must be aware that the they are not in the board. You will normally get the clock from the upper side of the board that includes the USB connector but if you separate both board pieces you will have no crystal clock for the board. And, of course, if you need a 32kHz clock for the real time clock you would need to solder it yourself.

The nucleo boards are compatible with the now "standard" Arduino headers.

F401RE Arduino headers

If, as in my case, you don't mind about Arduino compatibility you can use the dual row Morpho headers that include more signals that the Arduino headers and don't include the damm non 100 mil pitch space of the right arduino headers.

F401RE Morpho headers

This is a very capable board. The ARM Cortex M4 processor includes a FPU that speeds any 32bit floating point operation. As an example I have tested that the board can calculate 40000 times the square root of a float quotient in only 25ms. Its not as fast as a STM32F4 Discovery board but is a quite good spec for a board so cheap and easy to program.

All in all I'm quite pleased with this board. Packs a lot of power for its price and its very easy to program.
In the future I plan to try to program it using more traditional development tools under eclipse but for now mbed is working quite well. In fact I like this environment more that the Arduino one.

Intel Galileo. What will I make?

Some time ago I applied for the Intel Galileo university program and I was given ten Intel Galileo boards to be used on education projects. I supposed that the first I should do is learn to use the board before giving it to my students. This is the first blog entry about this board.

Intel Galileo Board Box

The Expectation

The Intel Galileo board promises a lot. It is an Arduino compatible board that uses a 400MHz 32 bit Intel® Quark System on a Chip (SoC) X1000 Processor. That makes it the fastest Arduino Board in the market while we wait for the Arduino Tre upcoming board.

Intel Galileo Board

The Galileo board includes a lot of functionality:

• Ethernet LAN RJ45 socket
• RS-232 COM 3.5mm Jack
• USB Client Socket
• USB Host Socket
• SD Slot
• Mini PCIe connector for WLAN Card
• One SPI port
• One I2C port

And, of course, the full Arduino UNO headers with 14 Digital lines (6 with PWM functionality) and 6 analog lines. The full board specification can be found in this link.


The board can be programmed using a special Arduino IDE with version 1.5.3. The IDE makes easy to program the board as any other Arduino board.

That all sounds good , ok?
Well not everything is so good in this board.

The Reality

The main problem about this board is in the GPIO implementation.
Intel decided to use a Cypress CY8C9540A I/O expander to implement most of the I/O functionality.

The Cypress CY8C9520A Expander Chip

The selected I/O expander is quite powerful. It gives 40 GPIO lines and 8 of them can generate PWM. I suspect that Intel selected this chip in order to mimic the standard Arduino I/O functionality. The problem is the I2C link that communicates this I/O expander with the Quark CPU. It operates at a only 100kHz. That means that the in practical terms the maximum GPIO frequency is 230Hz for most of the I/O pins.

Two lines (IO2 and IO3) that are normally routed through the I/O expander can be alternatively routed directly to the SoC chip and thus can operate at a much higher frequency. But only those two pins can benefit from high speed operation.

The analog readings are provided by an external  AD7298 ADC but at least this device connects at 4MHz with the SoC chip using a SPI interface.

AD7298 ADC (to the right)

The catch is that most Arduino compatible I/O lines, analog included, are routed trough TS5A23159 multiplexers that are controlled by the outputs of the I/O expander controlled by the slow 100kHz I2C interface. So changing from digital to analog mode on a pin is quite slow.

The final problem is that the SoC chip don't run directly the Arduino sketches. The SoC runs under Linux and the running sketch is one process in the myriad of processes of the Linux operating system. As Linux is not real time you cannot guarantee a deterministic timing on the sketches. If the operating system happens to be under high load you can expect a lot of jitter on the sketches.

All in all, the Galileo Board includes a power hungry (it cannot run on USB only) 400MHz Quark SoC but a lousy ATmega328 at 16MHz on an Arduino UNO runs circles around it in raw GPIO bandwidth.

Arduino UNO

So, what will I make?

In the end the Galileo Board delivers less than I expected due to the small I/O bandwidth that the 100kHz I2C port expander provides. The Linux operating system also don't help to obtain a deterministic reaction time. As a conclusion the Galileo Board is not a good board for fast real time operation. Better use a normal Arduino board or, better yet, a STM32 Discovery board for fast I/O operation.

Following the Arduino path

If you want, however, an Arduino compatible board that includes support for Ethernet, SD card storage and a real time clock and provides a lot of RAM and ROM memory, this is a very capable board if you don't mind the the slow GPIO bandwidth.

I use the Arduino Leonardo board in a mixed analog-digital lab course for students without the proper programming foundations to use a more capable board.

Arduino Leonardo Board

For applications that need more memory and speed I use the PIC32 Pinguino board. For the price of a Leonardo you get a board that features much more memory and speed and includes several goodies as a SD card slot and a 32kHz clock. I don't use this board as the main one because the Leonardo is better supported by the Arduino community.

PIC32 Pinguino Board

Now I have also the Galileo. I plan to use the Galileo in Arduino projects that need a lot of memory or network connectivity and don't need fast GPIO operation.

Following the Linux path

I am more interested, however, in the Galileo as a Linux board, not as an Arduino one. For some kind of projects I'm interested in controlling the board from Linux eliminating any Arduino IDE operation. That puts this board next to the Raspberry Pi and the BeagleBone / BeagleBone Black boards. 

BeagleBone Board

Raspberry Pi Model B

Both of the Raspberry Pi and BeagleBone boards are faster. Also both the Raspberry Pi and the BeagleBone Black provide a video output that the Galileo lacks. So the Galileo will only be useful for embedded operation not as a desktop computer substitute.

Compared with the Raspberry Pi the Galileo has some strong points:

• One USB client that can work as a serial over USB terminal
• 14 Digital lines and 6 Analog lines with both 3.3V and 5V functionality
• A RS-232 level Serial
• A battery backed RTC clock  
• Arduino Shield Compatibility
• Four mounting holes that make it easier to use without a case.

Off course the Raspberry Pi has also some strong points:

• Faster operation
• Much more capable Linux distribution
• Video and audio output
• Camera and LCD connectors
• Cheaper price

It's a pity that the Raspberry Pi don't provide a USB client to enable a serial over USB console. For headless operation that could be very handy. The lack of proper mounting holes is also a problem.

For desktop Linux use nothing beats the Raspberry Pi in its price range but it shows that embedded operation was not a priority in its design.

For embedded Linux operation the BeagleBone is my first option. Both the BeagleBone and the Galileo feature digital and analog I/O although the BeagleBone with its GPMC bus features several orders of magnitude higher bandwidth. Both boards feature Ethernet and a serial over USB console. Both boards feature also a USB host socket. In general, however, the BeagleBone is more powerful. It uses a better Linux distribution, has higher clock frequency, consumes less power, and has more I/O lines and bandwidth. The only thing that the Galileo has and the BeagleBone lacks is the battery backed real time clock and Arduino Shield compatibility.

I plan to use the Galileo boards for Linux projects that don't need all the BeagleBone power. As this board includes in the SD card image a Python interpreter and no C compiler I will start using it in Python.

Closing Comments

That's all for now. In the end the Galileo is a quite capable Linux board but it could have been much better if the designers had opted for a higher bandwidth I/O solution. That's a pity because that positions this board in a very bad place against the BeagleBone Black. It's only strong point is the Arduino shield compatibility but I don't really care about that.

I know that it is difficult for Inter to fight against ARM but those kinds of design decisions don't help at all.
Off course I will use for teaching projects the ten Galileo boards I have been given but I'm not sure I would opt for these boards if I needed to buy them myself.

Testing the AD5697R DAC

Yesterday I tested an interesting DAC: the AD5697R. This an interesting 12 bit dual channel Digital to Analog Converter (DAC). I plan to use it on a project where it will susbstitute some operational fixed voltages. 

Using a DAC instead of a potentiometers make those voltages adjustables by the microcontroller that manages all the system. Moreover, as the DAC features an internal reference the voltage values are independent on power supply variations. 

Unfortunately, as is more and more habitual this days the DAC only comes in SMD packages and they are not board friendly at all. This 16 pin device comes in the 3mm x 3mm Lead Frame Chip Scale Package (LFCSP) package and in the 5mm x 4.4mm Thin Shrink Small Outline Package (TSSOP) package. That's tinny!

Adpating the chip to protoboard use

I selected the 16 TSSOP package as it's easier to solder although it features a 0.65 pin pitch that is about 1/4of the standard 2.50 (100 mil) DIP pitch. To test it on a protoboard I used an SMD adapter. The following figure shows the adapter I used before soldering the chip. The image also serves to show the pitch difference between TSSOP and 100 mil DIP.

TSSOP16 Adapter

As is normally the case, the adapter costs more than the DAC chip itself.

This adapter, however, has one problem: It uses dual rows of pins at either side of the chip. That's bad for a protoboard as you will short odd and even pins.

The solution was to extend the adapter after I soldered the chip:

Adapter extension

Using the extension half of the 100mil pitch pins are soldered to the original adapter and the other half to the extension.

Test circuit

So far so good. Time to test the chip.

In order to test the chip I used the F3 Gizmo to send the I2C commands the chip needs to operate.

Test circuit for the DAC

The circuit only needs four main wires: 3V supply, ground and the I2C SDA and SCL lines. A0 and A1 are connected to ground although this is not shown in the above schematic.

Test circuit on the protoboard

Test of the DAC

Once the test circuit is mounted it's time to test the DAC by sending some I2C commands.

The 7 bit I2C address for the DAC is

0 0 0 | 1 1 A1 A0

As A1=A0=0 the address will be:

000 1100 = 0xC

Using the F3 Gizmo ISCAN word whe can check that the I2C channel is operational:

     ISCAN

     0xC

To send data to the DAC we must send 3 Bytes to it's I2C address.

The first Byte indicates the command and the channel.

The 4 MSBs are the command. The command I tried is:

0011 (3h) Write to and update DAC channel n

This command directly writes a binnary data to one or both DAC channels.

The 4 LSBs of the first Byte selects the channel to adress:

    0001 (1h) DAC A
    1000 (8h) DAC B
    1001 (9h) DAC A and DAC B

The two following Bytes to send are the data to send to the DAC. As two bytes are 16 bits and the DAC channels are 12 bits only, the last 4 LSBs bits are discarded.

The DAC uses an internal 2.5V bandgap reference. The full scale (FFFh code) should be 1 LSB below the reference for the selected GAIN=1. If the GAIN pin was at VDD the selected GAIN would be 2 and the full scale value would be one LSB below 5V.

In order to set the A channel to the maximum value we can must send the following data:

  Command: 3h

  DAC addressed: 1h

  Code to send: FFFh
  Last dummy nibble: 0h

We can use the following F3 Gizmo command in order to send the data:

   0xC 0x31 0xFF 0xF0 3 0 I2CT

As a result the output goes to 2.5V as expected.

To set any other value we must compute the 12 bit value. For instance, to set the output to 1V we must use the code:

   code =4096 * 1 / 2.5 = 1638 = 666h

Using the F3 Gizmo that means sending the following command:

   0xC 0x31 0x66 0x60 3 0 I2CT

As you can see from the multimeter reading the response is quite good.

Measuring the response to code 0x666

Having the DAC an internal reference makes very easy to generate exact absolute output values.

The test was a success. Now I can test the rest of the I2C functionality before deploying the DAC in the project.