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.
Didier_Juges 2/19/2013 12:49:46 PM User Rank Blogger
Re: Future proof device
@dolphin, that is an interesting question. Some vendors have obsolescence management tools and policies that are clearly spelled, but the vast majority don't.
If you buy 100,000 chips/year, you can be certain to have a phone number to call when you have such questions, but when you deal in the 100's or less, you are usually left to talk to the distributors. Yet, if you are persistent, you can sometime get useful information from the manufacturers. However, few vendors will formally go further than telling you they have no plan to discontinue a particular chip, which means you are probably good for another 6 months ast least.
Sometimes a vendor may put a lot of efforts and money behind a chip and you could assume that they would not do this without firm intentions to make that chip for a while. hen the company is acquired and the new owner has a different opinion. Or the company is fabless and therefore dependant on whatever partner foundry they have at the moment. As the company changes fab, parts may become unavailable because the new fab does not support the old process.
There are so many reasons why chips go obsolete I cannot keep up.
The way I look at it, obsolescence is a fact of life, and rather than try to find a chip that's going to be around, I am content with an architecture that will. At the moment, the ARM has a lot of wind and therefore the architecture is likely to be around and multi-sourced for a long while, which offers some protection against the need for a complete redesign. However, if a particular chip goes away, you may have to redesign your PWB and modify your code around a different set of peripherals.
dolphin 2/19/2013 12:27:17 PM User Rank Bit twiddler
Future proof device
I wonder what would be the suggested MCU to migrate 16 bit microcontroller into future proof CPU : 1. CPU which has obsolescence management (long lifetime or has substitution possibility on roadmap) 2. CPU which can easily integrate different peripheral as future, de facto necessity in a medical device
Didier_Juges 12/3/2012 6:48:44 PM User Rank Blogger
Re: Thank you for the article
Chris, thank you for the good words, and thank you for the link to your app note, very interesting. I actually found quite a few gems that had escaped me until now about the Cortex family (like the Wake-Up Interrupt Controller). I will make sure to use it for reference.
Didier_Juges 12/3/2012 6:45:35 PM User Rank Blogger
Re: Bit Variables
@fordp, I agree that the lack of bit variable is more of an emotional thing for those of us who got accustomed to it. It made sense when bytes of RAM were expensive and few. Now that the smallest 32 bit processor has many kB of RAM, and as you told us, there are other ways to use that RAM efficiently, it is not a real problem.
The lack of Bit Variable is just a compiler thing. The Cortex M3 has a system called bit banding. This is better than bit variables in most cases.
You can set up an array of bit types!
You can then use #defines to alias the array elements and you have something just like bit variable expect a bit more set up!
I like the ARM chips but the big change that is not always for the better is the complexity of the periperals. This is great if you need any of the features they have added but makes it more complex if you do not.
Didier_Juges 12/1/2012 11:46:52 PM User Rank Blogger
Re: CMSIS
Duane, I have used the TI Stellaris Peripheral Driver library, TI also supports the CMSIS library, but I believe the Stellaris is more complete and may not work with other vendor's chips. TI does not claim that the Stellaris library itself is CMSIS compatible, so probably I should not make that assumption.
I believe the CMSIS library is intended to support the internal peripherals, like UART and ADC. I would not expect to find support for external devices like LCD.
However, you may be able to find (or adapt) an existing LCD driver for the Cortex-M3. For inspiration, you can check my LCD (and I2C) driver for the 8051 on my web site
duanebenson 11/30/2012 11:01:34 AM User Rank Blogger
CMSIS
Didier - Have you tried to use the CMSIS libraries yet? I've been moving from 8-bit PIC processors to ARM. I do lament the lack of bit variables as well.
The demo board that I'm using the most (IAR Systems KickStart 1347) has a few things that don't appear to be supported in the CMSIS libraries, like the on-board LCD display, so I have to use both CMSIS and the IAR proprietary libraries, unless I want to write my own handler.
CMSIS is an attempt to create a single library for pretty much all Cortex M processors, but I've found that there are multiple version of the CMSIS libraries and support isn't complete yet.
I've also been using an NXP LPCXpresso with a Cortex M0. Unfortunately, it comes with a different IDE so I'm learning two IDEs.
Didier_Juges 11/29/2012 11:22:43 PM User Rank Blogger
Re: 11 days ;)
About 80% of the effort was to write new drivers for the peripherals. In my case, that meant the UART, the ADC, the timers and the GPIO ports. I was able to do that while keeping the same API which gave upper level code access to these peripherals without change to the main code. The remaining 20% was split between converting the return values from bit type to integer and eliminating the memory space specifications (data, xdata and such). Once this was done, the main code ran essentially unchanged.
After this project was finished, I converted another, simpler project and that took just a few hours since the new drivers were already written.
With his applications straining the bounds of 8-bit processors, Didier is considering an RTOS but is unsure if it's worth the MCU resources it consumes.
To save this item to your list of favorite Microcontroller Central content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
