It seems there are a lot of people who have the same complaint about the STM32 Discovery boards; it can be difficult to add external hardware to them. Don’t get us wrong, we appreciate all of the pins being broken out (as opposed to the Stellaris Launchpad which we think has too few available). Here’s [Scot Kornak’s] solution to the problem. He created three different baseboards which the STM32 Discovery plugs into. Each is for a different model of dev board: the VL, F3, and F4. But he also thinks the baseboard we saw in this other project is a good choice for an F4 solution.
These large PCB add-ons bring functionality in two different ways. The first is by using expandable ports for drop in modules like serial communications connectors or Analog/SPI/I2C modules. For us, the second method is the most desirable. He routes each GPIO port to a 2×8 header and uses IDC cables (rainbow cable in these images) to connect them to a breadboard. Seeing this makes us wish STM had used discreet clusters of 16 pins instead of those super long dual pin headers.
[The Backwoods Engineer] tested out a new accessory kit for the STM32-F4 Discovery board. The image above shows two boards communicating with the UDP protocol. Notice the extra PCB into which each Discovery board has been plugged. This is a third-party add-on which adds Ethernet, RS-232, SD card slot, and a connector for LCD or Camera. We’ve had one of these F4 Discovery boards on hand for a while and haven’t figured out a good way to connect external hardware to the huge dual pin-headers. This doesn’t solve the problem — the base board also includes dual headers to break-out all the pins — but having Ethernet, serial, and SD certainly reduces the need to add all that much more. The other drawback to the hardware is that the sample firmware is targeted at the IAR Embedded Workbench which is neither free, nor in the realm of affordable for hobbyists.
The NIC used on the baseboard has auto-crossover capabilities so the boards were connected using a regular Cat6 patch cable. This example has the boards constantly sending UDP packets with the module on the right reporting status information to a terminal via the serial connection.
The STM32 F3 and F4 Discovery boards have been around for a while now. We’ve looked at both separately and they’re impressive dev boards for the price. Now can get a closer look at each from this in-depth comparison of the two Cortex-M4 development tools.
To start off, both of the boards have the same size and footprint (there are two dual-row pin headers which break out the connections to the ARM chip). Fundamentally the F3 and F4 chips have a different level of features, but the boards themselves are aimed at different applications as well. The F3 series of microcontrollers looks to be more affordable than the F4, containing less program memory, no Ethernet capability, and only one USB port. But both have hardware floating-point abilities and they’re blazing fast. The boards offer a MEMS accelerometer for prototyping. But the Discovery-F3 also contains a gyroscope while the Discovery-F4 provides audio hardware like a microphone, and DAC.
If you want to use a Linux box to develop with these tools you might find this guide helpful.
Here’s a technique that will let you use the .NET framework on an STM32 Discovery board. [Singular Engineer] was happy to learn that the .NET Micro Framework had been ported for STM32 chips. It’s doesn’t look like the port has hit a stable version yet, but these instructions will be enough to get you up and running. This lets you use managed code in the C# language to program an embedded device: the STM32 F4 Discovery board.
After flashing a new bootloader to the board a driver needs to be added for Windows to communicate with it. Above you can see that the board will enumerate as ‘STM32 .Net Test’. Once the driver is installed the rest of the firmware can be loaded on the board using a GUI supplied with the NETMF for STM32 package. That takes care of prepping the hardware, the rest is a painless process of configuring Visual Studio to use the board as a target. The ‘Hello World’ application then uses C# to blink an LED.
[Gpuhackr] chose his username to explain exactly how he spends his time. For instance, here he’s using an STM32 Discovery board to drive an AMD Radeon HD 2400 graphics card. The ARM microcontroller isn’t actually using the PCIe interface on the card. Instead, [Gpuhackr] has patched into the debugging interface built into the card itself. This isn’t quite as straight forward as it sounds, but if you do the wiring carefully it’s a pretty intersting way to connect an ARM to an LCD monitor.
This project would be almost impossible if it weren’t for the open source code which AMD has released. This lets him implement the card’s 3D rendering features. The demo directly programs the UVD Xtensa CPU which is on the video card. It draws a cube with color gradients on each side. The cube spins while the debug information is overlaid on the screen. In this case the ARM chip/board is really being used as a programmer to upload some custom firmware. But we think a real code-ninja could implement a communications protocol to open up a simple way to drive the card in real-time.
[Pulko Mandy] got his hands on the new STM32 F3 Discovery board. He’s a fan of the open source tools just like we are, so he posted a guide covering the use of an open source toolchain with the F3 hardware.
This board was just announced earlier this month but there is already support for it in OpenOCD. It’s not all that different from the F4 board, which we would think made the process a bit easier. [Pulko] is using the Sourcery CodeBench Lite toolchain, which works for pretty much all of the ARM chips out there. It is GCC based and comes with GDB for debugging (along with all the other tools you would expect). He did created his own Linker script and startup code. These are crucial for ARM so it’s nice that he provided them for us. He finishes up the guide by showing how OpenOCD can be used to flash the code to the chip and how it works with the debugger.
Yep, that blue light is blinking and I made it happen. I’ve been hard at work since I got my free STM32F0-Discovery board in the mail. Most recently I put together a starting template for building STM32F05x project on Linux. You’ll still need to install your own tool chain (I’m using the Code Sourcery G++: Lite Edition), but this makes it a snap to compile your projects with support for STM’s peripheral libraries.
As for programming, you may remember that I added support for writing to RAM in the stlink project. I’ve
wasted spent a ton of time trying to get support for writing to Flash into that project. It’s just less of a hassle to use stlink than it is to work with OpenOCD. But I’ve really hit a wall getting the flash loader code to work. If you want to check out what I’ve done so far in that area I committed a very messy branch (see the commits for what code changes I’ve made).
In the mean time you can use OpenOCD to write images compiled with the template to your device. I included the ‘make program’ option in the Makefile to do this from command line. If you need help compiling OpenOCD check the readme in the template repository.