Robert Scott wrote:

> On Thu, 14 Dec 2006 17:46:51 GMT, nico@puntnl.niks (Nico Coesel) wrote:
> 
> 
>>---@--- (Robert Scott) wrote:
>>
>>>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.
> 
> 
> 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.

-- 
Regards, Joerg

http://www.analogconsultants.com

Nico Coesel wrote:
> Joerg <notthisjoergsch@removethispacbell.net> wrote:
> 
> 
>>Nico Coesel wrote:
>>
>>
>>>Joerg <notthisjoergsch@removethispacbell.net> wrote:
>>>
>>>
>>>
>>>>rickman wrote:
>>>>
>>>>
>>>>
>>>>>Ulf Samuelsson wrote:
>>>>>
>>>>>
>>>>>
>>>>>>"rickman" <gnuarm@gmail.com> skrev i meddelandet
>>>>>>news:1165869096.359955.303550@79g2000cws.googlegroups.com...
>>>>>>
>>>>>>
>>>>>>
>>>>>>>steve wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>The new SAM7L series is claimed to be ultra low power and have LCD
>>>>>>>>drivers, which is the combo I need, but Atmel is also coming out with
>>>>>>>>Xmega AVR's series shortly (from the rumor mill), who knows what
>>>>>>>>features they will have.
>>>>>>>
>>>>>>>Yes, but the term "ultra low power" has little real meaning just like
>>>>>>>"pico power".  The pico power parts have low static current draw, but
>>>>>>>that is only an issue in apps that have to remain in sleep mode for
>>>>>>>more than 99% of the time.  Otherwise the SAM7 parts were designed for
>>>>>>>very low active power and were made in a newer process than the AVRs,
>>>>>>>so they get better power consumption.  I don't think the Xmega parts
>>>>>>>are going to do any better.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>The Picopower has a power curve that starts at close to zero and increases
>>>>>>in almost a linear fashion.
>>>>>>The main advantage of Picopower is when you are in sleep mode
>>>>>>or are running at low clock frequencies.
>>>>>>When running at high frequency, the main benefit is from the new
>>>>>>cell library, which is not present in the ATmega128, that Rickman
>>>>>>compares with.
>>>>>
>>>>>
>>>>>I looked at the data sheet for the pico power part you recommended, the
>>>>>ATmega324P.  It does not seem to be significantly better than the
>>>>>ATmega128.  It draws 7.4 mA at 8 MHz which is 37 mW at the rated 5 volt
>>>>>power.  It draws 2.1 mA at 4 MHz and 0.4 mA at 1 MHz.  This is
>>>>>essentially the same (or worse) as the SAM7S parts, no?  The price
>>>>>listed in the press release is not any better than SAM7 prices.
>>>>>
>>>>>As much as you wave your arms, I have not seen any information that
>>>>>shows that either the SAM7 or the AVR devices will do a good job of
>>>>>competing against the CM3 devices coming out in 2007.  I understand
>>>>>that with limited resources it may not be the best idea for Atmel to
>>>>>develop a CM3 device line at this time.  But I think it is pretty clear
>>>>>that the CM3 is the way that ARM designs will be headed in the near
>>>>>future and that the days of the ARM7 are numbered.
>>>>>
>>>>
>>>>" ... 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. ...
>>
>>
>>Selecting the "archaic" 8051 can IMHO be a rather wise decision.
> 
> 
> 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.

> 
>>> ... 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.
> 
> 
> 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 ;-)

> 
>>>* 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 
> 
> 
> 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.

> 
>>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.
> 

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?

-- 
Regards, Joerg

http://www.analogconsultants.com

On Thu, 14 Dec 2006 17:46:51 GMT, nico@puntnl.niks (Nico Coesel) wrote:

>---@--- (Robert Scott) wrote:
>>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.

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

Nico Coesel wrote:
> Joerg <notthisjoergsch@removethispacbell.net> wrote:
> 
>>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.

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

Joerg <notthisjoergsch@removethispacbell.net> wrote:

>Nico Coesel wrote:
>
>> Joerg <notthisjoergsch@removethispacbell.net> wrote:
>> 
>> 
>>>rickman wrote:
>>>
>>>
>>>>Ulf Samuelsson wrote:
>>>>
>>>>
>>>>>"rickman" <gnuarm@gmail.com> skrev i meddelandet
>>>>>news:1165869096.359955.303550@79g2000cws.googlegroups.com...
>>>>>
>>>>>
>>>>>>steve wrote:
>>>>>>
>>>>>>
>>>>>>>The new SAM7L series is claimed to be ultra low power and have LCD
>>>>>>>drivers, which is the combo I need, but Atmel is also coming out with
>>>>>>>Xmega AVR's series shortly (from the rumor mill), who knows what
>>>>>>>features they will have.
>>>>>>
>>>>>>Yes, but the term "ultra low power" has little real meaning just like
>>>>>>"pico power".  The pico power parts have low static current draw, but
>>>>>>that is only an issue in apps that have to remain in sleep mode for
>>>>>>more than 99% of the time.  Otherwise the SAM7 parts were designed for
>>>>>>very low active power and were made in a newer process than the AVRs,
>>>>>>so they get better power consumption.  I don't think the Xmega parts
>>>>>>are going to do any better.
>>>>>>
>>>>>
>>>>>
>>>>>The Picopower has a power curve that starts at close to zero and increases
>>>>>in almost a linear fashion.
>>>>>The main advantage of Picopower is when you are in sleep mode
>>>>>or are running at low clock frequencies.
>>>>>When running at high frequency, the main benefit is from the new
>>>>>cell library, which is not present in the ATmega128, that Rickman
>>>>>compares with.
>>>>
>>>>
>>>>I looked at the data sheet for the pico power part you recommended, the
>>>>ATmega324P.  It does not seem to be significantly better than the
>>>>ATmega128.  It draws 7.4 mA at 8 MHz which is 37 mW at the rated 5 volt
>>>>power.  It draws 2.1 mA at 4 MHz and 0.4 mA at 1 MHz.  This is
>>>>essentially the same (or worse) as the SAM7S parts, no?  The price
>>>>listed in the press release is not any better than SAM7 prices.
>>>>
>>>>As much as you wave your arms, I have not seen any information that
>>>>shows that either the SAM7 or the AVR devices will do a good job of
>>>>competing against the CM3 devices coming out in 2007.  I understand
>>>>that with limited resources it may not be the best idea for Atmel to
>>>>develop a CM3 device line at this time.  But I think it is pretty clear
>>>>that the CM3 is the way that ARM designs will be headed in the near
>>>>future and that the days of the ARM7 are numbered.
>>>>
>>>
>>>" ... 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. ...
>
>
>Selecting the "archaic" 8051 can IMHO be a rather wise decision.

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

>>  ... 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.

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.

>> * 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 

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.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

---@--- (Robert Scott) wrote:

>On Wed, 13 Dec 2006 20:22:53 GMT, nico@puntnl.niks (Nico Coesel) wrote:
>
>>...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

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.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Robert Scott wrote:
> On Wed, 13 Dec 2006 20:22:53 GMT, nico@puntnl.niks (Nico Coesel) wrote:
>
> >...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

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.

"Robert Scott" <---@---> wrote in message 
news:45807408.17932578@news.provide.net...
> On Wed, 13 Dec 2006 20:22:53 GMT, nico@puntnl.niks (Nico Coesel) wrote:
>
>>...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.

My own experience is that most projects/products outlive the component 
availability. As a result we try not to rely on magic features of particular 
devices if we help it. A case in point was a product range released in 1995, 
so developed in 1993-1994, where the two (different) processors went 
obsolete around 2000. The replacement also used two processors but with a 
different split of resposibilities. Even so vertually all of the code was 
ported over unchanged (so well placed macros eased the pain) - about 80k 
lines. The product name was updated, the box was changed from angular to a 
rounded one, but otherwise business as usual. But, of course, now it is time 
to upgrade the software i.e. a new marketing team has been installed and 
they could possibly sell the trash we currently make...

Peter 

Robert Scott wrote:

> On Wed, 13 Dec 2006 20:22:53 GMT, nico@puntnl.niks (Nico Coesel) wrote:
> 
> 
>>...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.
> 

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

-- 
Regards, Joerg

http://www.analogconsultants.com

Tim Wescott wrote:


[...]

>>>
>>> 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.
>>
> 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.

-- 
Regards, Joerg

http://www.analogconsultants.com