Embedded processor selection for long-life product

I am faced with selecting a replacement processor/uC for a re-design of some industrial controller/safety equipment. The technical requirements can be satisfied by just about any 32bit risc style uP/uC, but one key requirement is that since the product life is decades long, the particular part or at least the architecture should continue to be supported by the vendor for as long as possible.

This seems a pretty tough requirement. Years ago, the x86 would have been a good choice, but probably not today. I also think this pretty much rules out any Microchip or Atmel parts as their 32bit line is too new and they have already obsoleted their earliest parts. The latest architectures may be too new to say anything about longevity. I am leaning towards the ARM architecture or perhaps MIPs - something that already has a very large installed base to guarantee continued support. Thoughts?

Reply to
tns1
Loading thread data ...

You probably won't be able to secure the kind of stability in actual or simulated (ASIC) hardware environments that surround the processor, as the x86 received driven by 'compatibility' pressures of the market, anywhere else. But in terms of software tools used to develop the code, the ARM7TDMI as a core has fairly broad support across a number of vendors and is likely to continue for a while. Peripherals will vary, of course, and so will the memory environments and methods for controlling all this... but the tools you use now will probably work satisfactorily on ARM7TDMI processors a decade or two from now, with appropriate changes in code support for peripheral differences you won't be able to entirely avoid.

I like MIPS more than ARM7 instructions, perhaps because of having a longer history with them (1987) if nothing else, but I suspect ARM7 is a better gamble.

But I'm interested in hearing responses, too.

Jon

Reply to
Jonathan Kirwan

On the assumption your ARM7 tools also support the ARM Cortex-M3....

If you are worried about future support consider a lifetime buy of the components.

-- Regards, Richard.

  • formatting link
    &
    formatting link
17 official architecture ports, more than 6000 downloads per month.

  • formatting link
    Certified by TÜV as meeting the requirements for safety related systems.

Reply to
FreeRTOS.org

That isn't so easy. Often, there are many specific parts involved, incoming testing requirements suddenly bunched all at once, long term storage/shrinkage issues, etc. So there are risks in all directions.

Luckily, I'm not so concerned but I am still curious about tradeoffs. Even if one accepts the idea that nothing remains the same for long in this business, there is an advantage thinking about holding the software tool chain as static when supporting products that may need continued production and support long into the future, even if everything else changes around it.

Jon

Reply to
Jonathan Kirwan

We have some long term support requirements where not only have we archived copies of development tools and the version of Windows used to build the software (this is already obsolete) but also entire PC systems on the assumption that the hardware on which this version of Windows is capable of running will also be obsolete.

-- Regards, Richard.

  • formatting link
    &
    formatting link
17 official architecture ports, more than 6000 downloads per month.

  • formatting link
    Certified by TÜV as meeting the requirements for safety related systems.

Reply to
FreeRTOS.org

Why not ? PC104 and variants are long life, and the new Intel Atom runs x86 code fine. You can expect the form factor to change quite quickly on x86, but the code base/software is very stable. Another advantage, is the tools can be Native, not cross-tools.

You could even archive the Tools.Compiler.Build INSIDE each shipped unit :)

You seem to be confusing architecture with device: to be fully SW binary compatible, the 'Architecture' umbrella has to include peripherals and pinouts. As soon as you lose that, you have to recompile and redesign parts of the system.

How many Decades, exactly ? You are right that is a tough call. Even ARM7 is now 'trailing edge', and tagged 'not for new designs' - they have moved on to Cortex M3.

How long will the Cortex M3 last ?

If you want field-longevity, one way is to design at the PCB level, for replacement. Very like the PC104 system does. USB is another physical standard, that will have very long legs.

That also means you are not stuck with a truly ancient system in 15 years time.

How important is price, and power consumption ?

-jg

Reply to
Jim Granville

