Getting started with ARM

[nctnico]

If the OP is just trying to complete a particular task and program in C then surely the architecture is not that important.

It is ESSENTIAL to have an understanding of the underlying architecture when programming any microcontroller in my opinion. Just try to write even a moderately simple program without looking at the datasheet!

Yes and no. Studying how the CPU works isn't very interesting when programming in C. Though you do need to know how the peripherals work. BTW the manual which describes the peripherals is often called a 'user manual'. The datasheet just sums up the possibilities and electrical / mechanical characteristics.

[westfw]

but there must be an open source IDE and compiler out there which I can use and which doesn't impose arbitrary restrictions on code size... isn't there?
   :
Please bear in mind I'm a hardware guy... I'm quite good at keeping the magic smoke inside the chips, but I need software to "just work"

All of the ARMs can be programmed using some free flavor of gcc, using command-line tools or some free version of an open source development environment (Eclipse, Netbeans, etc.)  Putting all the little pieces together can be a significant software task, however.  If you're lucky, someone else has already put the pieces together for you.

The cheap eval boards people have mentioned all come with relatively "reasonable" limited compilers; probably quite adequate for "getting started."  Knowing that you CAN gnu should be enough, IMO...
(And it's not at all unreasonable to pick a vendor because you like their particular IDE/compiler setup better than others, even if it costs money...  "I started with the free version of TI's software.  When I started to get close to its limits, I tried to install eclipse/arm-gcc, but it was a PITA and didn't have the options I had liked in TI's version (which is also eclipse based), so I decided to shell out the $500 for TI's full SW." is a perfectly reasonable chain of thought...

[AndyC_772]

It might be possible to pick up an old Archimedes today for a song and use it to learn the ARM instruction set. Although the hardware has changed tremendously the core of the instruction set is essentially the same.

I actually had an Acorn A3000, and later upgraded to the much faster ARM3 based A5000, as my desktop computer while I was doing my degree. It had a version of BBC BASIC built in, which included an ARM assembler, so I used to know the instruction set very well indeed. I'm sure it's evolved since then, but coming from the 6502 it was wonderful to have so many registers to play with, and every instruction was (and presumably still is) able to be executed conditionally.

A lot has changed since then, of course. I sadly had to sell the A5000 to buy a (conventional) PC, which for all its relative disadvantages did offer much better support and price/performance than the ageing Acorn. I think that was about the time I wrote my last computer program too, right up until I picked up the PIC stuff and started learning C a couple of years ago.

It's C that I plan on using now, of course. Life is too short, and fast microcontrollers too cheap and readily available, to invest too much time and effort in learning the machine language of any one processor without a very good reason, IMHO.

That said, I'm well aware, for example, that the memory architecture of a PIC18 is a dog's dinner. I know its performance is limited too, especially with the free compiler, but given the choice of spending my time learning to program a PIC in assembler vs learning to program a much faster - and cheaper! - processor in C, I choose the latter.

Where I expect to spend the time is on learning the peripheral set of a particular MCU - how to use its timers, serial ports, clock structure, interrupts and so on, plus the associated compiler and IDE. I'm hoping not to need to spend too long on the ARM instruction set itself!

I find it always helps to have an application in mind when learning something new, and I do have a PIC18 board which I'm thinking of re-doing with something like an STM32. It has about 32k of code in it, most of which is actually graphics for the LCD which are compiled in as pre-initialised structures. (This is one reason why I'm not keen on a code size limited compiler; I may find that simply porting across the code I already have will use it all up. The other reason is I'd really prefer to build my own board, in my own form factor, with my own peripherals and which will actually work as a usable product when it's done, than use an off-the-shelf dev board).

[IanB]

I sadly had to sell the A5000 to buy a (conventional) PC

Sad that, when these days conventional PCs are so cheap and easily obtained they are practically abandonware.

I recall my first slightly foolish PC purchase back around 1993--a Compaq laptop with 25 MHz processor, 640x480 VGA screen and 4 MB of memory for about £3000. I never dreamed how much prices would come down and specifications would go up in future years...

[andyturk]

Where I expect to spend the time is on learning the peripheral set of a particular MCU - how to use its timers, serial ports, clock structure, interrupts and so on, plus the associated compiler and IDE. I'm hoping not to need to spend too long on the ARM instruction set itself!

I find it always helps to have an application in mind when learning something new, and I do have a PIC18 board which I'm thinking of re-doing with something like an STM32. It has about 32k of code in it, most of which is actually graphics for the LCD which are compiled in as pre-initialised structures. (This is one reason why I'm not keen on a code size limited compiler; I may find that simply porting across the code I already have will use it all up. The other reason is I'd really prefer to build my own board, in my own form factor, with my own peripherals and which will actually work as a usable product when it's done, than use an off-the-shelf dev board).

As a long-time unix coder, I found it fairly easy to slip into ARM development with an ST Discovery board (about $10). The board actually has two mcus on it, one that runs your code and the other to implement the debugging interface. You can also use the same disco board as a debugger for an outboard mcu by removing two jumpers... and that's how I program my own boards.

The painful part is getting your toolchain and debugging environment going. Most of the OEMs offer some sort of Eclipse based IDE that will give you a text editor and a toolchain in one download. If you're a fan of Eclipse (or IDEs in general), that may be a good way to go. It's probably the quickest way to get your "blinky" app working, which is key. From there, it's reasonably easy to write "real" software. You can learn the peripherals one-by-one and use the same debugging setup that works for the simple blink app.

The alternative is one of the gcc based toolchains. I've had pretty good luck with Yagarto. There are binary installation packages for Windows and OS X. The most complicated aspect is the debugger, usually based on OpenOCD. It's open source and under active development, so which version you get matters. OpenOCD is critical because it runs the JTAG/SWD pins on your microcontroller and is responsible for flashing new code and debugging. Getting comfortable with it is a little frustrating, because it's mostly about writing Tcl scripts and locating the right configuration files. But once it's set up, it does stay out of your way.

However, Yagarto and the other open source toolchains don't have library code for your mcu. And without a decent library, you can get lost in peripheral configuration, some of which is required before your program even runs (e.g., clock configuration). The OEMs obviously provide their own libraries, but there are open-source RTOS projects that give you essentially the same thing (along with more OS-like stuff). I use one called ChibiOS, which was written by an engineer who works at ST. The project has no official support, but they usually have the latest ST parts running quickly.

Even if you don't want to use ChibiOS, keep it in mind for reference purposes. It has a fairly extensive HAL (Hardware Abstraction Layer) with support for most peripherals and Giovanni's code is quite good.

[AndyC_772]

Time for a little update...

I decided to give CoIDE a try, and I bought the smallest STM Discovery board, the STM32F051R8.

First impressions were very positive. Installing GCC and the ST-Link driver went without a hitch, and I was soon working my way through the wizard creating my first project.

Then it all ground to a bit of a halt. After sorting a couple of wrinkles I was able to get a simple loop to compile, and I successfully erased the demo app from the target board.

Shame it wouldn't actually download or debug my code, then. The disassembly window showed the memory was full of zeroes and FF's. Looks like it might be down to a known bug in the Flash programmer