Like many of you, I suppose, most of my experience has been with eight-bit processors. In my case, it has been mostly the 8051 family. Recently, I needed to move to an ARM.
The 8051 is arguably the most popular MCU architecture ever. (Your scale may vary, but in terms of the number of vendors offering 8051 variants, I believe this to be the case.) It has also been a very varied family. Every vendor has its variations on the basic theme.
I have personally experienced at least five vendors' flavors. All support the basic core 8051, but some have expanded quite a bit on that theme. Silabs, for instance, has cores running at 100MHz with one clock/instruction (for one-byte instructions). Others, like Dallas Semi, have implemented a second index register. Yet others have added 8051 cores to A/D converters, instead of the converse. (Analog Devices advertises some such products as A/D with embedded processor.) Many 8051 flavors offer the capability to address more than 64k of program memory through paging. I dislike that concept, but it has proven useful in the times when few alternatives existed.
In spite of this pervasiveness, I must admit that some applications are outside the 8051's comfort zone, including Ethernet and its big brother, TCP/IP. Not only does an Ethernet/TCP/IP stack occupy a fair amount of memory, straining the 64k native memory space of an eight-bit processor, but many of the calculations these protocols require operate on 32-bit numbers that strain an eight-bit processor.
As a result, for a new project last year where I anticipated that Ethernet and TCP/IP would be required, I jumped into the 32-bit fray. I bought a small single-board computer by Micromint, the Eagle 50e, based on the TI LM3S6918 Cortex-M3 microcontroller.
This chip is not much different from the many other Cortex-M3 products out there, except maybe for the Ethernet interface that is not so common in the Cortex-M3 family. The board comes with a fair amount of sample software, a trial version of the IAR development suite (limited to 32k executable), and several open-source IDEs based on the gcc compiler, including the Code::Blocks IDE.
Of course, there is much to learn when starting an ARM project for the first time. One of the nice things about the move to ARM is the freedom from the baggage that had me tied to an eight-bit architecture with limited address space up to now. Many of you probably are familiar with the 8051 basic architecture and special function registers (SFRs). On the 8051, there is a finite, limited amount of address space for SFRs. Timer0 and Timer1 share a common eight-bit configuration register. On the more recent chips, which have been expanded to offer more peripherals, some special function registers are paged. Vendors use other tricks, as well, that make programming and debugging less intuitive, more difficult, and bug prone. SFR paging on the Silabs 8051, for instance, has caused many a joyful night chasing bugs for yours truly.
Not so on the ARM chip. Each peripheral has 32-bit registers galore. This bounty makes it much easier to set up each peripheral independently. On the other hand, the architecture and instruction set does not support the bit variables that are so convenient with the 8051.
Here are some of my experiences and thoughts on developing using the ARM. This is based on the TI Stellaris implementation, and there is a good chance other vendors have different ways to perform these tasks. Whatever path you follow, if you want to adapt 8051 code to a Cortex-M3, it will be easier if your original C code follows good programming practices.
- Library: Using the TI library certainly facilitates configuring the peripherals and performing routine functions related to them. The many examples cover all levels of difficulty (from simple to complex) and illustrate how all the peripherals work. The fact that I was able to convert a complex project from the 8051 to the Cortex-M3 in 11 days of part-time work without prior experience with the architecture or the tools (I did check my logs), and mostly without looking at the datasheet, speaks for itself.
Still, there are some differences. When using the TI library to read the state of an input, the library returns a 32-bit variable with one bit set if the pin is high and all bits cleared if the pin is low. The bit that is set depends on the position of the pin on the eight-bit I/O port. If your code checks the state of a pin against a TRUE/FALSE condition, it will work, but if you check against a value of x01, it probably won't, unless you happen to be checking the particular pin that returns the value of x01 when set. The same applies, of course, when writing to a pin. To those of us with 8051 experience, it seems wasteful to use a 32-bit variable simply to return TRUE or FALSE, but on a 32-bit processor, there is no penalty for doing so.
- Pin use: A downside to this particular MCU is that it is much less efficient in pin use than my current favorite family of 8051s by Silabs. The LM3S6918 in a 100-pin package uses 37 pins for supply and ground while running at 50MHz with a 10-bit ADC. The C8051F120, also in a 100-pin package, needs only 10 pins for supply and ground while running at 100MHz clock speed with a 12-bit ADC.
- Tools: I tried out both the IAR Embedded Workbench evaluation version and the Code::Blocks suite based on gcc. The IAR tools are first class. I particularly like the debugger, even though my practice when I come across a bug is to analyze the code first and fire the debugger only if I can't figure out the problem on my own. Over the years, I have been able to squash more bugs that way. However, I will be the first to admit that a powerful debugger is a necessity. Debugging is where my experience with the Code::Blocks suite fell short. For unknown reasons (to this day), the same code that worked with the IAR tool did not run well under Code::Blocks. Further, I could not set up the debugger (based on gdb) on my Windows 7 computer.
That's it so far. I anticipate resuming work on this project, though. I am fully certain that a project will come up soon that requires TCP/IP. I do not want to have to do that with an 8051, nor can I afford the full license for the IAR tools for now.
What is your experience with the Cortex-M3? Comments are invited.