Jonathan Thomson's web journal

Level Headed – EL Wire Decorated Headphones July 5, 2013

Filed under: Electronics — jethomson @ 12:25 am

 

I decorated a pair of headphones with electroluminescent wires (EL wire) that react to the music you’re listening to. I modified an inverter taken from a graphical equalizer T-shirt to respond to an audio signal from my mp3 player instead of sound. Here’s a link to the instructable.

Advertisements
 

How to use the TSL2561 May 22, 2012

Filed under: Electronics,Spectrometer — jethomson @ 2:07 am

The TSL2561 is a light-to-digital converter from TAOS. It senses light intensity and transforms its measurement into a digital output that is transferred over I2C or SMB. If you are familiar with the TSL230R light sensors, you shouldn’t have much trouble working with TSL2561s, but there are a few important differences. The TSL230R outputs its data as a pulse train, so a microcontroller with frequency counting code is required to read the sensor’s output. The TSL2561 outputs its data directly over I2C or SMB, so the sensor’s output is simply read from the bus. The TSL230R is controlled by bringing purpose specific pins high or low. The TSL2561 is controlled by writing data to it over the bus. The TSL230R is available in a breadboardable package and runs at 5V. The TSL2561 needs an adapter board for breadboarding and it’s power supply must not exceed 3.3V. The TSL2561 also has a second diode specifically for sensing infrared.

Since the TSL2561 is so similar to the TSL230R in theory, I’ll only be writing one condensed article for the TSL2561. Please refer to the series of article of the TSL230R for a more in-depth explanation of how to acquire and process data from these sensors.

 

Serial Control
TSL2561_DAQ.ino (view online) enables serial control of the TSL2561 via a simple serial protocol between the host computer and Arduino. It allows the user to set the number of output samples, adjust the TSL2561’s sensitivity and integration time, and switch power to a light source. The Arduino IDE has a built in serial monitor, which you can use for testing serial commands. However, Tod E. Kurt’s arduino-serial is smaller and has more functionality.


The command:
./arduino-serial -b 9600 -p /dev/ttyUSB0 -d 3000 -s s016 -d 100 -s i101 -d 100 -s l111 -d 100 -s t005 -d 10000 -r -d 500 -r -d 500 -r -d 500 -r -d 500 -r -d 500 -r -d 100 -s l000

Outputs one read for each -r:
read: 697

read: 697

read: 696

read: 697

read: 696

read: EOT

This command waits three seconds for the bootloader to load the program (-d 3000) then it tells the program to set the sensitivity to 16x (s016), the integration time to 101 ms (i101), turn the light on (l111), and transmit five samples (t005). The command then waits 10 seconds for the buffer to fill (-d 10000), reads five samples (-r -d 500 repeated five times), and finally turns the light off. The blank lines in the output are from the line feed (i.e. \n) printed after each number. The uc code uses Serial.print('\n') instead of Serial.println() and the string “EOT” so that it can communicate with code written for GNU Octave and MATLAB.

 

Data Acquisition Scripts
The archive TSL2561_code.zip contains the m-files (view online: get_data, save_data, serial_open) necessary for controlling the TSL2561 within GNU Octave and MATLAB and reading the counts output from the ATmega uc.

 

Spectral Responsivity

The spectral responsivity for the Channel 0 diode when the gain is 16x, the integration time is 101 ms, Vdd = 3V, and Ta = 25°C is saved in Re2561.mat in the essential_data_sets folder within the archive TSL2561_code.zip

 

Converting Counts to Irradiance
With Re(λ) and a model of the spectral content of the light source irradiating the photodiode array we can calculate the spectral irradiance and total irradiance of the light source more accurately than in the simplistic case of assuming all the light source’s photons are 640 nm in wavelength.

For example, if we model a red LED with a peak wavelength at 640 nm and a full width at half maximum (FWHM) of 34 nm with MATLAB like so:

   % mathematically model lamp's spectrum as a gaussian curve with a peak 
   % wavelength at 640 nm and full width at half maximum of 34 nm
   e = exp(1);
   func_lamp = @(mu, FWHM) e.^(-2.7726*((lambda_Re-mu)/FWHM).^2);
   X = func_lamp(640, 2*17);  % [uW/(nm*cm^2)]

