Single-Source PIC, AVR & Alternatives

[John Devereux]

Some of Maxims MAXQ's are similar.

There are two main current hogs: FLASH memory, and Analog cells.
Some devices leave the FLASH charge pumps/sense amps enabled,
which gives faster speeds, but has a static Icc cost.

Most wake up Flash as they need it, but that has a time-cost,
so your MIPS are lower than they could be.

Analog cells can be powered on/off, sometimes that can be simply overlooked.

Or, they might find that the impedance of the Vcc switch
adds too much impedance/noise to meet the important Analog
targets, so they do a metal layer change and short it out.

The ADUC flash is unusual in that a page can be erased (or
reprogrammed) during code execution from another page. This is
extremely useful (and not mentioned in the datasheet). It makes the
interbal flash ideal for keeping user settings or data logging,
replacing e.g. an external EEPROM. Other micros I have used require
you to execute the programming code from RAM & turn off interrupts.

 

[Nico Coesel]

" ... and that the days of the ARM7 are numbered". That's exactly why
some things such as the 8051 are so successful in the marketplace. Large
parts of the industry (including pretty much all of my clients) cannot
consider any components that are likely to fall from grace within a few
years.

I think that is a problem induced by choosing micro's which are either
too dedicated or based on an archaic architecture like PIC or the
8051. If you start with a micro which can be programmed using C code
(use of assembly language strictly prohibited) which compiles on a PC
* (except for the hardware layer) then porting to a different micro
becomes a piece of cake. Write a new hardware layer, hit 'compile' and
you have the new micro running with a minimal amount of changes. Take
the PCB through a re-design and you're done. Customer happy.

* This is one of the reasons I recommend using GCC (Gnu C Compiler)
for embedded projects. GCC forces you to write clean code with a
minimal dependancy on the target. Most commercial embedded compilers
have some language extensions / pragmas which make the C code stick to
the target. The latter turns porting code from one target to another
into a time consuming (expensive) process.

 

[Joerg]

I think that is a problem induced by choosing micro's which are either
too dedicated or based on an archaic architecture like PIC or the
8051. ...

Selecting the "archaic" 8051 can IMHO be a rather wise decision.

... If you start with a micro which can be programmed using C code
(use of assembly language strictly prohibited) which compiles on a PC
* (except for the hardware layer) then porting to a different micro
becomes a piece of cake. Write a new hardware layer, hit 'compile' and
you have the new micro running with a minimal amount of changes. Take
the PCB through a re-design and you're done. Customer happy.

It's not so much just the re-programming that bothers clients. It's the
fact that any obsolescence of a single-sourced part mandates a relayout,
writing another ECO, possibly causing some service nightmares, and in my
business often a new regulatory approval process. The latter can throw
you a real curve.

* This is one of the reasons I recommend using GCC (Gnu C Compiler)
for embedded projects. GCC forces you to write clean code with a
minimal dependancy on the target. Most commercial embedded compilers
have some language extensions / pragmas which make the C code stick to
the target. The latter turns porting code from one target to another
into a time consuming (expensive) process.

Most embedded tool sets allow a choice between strict ANSI adherence and
full-feature. Staying away from HW-specifics can be quite tricky though.
Just the bootloader ini-sequences alone can already put you in a bind
where you have no choice. If you don't do the right clock/reset tap
dance it ain't going to load and that dance is (usually) different
between mfgs.

 

[Robert Scott]

...If you start with a micro which can be programmed using C code
(use of assembly language strictly prohibited) which compiles on a PC
* (except for the hardware layer) then porting to a different micro
becomes a piece of cake. Write a new hardware layer, hit 'compile' and
you have the new micro running with a minimal amount of changes. Take
the PCB through a re-design and you're done. Customer happy.

Sure, portability would be nice if it were free. But when you use portability
as a reason for restricting your choices of target, then you are paying a price
for that portability. So it comes down to a cost-effectiveness decision. That
leads me to wonder how often it happens that an embedded application needs to be
ported to a different target, keeping the source code essentially intact. Don't
count projects that need to be re-written from scratch for other reasons like
drastically enhanced functionality. This often happens coincident with the
porting need.