Motorola/FreeScale has a good reputation for the parts longevity as well as the reliability. The ColdFire will probably last for quite some time; MPC family could be the choice also.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Automotive companies are good at it- the airbag ECU, for example, has to be serviceable in 15 years or so. And you have to have exactly the same unit because of software dependency on car frame characteristics etc. As far, as my memory serves, they use ARM7. If you *really* want a part, that will be around in 15 years, go for automotive. They might be not the fanciest parts, though.

M.W.

Reply to
Marcin Wolcendorf

Microchip tends to keep parts in production. The new PIC32 (MIPS core) might be a good choice.

Leon

Reply to
Leon

Their peripherals also tend to be the same. So even if the core changes then a simple change of the source to define the peripheral base address and a re-compile is required to change MCUs. I have ported code between a CPU32 based MCU, a HC16 and a Coldfire based CPU. Because the peripherals are compatible, the same code runs on all 3 devices. Changing code between ARM MCUs from different manufacturers is a pain. Most of not all the peripheral code must be re-written. IMO keeping the same peripherals is much more important for ease of porting than having the same core. Except pf course when the code is written in assembly.

Regards Anton Erasmus

Reply to
Anton Erasmus

Thanks, Leon. Good point. Microchip also has a reputation for supporting their development tools 'forever,' as well. And my own personal experience with them, regarding their professional-level tool support, is without any peer. Good company in that regard.

Jon

Reply to
Jonathan Kirwan

I was thinking the automotive rating would be a plus just for robustness. Does the fact that Toyota uses a ARM7-gizmo in all their cars mean that that same part is going to be more available to everyone, or do they have purchasing channels that would lock out everyone else? This probably means I would need to select not just an automotive rated part, but one that is in widespread use already.

Reply to
tns1

On Sat, 05 Jul 2008 23:15:21 -0700, tns1 wrote in comp.arch.embedded:

I tend to agree with others that ARM 7 or 9 is probably the best bet. I would suggest starting out with a tool chain that supports at least ARM7 and Cortex M3. ARM7 binaries run unchanged on ARM9, and I believe on ARM11 as well.

As for tool chain, OS, and archiving hardware, there are possibly better ways than physical storage.

Get Microsoft's Virtual PC 2004 SP1, still available at no charge from Microsoft, if you're using Windows XP. Even though it has been "replaced" by the 2007 version, you can still download it here:

formatting link

You might want to snare the 2007 version as well, under the assumption that you might be forced to move Windows Vista someday.

Create a Virtual Machine, preferably Windows 2000 if your tools will run in it. A Windows 2000 VM is much smaller than a Windows XP one. Then install your tools and archive the virtual machine.

I've got a bunch of older tools running under Win2K right now. Some of them run under Windows XP, but not under the managed client crap our IT department pushes onto our desktops.

I've even got an MS-DOS 6.22 VM for running a very old tool chain for a product we still have to support. This compiler won't run under any version of MS-DOS later than 6.x, and also won't run under ANY version of Windows (not even Win 3.x under DOS 6.x). It is happy as a clam under even our managed XP clients in a Virtual PC VM.

VMWare has an import utility for Virtual PC VMs to create VMWare VMs. I've done a little experimentation with this. Eventually I'd like to have my old development VMs running on VMWare Workstation and/or Player. That will add better insurance against Windows changes, I think, and also open up the possibility of running old DOS/Windows development tools under Linux.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

On Sun, 06 Jul 2008 08:07:05 GMT, "FreeRTOS.org" wrote in comp.arch.embedded:

See my reply to the OP. I've had very good luck so far creating virtual machines for running some very antique development tools with free (but not open source) tools.

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

Board level standards for longevity may be the right way to go.

I think the Atom is too new, too complex, way overkill. I need maybe

20-30mips max. Packaging reqs may be restricted to leaded parts due to in-house assy req. Small process geometry may actually be a negative due to lower radiation/cosmic ray tolerance. Think avionics & safety - what would you use?

Good point.

20-40yrs

Good to know.

Not very.

You have some good points. What good does it do me to pick a popular architecture since the exact peripherals may not be exact matches down the road? The ARM core is used by many different vendors and has no standard peripheral set.