Then the output counts, cX, that would result if X irradiated the photodiode array can be calculated thusly:

 

However, cX is not the actual output counts of the TSL2561 because X is only a model of the shape of the light’s spectrum and lacks radiometric calibration. Since we can measure counts, finding the proper radiometric calibration multiplier for X is as simple as dividing counts/cX.

 

Therefore, a good approximation of the radiometrically calibrated spectral irradiance of the light source should be:

 

and the total irradiance is:

 

Acknoledgements

Newark gave me a TSL2561T light to digital converter from TAOS to evaluate as part of their product road testing program.

Thanks go out to ladyada for providing a library and basic example for working with the TSL2561.

 

Using a Wii Nunchuk as an Earthquake Sensor May 16, 2012

Filed under: Electronics,QCN — jethomson @ 9:57 pm

 

 

This article explores the suitability of a Wii nunchuk based USB accelerometer as an earthquake sensor for the Quake-Catcher Network (QCN) project. It examines the nunchuk over several metrics: precision and range, frequency response, total cost and availability.

The Quake-Catcher Network is a collaborative initiative for developing the world’s largest, low-cost strong-motion seismic network by utilizing sensors in and attached to internet-connected computers. With your help, the Quake-Catcher Network can provide better understanding of earthquakes, give early warning to schools, emergency response systems, and others. The Quake-Catcher Network also provides educational software designed to help teach about earthquakes and earthquake hazards.

Range and Precision
QCN supports a few different USB accelerometers. The most basic one is the JoyWarrior24F8 (JW24F8), which is a 3 axis accelerometer with 10 bits of precision and a measurement range of +-2g, +-4g, or +-8g. QCN uses the +-2g range. According to WiiBrew, the Wii nunchuk’s accelerometer also has 10 bits of precision over a range of +-2g. Therefore, the nunchuk meets the first criteria for evaluating its suitability as a QCN sensor.

Data Comparison
I don’t have access to a shake table so I’m unable to directly evaluate the frequency response of the nunchuk based USB accelerometer. However, QCN did provide me with a JoyWarrior24F8 USB accelerometer for comparison. Since the frequency response of the JoyWarrior24F8 was already deemed suitable by Prof. Cochran for QCN, I simply had to attach the JoyWarrior24F8 and the nunchuk to the same substrate, shake them by hand at various frequencies while recording data from both sensors simultaneously, and compare the Fourier transform of the nunchuk’s data to the transform of the JW24F8’s data.

Here are comparisons of an official (i.e. STMicroelectronics accelerometer) nunchuk to the JW24F8. The microcontroller code used was mega32u4_hard-i2c_no_filter.zip and the plots were made using the Octave scripts found in the code section below.

 

Accelerometer X-axis data comparison
Time domain plots:

 

Frequency domain plots:

 

Accelerometer Y-axis data comparison
Time domain plots:

 

Frequency domain plots:

 

Accelerometer Z-axis data comparison
Time domain plots:

 

Frequency domain plots

 

The STMicroelectronics based nunchuk appears to have a response that is very similar to the JW24F8’s response. It should be noted that I was shaking the accelerometers by hand so I don’t think I covered the entire range of frequencies of interest.

Fakes
Unfortunately, there are fake (i.e. 6331 accelerometers) nunchuks that are unsuitable earthquake sensors because their accelerometer data has stuck bits. Even worse, it can be very difficult to impossible to tell if a nunchuk is official by external examination only.

Microcontrollers
The nunchuk uses I2C to transfer its data. Therefore, a microcontroller that supports USB and I2C is required to read the data from the nunchuk, filter it, and pass it to the host computer. Three different microcontrollers were evaluated: an ATmega32U2 board that supports hard USB and soft I2C, an ATmega328P with V-USB that supports soft USB and hard I2C, and an ATmega32U4 (teensy) that supports hard USB and hard I2C. The ATmega32U2 only works with 6331 based nunchuks and only at 100 kHz. The ATmega328P works with both STMicroelectronics and 6331 based nunchuks, but the two-wire interface (TWI) eventually locks up for an unknown reason. The ATmega32U4 works with both types of nunchuks tested and with no crashes observed over a two-week period. The STMicroelectronics nunchuk works at 100 and 200 kHz with hard I2C only. The 6331 based nunchuk works at 100, 200, and 400 kHz when hard I2C is used.