What you say? 30% of new projects will need this at some point? 5%? 1%? If
you are paying a price for 100% of your new projects and only benefitting 5% of
the time, that also has to be taken into account in the cost-effectiveness
decision.



Robert Scott
Ypsilanti, Michigan

 

[Tim Wescott]

Selecting the "archaic" 8051 can IMHO be a rather wise decision.



It's not so much just the re-programming that bothers clients. It's the
fact that any obsolescence of a single-sourced part mandates a relayout,
writing another ECO, possibly causing some service nightmares, and in my
business often a new regulatory approval process. The latter can throw
you a real curve.



Most embedded tool sets allow a choice between strict ANSI adherence and
full-feature. Staying away from HW-specifics can be quite tricky though.
Just the bootloader ini-sequences alone can already put you in a bind
where you have no choice. If you don't do the right clock/reset tap
dance it ain't going to load and that dance is (usually) different
between mfgs.

If you are careful you can isolate the hardware-specific stuff. It's
trendy to call the result a HAL, but you're just sticking it all into
'hardware-specific.h' and 'hardware-specific.c', possibly with a
'hardware-specific.asm' thrown in for good measure. If you change
chips, you should only have to change the hardware-specific stuff.

You're still left with recertification, of course...

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Joerg]

Tim Wescott wrote:


[...]

If you are careful you can isolate the hardware-specific stuff. It's
trendy to call the result a HAL, but you're just sticking it all into
'hardware-specific.h' and 'hardware-specific.c', possibly with a
'hardware-specific.asm' thrown in for good measure. If you change
chips, you should only have to change the hardware-specific stuff.

A HAL would really impress the suits. They like stuff being modular.

You're still left with recertification, of course...

That's a problem. If you can take a plain old 8051 and spec in several
manufacturers right from the beginning this can be avoided. The best
avenue might be to look at some products that must remain in production
for a long, long time. The first thing I did when I serviced our little
pellet stove was take out the controller board and have a good look at
it. Just out of curiosity. Sure enough a Winbond 8051 was at the helm
there. One of my first designs with a 8051 from the early 90's is still
in production, with the same uC on there.

That's also why I generally try to avoid FPGA and CPLD if I can. Some of
these don't seem to last longer in production than fashion clothes ;-)

In medical all this is even more critical WRT certification. After some
spectacular and rather sad accidents the FDA now places a great deal of
scrutiny on the software/firmware aspects. Basically you have to repeat
months of validation after you change one line of code. A HAL won't help
and the seemingly minor job of switching from a discontinued uC to
another can cost you more than $100K in manhours just for the validation
phase.

 

[Joerg]

Sure, portability would be nice if it were free. But when you use portability
as a reason for restricting your choices of target, then you are paying a price
for that portability. So it comes down to a cost-effectiveness decision. That
leads me to wonder how often it happens that an embedded application needs to be
ported to a different target, keeping the source code essentially intact. Don't
count projects that need to be re-written from scratch for other reasons like
drastically enhanced functionality. This often happens coincident with the
porting need.

What you say? 30% of new projects will need this at some point? 5%? 1%? If
you are paying a price for 100% of your new projects and only benefitting 5% of
the time, that also has to be taken into account in the cost-effectiveness
decision.

Unless you work in medical electronics where that innocent 5% can
balloon into a monster.

 

[steve]

Sure, portability would be nice if it were free. But when you use portability
as a reason for restricting your choices of target, then you are paying a price
for that portability. So it comes down to a cost-effectiveness decision. That
leads me to wonder how often it happens that an embedded application needs to be
ported to a different target, keeping the source code essentially intact. Don't
count projects that need to be re-written from scratch for other reasons like
drastically enhanced functionality. This often happens coincident with the
porting need.

What you say? 30% of new projects will need this at some point? 5%? 1%? If
you are paying a price for 100% of your new projects and only benefitting 5% of
the time, that also has to be taken into account in the cost-effectiveness
decision.



Robert Scott
Ypsilanti, Michigan