All I can do is start with some assumptions and refine goals as I learn more. A simple goal might be to pick a specific part# which will continue to be sold for as long as possible to insure direct support, tools, etc. Maybe this means picking a vanilla part with fewer custom features instead of the 'one chip does as much as possible' approach I would normally use.

A secondary goal might be to pick a popular architecture in the hopes that there will at least be an easier upgrade path down the road.

As much as I dislike x86 for embedded, I have to consider using PC104/x86 or another board standard.

Reply to
tns1

...

...

They tend to have special versions and special agreements with IC vendors. Depending on volume you might succeed asking the vendor. From what I remember my previous company used ARM7TDMI chips from ST in 144 pin pqfp package, just an automotive (and safety-critical) version of some standard part, then they switched to custom-made 100 pin pqfp, probably because of space constraints. I have never seen such an agreement, though, all I've seen were datasheets with secrecy warnings. Try your local distributor or sales office, then you'll know.

Regards,

M.W.

Reply to
Marcin Wolcendorf

That's impoerant new information. Just how 'mission critical' is this ?

Unless you can find a specific avionics qualified part, the next-best would be Automotive flow devices. Longer supply lifetimes, and generally higher quality standards. eg Infineon have ECC in their Automotive flash devices.

You have not mentioned codesize yet. If you can fit this into an Automotive 32 bit (Infineon, Freescale, TI... ) single chip, that is likely to be the most reliable solution.

-jg

Reply to
Jim Granville

More info, OS and toolchain discussion...

This is industrial safety monitoring equipment that also has to meet some minimal radiation rating. Trailing edge technologies with larger process geometries may actually fare better. Compatibility with in-house assembly equipment may eliminate using BGA components.

The overall HW design will include RS232,RS485, current loop, A/D, D/A, a key panel with display, and some GPIO. The biggest change is to add an ethernet port which could be satisfied by some kind of separate serial to ethernet adaptor design as long as all the IP were available.

I am still getting an idea of what my requirements really are and what that means in terms of component selection. My interpretation so far is to stay away from proprietary architectures and tools which may go away. I think I will want the source for every piece, so open source or commercialized open source.

The original system design used the Intel i960 running the Intel iRMK kernel. You are lucky if you can even find any mention of this processor/scheduler combo today (tell me if you find anything), let alone any reference manuals. Intel is still going strong but these particular products have long been abandoned. The old command line cross-tools are still workable under XP, but obviously won't be of use on the re-design.

The iRMK/iRMX product was sold and the new company has continued with the x86 port. I'd consider it if I still wanted to use x86.

The existing kernel is just a scheduler without a filesystem. It only uses the most basic kernel services (tasks, semaphores, mailboxes). The only new complication is ethernet, which may not need to be handled directly by the main processor if it complicates the whole safety verification part too much. There is a big advantage in preserving existing code and task partitioning - something simple and very similar to the existing kernel.

Possible candidates so far are Ecos, QNX, FreeRTOS/SafeRTOS, L4. If it isn't already ported to many devices or the complete source is not available, then it isn't a candidate. On the other hand, my app code is commercial and probably can't be made public.

Reply to
tns1

I'm thinking Freescale Coldfire or some of the automotive or industrial PowerPC controllers might be a good choice. They both have been around a while and should continue to be available. Try

formatting link
for some Coldfire info on real world HW and SW.

Also, you might want to add RTEMS

formatting link
to your OS list.

-Dave-

Reply to
DaveT

If you have such sign-offs, then you might need some Eval-boards, to reality-check before going too far down one pathway.

This could also favour Error Correcting Flash devices, and that will narrow your field a lot. Or a device with Stack Error trapping. Infineon XC2000 family offers those features. (as does XE16x) (and allows 5V ADC operation)

I'm not sure having 100% source code coverage is that important - after all, you got this far without it!

Better is to avoid any sort of security keying on the tools, as that CAN be a long-term killer.

As you say

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.