Cost
A Quake Catcher Kit from Saelig is $42.25 with about $12 for shipping to a U.S. residence, for a total of $54.25.

A Teensy with a 3.3V regulator and shipping costs about $22. A genuine, official nunchuk is approximately $20 shipped. A nunchuk extension cable from eBay is around $4.50. For a total price of $46.50. However, the cost of a proper mount for the nunchuk as well as the labor cost of assembly has not been included. Therefore, I believe that Quake Catcher Kit is most likely a better deal for your time and money.

Code
_Microcontroller code_
The output resulting from microcontroller code that didn’t filter the accelerometer data was the most similar to the output of the JW24F8. Code that filters the accelerometer data with Chebyshev and moving-average filters is included for comparison purposes and because I’d already written it.

This code is for research purposes only; it uses an Atmel USB VID/PID pair for LUFA demos only. This code doesn’t work with QCN because the QCN software checks the joystick’s name to make sure it’s a JoyWarrior. This code can be easily made to work with QCN by modifying its USB descriptors, which I’ve done, but I won’t be releasing this code since it uses Code Mercenaries’s VID/PID. The code also checks the connected controller’s identification bytes to make sure its a genuine Wii nunchuk. It doesn’t work with fake nunchuks.

Wii Nunchuk quake sensor code for teensy (no filter)

Wii Nunchuk quake sensor code for teensy (moving average)

Wii Nunchuk quake sensor code for teensy (chebyshev)

_Host code_
Joystick Accelerometer Data Acquisition code for Linux

Octave plotting scripts

 

Fake Wii Nunchuks with a 6331 Accelerometer April 29, 2012

Filed under: Electronics,QCN — jethomson @ 12:45 am

While evaluating the suitability of a Wii nunchuk as an earthquake sensor (article not yet published), I discovered a few things about non-official nunchuks that use an accelerometer with the markings 6331 over QS***, where the asterisks stand in for a three letter code. This website (translated PDF) says these accelerometers are MMA6331L chips, but I’m not certain if they are genuine Freescale parts. The 6331 nunchuks don’t behave the same as the original nunchuks, which use an STMicroelectronics’ accelerometer. The 6331 nunchuks differ from the original in two important ways.

First, the 6331 based nunchuks don’t encrypt their data whether they are initialized using the old or the new method. This is important because there is a lot of microcontroller code on the web for reading data from a nunchuk that uses the old initialization method and decrypts the nunchuk data. Using this code on a 6331 based nunchuk will result in mangled data caused by incorrectly applying the decryption routine on unencrypted data. The solution is to use the new initialization method. This method causes an STMicroelectronics based nunchuk to output unencrypted data. Since the 6331 based nunchuks output unencrypted data no matter the initialization method, it’s better to use the new method without a decryption routine so your code will support both types of nunchuks.

 

    void nunchuck_init_old ()
    {
      delay(1);
      Wire.beginTransmission(0x52);
      Wire.send(0x40);
      Wire.send(0x00);
      Wire.endTransmission();
      delay(1);
    }

 

    void nunchuck_init_new ()
    {
      // http://wiibrew.org/wiki/Wiimote#The_New_Way
      delay(1);
      Wire.beginTransmission(0x52);
      Wire.send(0xF0);
      Wire.send(0x55);
      Wire.endTransmission();
      delay(1);
      Wire.beginTransmission(0x52);
      Wire.send(0xFB);
      Wire.send(0x00);
      Wire.endTransmission();
      delay(1);
    }

 

Second, the accelerometer data in 6331 based nunchuks have some bits that are permanently fixed (i.e. stuck at 0 or 1). Bit 0 of byte 2 is always zero, bit 0 of byte 3 is always one, and bit 0 of byte 4 is always zero. Bits 3, 4, and 5 of byte 5 are also stuck at zero.

    Table 1
              7   6   5   4     3   2   1   0
    byte 2  | x | x | x | x | | x | x | x | 0 |
    byte 3  | y | y | y | y | | y | y | y | 1 |
    byte 4  | z | z | z | z | | z | z | z | 0 |
    byte 5  | z | z | 0 | 0 | | 0 | x | b | b |

