Migrating or upgrading to a new microcontroller and the issues associated with porting all or parts of an existing design to a new microcontroller have been the subject of considerable debate in the electronics industry. The problems that engineers face in this situation are exacerbated when the project schedule is tight and perhaps the only certainty is the storm of protest that will greet the engineer who fails to deliver on time. Whilst this situation is not new, there has been a steady change in the industry over recent years and many will not be aware of the new rules that govern this age-old challenge.
As an example, consider the '8051' and the many derivative devices that are available in today's market. Ten years ago the 8051 was almost written off but it seems that reports of its death were exaggerated. There are a number of new offerings using the 8051 core that give increased performance and a significant increase in both the number and variety of peripherals available. Many engineers, familiar with the 8051, are looking at these new offerings. They feel comfortable that they know the 8051 core so it should be easier to adopt any 8051 based device than look at a different core.
This is a common statement but is this correct?
The porting challenge
Before we try to answer this question, let us look at what is involved with moving to a new microcontroller. Most manufacturers of microcontrollers have many different variants; one manufacturer boasts over 500 different varieties. These variants are necessary for designers to get a sufficient choice of peripherals to meet the mix required in the particular application that is being considered.
A far better approach would be to select a microcontroller that has all the peripherals required for many projects and a flexible I/O arrangement allowing the user to choose and configure the exact combination of peripherals that each project requires. The eCOG1 from Cyan Technology makes use of this approach and can significantly reduce the amount of effort required in PCB redesign. Choosing a part like this can make the hardware changes with a new microcontroller easier. In addition, the engineer will be appreciated by the logistics people in his company if he reduces the number of different parts bought and stocked.
Most engineers would argue that software compatibility is a reason to stick with their current family of microcontrollers - so let's look at the software issues.
When considering a new microcontroller there are two main software tasks that need to be addressed:
* Writing algorithms that work entirely in the core. These could be mathematical algorithms (eg, a filtering algorithm) or they could be the main execution loop for the product.
* Software that initialises and interfaces with peripherals.
First let us address the software that works entirely in the core of the microcontroller. Over recent years, there has been an increasing use of C compilers. Compilers have become more efficient so any performance penalty that arises from using C has been reduced to a point where the reduction in engineering effort offered by a C compiler far outweighs any loss of performance in almost all applications. There are still some time-critical software functions that need to be written in assembler but even these are likely to be 'packaged' in a main program written in C. In addition to the efficiency of compilers, we have seen a marked increase in the performance of microcontrollers in general. Many engineers have taken the opportunity offered by a 10 times performance enhancement of modern microcontrollers to switch to writing software in C and ending up with a product that is still much faster than previous generations.
The other driving factor behind the adoption of C has been the steady increase in the size of code that is commonly required for many products. Writing 8 K of code in assembler probably equates to around 100 A4 pages of software. Writing and maintaining this amount of code takes considerable engineering effort. Once you start to look at applications that require 32 K or 64 K of code then using a compiler becomes the only realistic option for 99% of applications.
If we accept that the next project that we will develop will use a C compiler then we can make an obvious but startling conclusion. A high-level language such as C removes the engineer from the intricacies of the microcontroller core. If we write:
Counter = Counter + 1; (or Counter++;)
- we suddenly realise that we do not have to care exactly how this is implemented in the application. This is the very purpose of the compiler so it should be no surprise. What is perhaps a little more startling is that this means that we do not have to worry about the details of the core itself. So long as the variable Counter is incremented, we do not need to know if the result was obtained using an accumulator or register architecture - we do not care.
Now let us look at the issue of programming the peripherals. In many new microcontrollers on the market, the number of peripherals is increasing rapidly. More and more of the die size is down to the peripherals, and their complexity and power seems to be ever increasing. Taking a look at some of the 8051 microcontrollers on the market today, we have data sheets that run into 300 or 400 pages. Of these you may find that only 25 of these pages document how the core works. The remaining pages are all about the peripherals, from the humble reset controller; through sophisticated ADCs to much more complicated communications controllers (eg, CAN, USB, Ethernet).
This leads us to the conclusion that software that uses the peripherals takes much more effort to develop than software that runs entirely in the core.
It follows that the more pages of a microcontroller data sheet that are dedicated to the peripherals the less you will find it useful being familiar with the core!
Drowning in peripherals
As an engineer faced with a plethora of sophisticated peripherals what could you do to avoid being overwhelmed with the task of making them all do what you want? Fortunately, help is at hand. Certain manufacturers of microcontrollers offer tools that generate the source code for you. The screenshot pictured above shows an example of such a tool - CyanIDE from Cyan Technology, showing 'point-and-click approach to setting the baud rate for a UART.
In fact, choosing a microcontroller from the same family and manufacturer but with significant new peripherals may not be as easy as choosing a microcontroller from a new manufacturer if the new manufacturer has good, integrated tools that help with the programming of the peripherals. The powerful combination of tools and configurability is more important than a lot of experience with the core.
The age-old challenge of using a new microcontroller is taking a new twist!
| Tel: | +27 11 728 4757 |
| Fax: | 086 633 4903 |
| Email: | [email protected] |
| www: | www.mbsiliconsystems.co.za |
| Articles: | More information and articles about MB Silicon Systems |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version