Thursday, October 7, 2010

Hobby work on ARM cortex M3

I've been a staunch follower of AVR 8-bit AtMega series of Microcontrollers for hobby works at home. Working with the AtMega line has been pure fun. But the time has finally come where the power of an AtMega can no longer slake my thirst. The next logical step would be to move to a 32-bit controller. The biggest pain in making the move is the absence of a fantastic community like AVRFreaks.

The ARM Cortex Series is first that comes to my mind. Googling about it quickly revealed that there are no DIP parts available from any manufacturer which means the convenience of having a chip on a bread board is not an option. This definitely came as a heavy blow to me for I have always bread boarded AtMega projects before getting a PCB done for the same. Never have I used a "pre-made" development board. Although starting with a PCB layout and fabrication before I even start working on it is an option, I dont think I'll be taking that route. SMD soldering requires quite a bit of skill which I lack. Wading through more websites showed that most development boards were costly averaging about 70$. Keeping things cheap is of paramount importance as I'm a student. LPCXpresso, mbed were options that came up. The idea of an online compiler is far from enticing and so I chose to keep away from that despite the attraction to the DIP40 form factor. LPCXpresso has great VFM but is unfortunately unavailable where I live. Searching around, I found this.

Seems fairly simple which is exactly what I wanted. In addition to that, its very cheap compared to some of the other boards.

As for the software, development is more complex than that for the ATmega although this is to be expected. From the forum posts I've read, ARM has taken quite a bit of pain in developing their Cortex series to ensure that noobs are at ease. Apparently the older ARM7 architecture proved very difficult for greenhorns and the startup code itself was complex. Even with the simplifications made, open source tools like ARM GCC do not make it easy for the beginner. In AVR Studio, there was never any need to write the makefile , linker file or finding the .h file for the controller i'm thinking of. All that was needed was an #include and everything was taken care of. It became quickly obvious that such ease of use is not available with open source tools for ARM. Possibly Keil uVision offers such a convenience but restricts code size to 32k. And buying the full version is out of the option for me. Digging up on ARM gcc revealed that several "flavours" are available with Yagarto and CodeSourcery g++ Lite being the most often used. Further digging revealed that Yagarto support for Cortex M3 is fairly new which probably means that the compiler is yet to be optimized. On the other hand CodeSourcery g++ has been offering Cortex M3 support for years and so I decided to use it.

One major issue with 32-bit CPU's is the lack of hobby groups and tutorials.When I started with the AVR AtMega, I bought a bare Atmega48 DIP chip, put it on a bread board, soldered a parallel port programmer and had the "Hello World" blinking LED program running, all within hald an hour without knowing the nuances of the Linker File or a Makefile. Indeed I had no idea that a Makefile was created implicitly. This seems almost impossible with ARM if one is using ARM gcc. I'd like to bridge this gap by writing tutorials and my sharing experiences with the ARM cortex-m3 in the hope that hobbyists will not shy away from 32 bitters because of the difficulty of getting started.The aim is to strip the abstruse parts of programming an ARM with gcc and make it similar to programming an AVR while retaining the power that a 32 bit chip provides.

I'll be ordering the LPC1768-H board very soon. Once I get hold of it and have it running (hopefully I won't have pulled out all my hair by then), I'll put up a tutorial on how to use it.


  1. Hi,
    CodeSourcery g++ Lite seems to be great if I only want to blink LEDs on my Blueboard, but gives all sorts of problems due to unreachable code if I try to use printf() or sprintf().

    Have you written a 'Hello World' program that really says 'Hello' to a serial port?


  2. John Harris has no provision for comments on web page, but e-mail is good

  3. I haven't used the serial port for debugging.

    In fact, i'm currently using a minimal startup file which does not link with newlib. functions like malloc() will also not work.

    For now, try this.

    xprintf() and related functions are provided.

  4. @John Harris,

    Its been a while. But I've re-written the makefile to link against libc and implemented minimal syscalls.

    Take a look here.

    terminal IO is implemented with uart0 @ 9600 baud.