Each axis of accelerometer data is represented by 10 bits with the 2 least significant bits of each axis stuffed in byte 5. When bytes 2 through 4 are transformed into accelerometer axis data, Table 1 can be rearranged to get Table 2.

    Table 2
                                      9   8   7   6   5   4   3   2   1   0
    x always zero                   | x | x | x | x | x | x | x | 0 | 0 | x |
    y always one, y always zero     | y | y | y | y | y | y | y | 1 | 0 | 0 |
    z always zero                   | z | z | z | z | z | z | z | 0 | z | z |

 

I have no idea why the accelerometer data in 6331 based nunchuks have some bits stuck like this. My first guess was that it had something to do with the Wii Motion Plus’s passthrough mode. The Wii Motion Plus (WM+) has a passthrough mode that interleaves nunchuk data with motion plus data. The WM+ discards some of the nunchuk’s LSBs to make room for bookkeeping bits. So I thought that since newer Wiimote’s include WM+ maybe the 6331 nunchuks don’t bother with the bits that will be discarded anyway. However, the bits discarded by the WM+ don’t match up with the fixed bits of the 6331 based nunchuks.

 

Identifying a 6331 based nunchuk
Unfortunately these fake nunchuks aren’t as easy to avoid as one might think. A nunchuk I purchased off of Amazon, which was advertised as official and looks genuine, has the same 6331 accelerometer and board as an obviously fake nunchuk I bought on eBay. The one I bought from amazon has a rubberized joystick, triwing screws, and the Nintendo logo.

There are a few ways to tell if your nunchuk is 6331 based. The most thorough method is to open the nunchuk and look for an accelerometer on the side of the board opposite the joystick with the markings 6331 over QS***, where the asterisks stand in for a three letter code. Another method is to use a program that performs the old initialization method and decrypts the data. When the joystick is centered the x-axis for the joystick (not the accelerometer) should be around 128. If the x-axis reads around 174 then the decryption algorithm has mangled unencrypted data. The decryption algorithm is (x xor 0x17) + 0x17 or in decimal (x xor 23) + 23. Therefore, (128 xor 23) + 23 = 174.

 

The STMicroelectronics accelerometer inside an official nunchuk. The official nunchuk also has a shielded cable.

 

Inside an fake/knock-off nunchuk purchased on eBay.

 

The board of a nunchuk that looks official from the outside but is actually fake. Notice that the EEPROM spot populated. The pinout of the 6331 as seen on the fake nunchuk’s board appears to agree with the datasheet except for one strange exception. The nunchuk is a three axis device, but the datasheet says the MMA6331L only measures x and y axis data. Pin 4 of the datasheet says it has no internal connection but on the board pin 4 has a trace that is connected to a filter capacitor and the microcontroller just like pins 2 and 3, which are the x-axis and y-axis data pins! It should also be noted that the MMA6331L’s minimum range is +-4g, where the STMicroelectronic’s nunchuk measures acceleration over the range +-2g.

 

Final Thoughts
If you have any information to share, please leave a comment below. I’m particularly interested to hear why 6331 based nunchuks have some of the accelerometer data bits stuck or how to unstick them. I’d also really like to hear what sort of accelerometers are being used in the nunchuks that come packaged with the newest Wiis.

 

Instructables January 25, 2012

Filed under: Electronics — jethomson @ 12:32 am

Here are links to a couple of instructables I recently finished.

 

Ceiling Fan Pull Chain Nightlight

 

Musically Animated Gift Box

 

Getting Started with the STM32F4DISCOVERY in Linux November 17, 2011

Filed under: Electronics — jethomson @ 8:58 pm

Building an ARM toolchain
To compile code for the STM32F4DISCOVERY you’ll need an ARM toolchain that supports the Cortex-M3. I used the build script summon-arm-toolchain to build one. Before running the script you need to install several dependencies:

$ su -c "apt-get install flex bison libgmp3-dev libmpfr-dev libncurses5-dev libmpc-dev autoconf texinfo build-essential libftdi-dev"

You might also need to run:

$ su -c "apt-get build-dep gcc-4.5"

Now make a directory to hold the files you’ll need to work with the STM32F4DISCOVERY:

$ mkdir ~/stm32f4discovery_root
$ cd ~/stm32f4discovery_root

Next clone the summon-arm-toolchain, read the README, and begin the build:

$ git clone https://github.com/esden/summon-arm-toolchain.git
$ cd summon-arm-toolchain
$ ./summon-arm-toolchain

 

Setting up the software to communicate with the STLINK
While the toolchain is compiling you can set up the software required to communicate with the STLINK, which is the on-board JTAG programmer/debugger on the lefthand side of the board. From a new shell run:

$ su -c "apt-get install libusb-1.0-0-dev"
$ cd ~/stm32f4discovery_root
$ git clone git://github.com/texane/stlink.git stlink_texane
$ cd ~/stm32f4discovery_root/stlink_texane
$ make

Now you should install the udev rules 49-stm32l-discovery.rules and restart udev. These steps will create a symbolic link called /dev/stm32l_stlinkN and give a normal user permission to access it.

$ su
# cp 49-stm32l-discovery.rules /etc/udev/rules.d/
# /etc/init.d/udev restart
# exit

 

Example projects and makefiles
Next, download the STM32F4DISCOVERY firmware package and an archive of makefiles for building some of the example projects found in the firmware package.

$ cd ~/stm32f4discovery_root
$ wget http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32f4discovery_fw.zip
$ unzip stm32f4discovery_fw.zip
$ wget http://jthomson.towhee.org/stm32f4discovery_files/STM32F4DISCOVERY_Makefiles.zip
$ unzip STM32F4DISCOVERY_Makefiles.zip
$ cd ~/stm32f4discovery_root/STM32F4DISCOVERY_Makefiles
$ cp Makefile.IO_Toggle ~/stm32f4discovery_root/STM32F4-Discovery_FW_V1.1.0/Project/Peripheral_Examples/IO_Toggle/
$ cd ~/stm32f4discovery_root/STM32F4-Discovery_FW_V1.1.0/Project/Peripheral_Examples/IO_Toggle

If the toolchain installation still hasn’t finished, then familiarize yourself with the example code and makefiles or take a break.

 

Compiling and Flashing
Once summon-arm-toolchain has finished building your ARM toolchain you can try it out on the IO_Toggle example by using the following commands.

$ cd ~/stm32f4discovery_root/STM32F4-Discovery_FW_V1.1.0/Project/Peripheral_Examples/IO_Toggle
$ make -f Makefile.IO_Toggle

If the build finished without error, then you’re ready to try downloading it to the board. Plug in the board and use stlink to write the blinking LED example, IO_Toggle.bin, to the STM32F4DISCOVERY’s flash memory.

$ PATH=~/stm32f4discovery_root/stlink_texane/flash:$PATH
$ flash write IO_Toggle.bin 0x8000000

Power cycle the board by removing then reinserting the USB plug. If the download was successful, the LEDs should light up in a clockwise pattern and pressing the pushbutton will not result in the board entering test mode.

You can easily modify one of the sample makefiles to work with another example by examining the .uvproj file (found in the example’s MDK-ARM directory) to determine which defines (-D), includes (-I), source files, etc. to add to the new makefile. Just open the .uvproj file in a text editor and look for lines like these:

<Define>USE_STDPERIPH_DRIVER,STM32F4XX</Define>
<IncludePath>
..\;
..\..\..\..\Libraries\CMSIS\Include;
..\..\..\..\Libraries\CMSIS\ST\STM32F4xx\Include;
..\..\..\..\Libraries\STM32F4xx_StdPeriph_Driver\inc;
..\..\..\..\Utilities\STM32F4-Discovery
</IncludePath>

<FilePath>..\main.c</FilePath>
<FilePath>..\..\..\..\Utilities\STM32F4-Discovery\stm32f4_discovery.c</FilePath>
<FilePath>..\..\..\..\Libraries\STM32F4xx_StdPeriph_Driver\src\stm32f4xx_rcc.c</FilePath>
etc.

 