It's rare for us, for high end medical and aerospace products we make
the quantities aren't great and the certification costs are
astronomical, so we keep track of part obsolescence and do lifetime
buys (sometimes very painful) as needed so ports aren't necessary.

For most other products the customer always wants more features at a
less price in a smaller lower power package, so complete redesigns are
a given, maybe every 4-5 years, and we have been pretty successful at
choosing parts that don't go obsolete in this time frame.

Its more important for us to optimize our redesign capabilities then
reuse capabilities.

 

[Nico Coesel]

Sure, portability would be nice if it were free. But when you use portability
as a reason for restricting your choices of target, then you are paying a price
for that portability. So it comes down to a cost-effectiveness decision. That

Why? Devices with similar functionality usually have a similar price.
These days a controller based on the ARM7TDMI costs the same as an
8051 based micro.

leads me to wonder how often it happens that an embedded application needs to be
ported to a different target, keeping the source code essentially intact. Don't
count projects that need to be re-written from scratch for other reasons like
drastically enhanced functionality. This often happens coincident with the
porting need.

What you say? 30% of new projects will need this at some point? 5%? 1%? If
you are paying a price for 100% of your new projects and only benefitting 5% of
the time, that also has to be taken into account in the cost-effectiveness
decision.

Being able to share one library across different platforms can save a
lot of time. Also, designing the hardware usually costs much less than
the design of the software. The big investment is in the software,
portability makes sure the investment in software keeps its value.

Several years ago I was in a meeting with a company which makes
telephony processing cards. They used hand crafted assembly language
for programming the DSPs on their card (and very proud of it). It
turned out they had a huge problem: the DSP they choose was going to
be obsolete and the DSP to follow wasn't much faster (they put their
bet on the wrong manufacturor).

If they had choosen to use a platform on which they could have used a
portable high level language (and perhaps stick 4 DSPs on a board
instead of 3), they could have turned their hardware product into a
PC/software based product and sell licenses instead of hardware. Now
their product is just another relic from the past.

The moral: you never know what is going to happen. You may get lucky,
you may not get lucky. If you don't want to take a bet make sure your
effort keeps its value as long as possible.

 

[Nico Coesel]

Selecting the "archaic" 8051 can IMHO be a rather wise decision.

NXP (Philips) is actually discontinueing some of their 8051 based
devices right now.

It's not so much just the re-programming that bothers clients. It's the
fact that any obsolescence of a single-sourced part mandates a relayout,
writing another ECO, possibly causing some service nightmares, and in my
business often a new regulatory approval process. The latter can throw
you a real curve.

That depends on the type of equipment. But I think its safe to say
most equipment needs to adhere only to EMC and safety regulations.
These tests are not terribly expensive.

Most embedded tool sets allow a choice between strict ANSI adherence and

The ANSI adherence usually throws you back 2 decades. Modern C/C++
compilers are far more strict to what they allow and disallow in order
to reduce coding errors.

full-feature. Staying away from HW-specifics can be quite tricky though.
Just the bootloader ini-sequences alone can already put you in a bind
where you have no choice. If you don't do the right clock/reset tap
dance it ain't going to load and that dance is (usually) different
between mfgs.

Yes, but this can be overcome by writing your own unified bootloader
which accepts files uploaded by X-modem or Y-modem to reprogram
itself. You could combine all binaries for all types of
microcontrollers in the field into one file and have the device figure
out which part it needs. No need to bother the field engineer with the
type of hardware.

 

[Jim Granville]

Yes, but this can be overcome by writing your own unified bootloader
which accepts files uploaded by X-modem or Y-modem to reprogram
itself. You could combine all binaries for all types of
microcontrollers in the field into one file and have the device figure
out which part it needs. No need to bother the field engineer with the
type of hardware.

Sure. Everyone's uC has an X-modem connection and parser built right in.
Plus, everyone has solid, corporate-wide standards for such parsers.

Why am I reminded of the Ariane rocket at this point ?

Quite a lot of system exclude field updates, and some even
mandate that they are not possible.

-jg

 

[Robert Scott]

