Single-Source PIC, AVR & Alternatives

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.

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

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

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

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.

be

Don't

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

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

be

Don't

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.

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

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.

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

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.

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.

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

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.

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

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

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?