Final Notes
There is a lot I don’t understand about compiling for the STM32F4DISCOVERY and I’m certain that the Makefiles I’ve provided could be improved. For example, I don’t know which -m options (see the Makefile’s MCUFLAGS variable) to set, when to set them, and why. If you have any corrections or improvements to share, please leave a comment.

 

Links
The STM32F4 high-performance discovery board (STM32F4DISCOVERY) and a range of of STMicroelectronics products are available at Newark
Alternate method of programming the STM32F4DISCOVERY using the Bus Blaster and OpenOCD
A fork of the summon-arm-toolchain that builds gcc for the Cortex-M4F
A comment discussing this fork

 

Getting Started with the STM32VLDISCOVERY in Linux

Filed under: Electronics — jethomson @ 8:16 pm

Building an ARM toolchain
To compile code for the STM32VLDISCOVERY you’ll need an ARM toolchain that supports the Cortex-M3. I used the build script summon-arm-toolchain to build one. Before running the script you need to install several dependencies:

$ su -c "apt-get install flex bison libgmp3-dev libmpfr-dev libncurses5-dev libmpc-dev autoconf texinfo build-essential libftdi-dev"

You might also need to run:

$ su -c "apt-get build-dep gcc-4.5"

Now make a directory to hold the files you’ll need to work with the STM32VLDISCOVERY:

$ mkdir ~/stm32vldiscovery_root
$ cd ~/stm32vldiscovery_root

Next clone the summon-arm-toolchain, read the README, and begin the build:

$ git clone https://github.com/esden/summon-arm-toolchain.git
$ cd summon-arm-toolchain
$ ./summon-arm-toolchain

 

Setting up the software to communicate with the STLINK
While the toolchain is compiling you can set up the software required to communicate with the STLINK, which is the on-board JTAG programmer/debugger on the lefthand side of the board. From a new shell run:

$ cd ~/stm32vldiscovery_root
$ su -c "apt-get install libusb-1.0-0-dev"
$ wget http://arm-utilities.googlecode.com/files/arm-utilities-2011-6-28.tgz
$ tar xvzf arm-utilities-2011-6-28.tgz
$ cd ~/stm32vldiscovery_root/arm-utilities/stlink-download
$ gcc -o stlink-download stlink-download.c

Now you should install the udev rules 10-stlink.rules, add your username to the group tape, and restart udev. These steps will create a convenient symbolic link called /dev/stlink to the board’s actual /dev entry (e.g. /dev/sg2)

$ su
# cp 10-stlink.rules /etc/udev/rules.d/
# usermod -aG tape your_username_here
# /etc/init.d/udev restart
# exit

 

Example projects and makefiles
Next, download the STM32VLDISCOVERY firmware package (AN3268) and an archive of makefiles for building some of the example projects found in the firmware package.

$ cd ~/stm32vldiscovery_root
$ wget http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/FIRMWARE/stm32vldiscovery_package.zip
$ unzip stm32vldiscovery_package.zip
$ wget http://jthomson.towhee.org/stm32vldiscovery_files/STM32VLDISCOVERY_Makefiles.zip
$ unzip STM32VLDISCOVERY_Makefiles.zip
$ cd ~/stm32vldiscovery_root/STM32VLDISCOVERY_Makefiles
$ cp Makefile.GPIOToggle ~/stm32vldiscovery_root/an3268/stm32vldiscovery_package/Project/Examples/GPIOToggle/
$ cd ~/stm32vldiscovery_root/an3268/stm32vldiscovery_package/Project/Examples/GPIOToggle
$ cp ../../Demo/TrueSTUDIO/DISCOVER/STM32F100RB_FLASH.ld ./

As described in README.TXT, you’ll need to edit Utilities/STM32vldiscovery.h to change the line: #include "STM32f10x.h" to lowercase: #include "stm32f10x.h". If the toolchain installation still hasn’t finished, then familiarize yourself with the example code and makefiles or take a break.

 