Why? Devices with similar functionality usually have a similar price.
These days a controller based on the ARM7TDMI costs the same as an
8051 based micro.

When I speak of "paying a price" for portability, I am refering to more than
just the cost of the part. I also include the cost associated with the
compromises that may be made due to limiting your choices. Suppose we divide up
all micros into two group: those that you consider well-suited for portability
and those that you don't. If it could be said that in every application served
by a micro from the second group there is a micro in the first group that could
serve that application just as well, then you would be right. There would be no
cost for portability. But what if the application has unusual requirements for
power, operating voltage, physical size, or special peripherals? If the micro
that best serves such an application happens to be in the second group, you
might not find any micro in the first group that meets every one of those
requirements. If you insist on using only micros from the first group, then you
might need to make your package a little bigger, supply a slightly bigger
battery, or cut back on some other spec. That is a cost.

Now you go on to illustrate the benefits of portability. On that point I have
no argument. There is obviously a benefit to writing portable software. But
especially when you get into the realm of the 8-pin micros (8-pin, not 8-bit),
it is easy to imagine applications that would be almost impossible without
resorting to "non-portable" software. Fortunately, such applications have
programs that are so small that the cost of re-writing them, if necessary, can't
be very high. So for these applications, the benefits of portable software are
minimal, and the cost of insisting on portability is much higher. So there is a
cost-effectiveness decision to be made, depending on the application.

Robert Scott
Ypsilanti, Michigan

 

[Joerg]

NXP (Philips) is actually discontinueing some of their 8051 based
devices right now.

Yeah, personally I have adopted a wait and see attitude when it comes to
former Philips parts. Before designing anything in I want to see how
things shake out.

That depends on the type of equipment. But I think its safe to say
most equipment needs to adhere only to EMC and safety regulations.
These tests are not terribly expensive.

Around $15-20K plus the manhours for your own engineers, usually. But
only if you get it licked the first time, not if you fail and have to go
again.

Medical is a totally different story. Reems of validation, a mountain of
paperwork. Realistically north of $100K. And that isn't something I
picked out of my hat. I am doing this since about 20 years ;-)

The ANSI adherence usually throws you back 2 decades. Modern C/C++
compilers are far more strict to what they allow and disallow in order
to reduce coding errors.

True. But they aren't standardized and in some industries that matters a
lot.

Yes, but this can be overcome by writing your own unified bootloader
which accepts files uploaded by X-modem or Y-modem to reprogram
itself. You could combine all binaries for all types of
microcontrollers in the field into one file and have the device figure
out which part it needs. No need to bother the field engineer with the
type of hardware.

That would require clairvoyant skills. Crystal ball, coffee ground
reading, your pick. When a new micro comes out who knows how it wants
the bootload procedure initialized?

 

[Joerg]

When I speak of "paying a price" for portability, I am refering to more than
just the cost of the part. I also include the cost associated with the
compromises that may be made due to limiting your choices. Suppose we divide up
all micros into two group: those that you consider well-suited for portability
and those that you don't. If it could be said that in every application served
by a micro from the second group there is a micro in the first group that could
serve that application just as well, then you would be right. There would be no
cost for portability. But what if the application has unusual requirements for
power, operating voltage, physical size, or special peripherals? If the micro
that best serves such an application happens to be in the second group, you
might not find any micro in the first group that meets every one of those
requirements. If you insist on using only micros from the first group, then you
might need to make your package a little bigger, supply a slightly bigger
battery, or cut back on some other spec. That is a cost.

Now you go on to illustrate the benefits of portability. On that point I have
no argument. There is obviously a benefit to writing portable software. But
especially when you get into the realm of the 8-pin micros (8-pin, not 8-bit),
it is easy to imagine applications that would be almost impossible without
resorting to "non-portable" software. Fortunately, such applications have
programs that are so small that the cost of re-writing them, if necessary, can't
be very high. So for these applications, the benefits of portable software are
minimal, and the cost of insisting on portability is much higher. So there is a
cost-effectiveness decision to be made, depending on the application.

However, you do need to factor in the cost for the re-cert. In medical
that can easily swamp everything else.