Strong Arm Tactics
The end of the year is always a good time to catch up on major projects. This year I put together a 3D printer (very cool; I’ll have more to say about it next year) and finally got around to working out how to program a particular ARM board from Linux.
- Red Hat cloud a road map to government cloud computing based on openness, portability, and choice
- 7 Ways to Fast Track Private Cloud Infographic
- 5 Reasons to Choose an Open Platform for Cloud
- Architecting Private and Hybrid Cloud Solutions: Best Practices Revealed
The ARM board in question is from a Thai company called ETT and available through Futurlec. For about $25 you get an ST32F103 processor that has 64K of RAM and 512K of flash. The Cortex M3 CPU runs at 90MIPS and has the usual array of analog and digital I/O. Not bad for the price.
The board has a serial port and a bootloader, and even comes with a cable to connect to a PC. My problem is the software on the CD was all Windows-based. I lost the CD and it doesn't appear to be online anywhere. My eventual goal was to not use the bootloader anyway. I wanted to use an Olimex JTAG adapter — another inexpensive piece. Add a breadboard and a 3.3V power supply, and you have a pretty capable ARM set up for well under $100.
Recently, I complained that NXP didn't support Linux whole-heartedly. That's true, but ST's support for straight-up GNU tools is pretty much non-existent. There's great support for development tools from different vendors, but if you are looking for support for just pure GNU tools, there isn't much. Luckily, the RIDE tools are close to "stock" GCC, so the files provided for that toolchain will work, for the most part.
For the ARM compiler, you need arm-none-eabi-gcc and its friends. There are a lot of options for getting these. Codesourcery keeps current builds available. They'd also like to sell you their other tools, but the basic open source tools are free (I assume since Mentor bought them, this will continue to be the case). About the only limitation I've found with these tools is that they don't build gdb with the insight option (the GUI debugger). I'll mention a few workarounds for that in a future blog.
There are three other parts to the puzzle: The ST libraries, something to push code down to the bootloader, and something to drive the JTAG adapter. The libraries are easy enough to find on the ST site. The current version is in the file stm32f10x_stdperiph_lib.zip ( go to the ST site and click on Resources to browse for the latest version). The example projects for RIDE are close to what you need to get started.
For the bootload downloader, there are a few options but all of them load .bin files, not .hex files. Of course, it is no trouble to make the tools write out binary files. The tool I picked was stm32ld. The bootloader autodetects the baud rate, and 19200 baud seemed to work fine.
You might question why you need the ST libraries. In theory, you don't if you don't mind programming everything at the register level. You'll also need to create a startup file and a link script. Here's the first part of my demo program using the ST libraries:
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB,ENABLE); GPIO_InitStructure.GPIO_Pin=GPIO_Pin_7; GPIO_InitStructure.GPIO_Speed=GPIO_Speed_10MHz; GPIO_InitStructure.GPIO_Mode=GPIO_Mode_Out_PP; GPIO_Init(GPIOB, &GPIO_InitStructure);
The clock enabling, for example, is quite a bit of register-level code. It is much easier to use the library code and there is even good documentation for it on the ST site.
I am mainly using the JTAG adapter to program the device, but if you are using the bootloader, you need to push the blue pushbutton on the board, which causes the boot LED to light. Then press reset. You can now run stm32ld to send a .bin file to the flash memory. To run your program, press the blue button again (the boot LED turns off) and then reset the board.
This is still a work in progress, but it is working. I'll show you more of the code and all the glue required to put it together next time. I'll also talk about JTAG, getting around the non-GUI debugger, and some of the CPU's capabilities in upcoming blogs.