Compiling and Flashing
Once summon-arm-toolchain has finished building your ARM toolchain you can try it out on the AN3268 GPIOToggle example by using the following commands.

$ cd ~/stm32vldiscovery_root/an3268/stm32vldiscovery_package/Project/Examples/GPIOToggle
$ make -f Makefile.GPIOToggle

If the build finished without error, then you’re ready to try downloading it to the STM32VLDISCOVERY. Before plugging in the STM32VLDISCOVERY run the following command:

$ su -c "modprobe -r usb-storage && modprobe usb-storage quirks=483:3744:lrwsro"

Plug in the board and wait for Linux to finish mounting it. Although the udev 10-stlink.rules are written to prevent the board from being auto-mounted it happens on my system regardless. Once the board is mounted, you should be able to see three URL files. In my experience, you must wait for the board to be mounted before attempting to flash a program; otherwise, you will crash Linux. Finally, use stlink-download to write the blinking LED example, GPIOToggle.bin, to the STM32VLDISCOVERY’s flash memory.

$ PATH=~/stm32vldiscovery_root/arm-utilities/stlink-download:$PATH
$ stlink-download /dev/stlink program=GPIOToggle.bin
$ stlink-download /dev/stlink reset
$ stlink-download /dev/stlink run

You can easily modify one of the sample makefiles to work with another example by examining the .uvproj file (found in the example’s MDK-ARM directory) to determine which defines (-D), includes (-I), source files, etc. to add to the new makefile. Just open the .uvproj file in a text editor and look for lines like these:

<Define>STM32F10X_MD_VL, USE_STDPERIPH_DRIVER</Define>
<IncludePath>
..\;
..\..\..\..\Libraries\CMSIS\CM3\CoreSupport;
..\..\..\..\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x;
..\..\..\..\Libraries\STM32F10x_StdPeriph_Driver\inc;
..\..\..\..\Utilities\
</IncludePath>

<FilePath>..\..\..\..\Libraries\STM32F10x_StdPeriph_Driver\src\misc.c</FilePath>
<FilePath>..\..\..\..\Libraries\STM32F10x_StdPeriph_Driver\src\stm32f10x_exti.c</FilePath>
<FilePath>..\..\..\..\Libraries\STM32F10x_StdPeriph_Driver\src\stm32f10x_gpio.c</FilePath>
etc.

 

I originally started working with a package that builds all the examples at once, but this requires compiling and linking code that isn’t needed by every example so it is best to create a tailored makefile for each individual project. However, it’s an easy way to create all the .bin file examples so that you can quickly try them out on your board. The STM32VLDISCOVERY_firmware_build_all package is based on Geoffrey Brown’s project “to enable building for the STM32VLDISCOVERY board in a Unix environment.” I modified his project slightly to fix some case sensitivity errors, a missing syscall _exit() function, and to prevent from redistributing code in possible violation of the code’s license.

$ cd ~/stm32vldiscovery_root
$ wget http://jthomson.towhee.org/stm32vldiscovery_files/STM32VLDISCOVERY_firmware_build_all.zip
$ unzip STM32VLDISCOVERY_firmware_build_all.zip
$ cd ~/stm32vldiscovery_root/STM32VLDISCOVERY_firmware_build_all
$ make

 

Final Notes
There is another open source software project that supports downloading and debugging via the STLINK hardware known as stlink. It allows JTAG debugging with gdb and OpenOCD. Unfortunately I wasn’t able to use stlink because it crashes my computer. I believe this may be caused by a bug in libsgutils2-dev. Here’s a link to the open source stlink project.

 

Links
The STM32 Value Line Discovery Kit (STM32VLDISCOVERY) and a range of of STMicroelectronics products are available at Newark

A great site on developing for the STM32 using open source tools
Geoffrey Brown’s makefiles to build for the STM32VLDISCOVERY board in a Unix environment
stlink-download wiki page
Another guide that shows how to build the STM32VLDISCOVERY firmware package’s examples using Eclipse and CodeSourcery
A good list of the various toolchains and utilities for the STM32
Programming STM32F10x I/O port pins
Cortex M3 For Dummies – STM32 Discovery Board
A fork of stlink that may work for the STM32VLDISCOVERY