On Sun, 06 Jul 2008 07:38:09 -0500, Vladimir Vassilevsky
<a...@hotmail.com> wrote:

>
>
>tns1 wrote:
>> 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?
>
>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.
>

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

On Sun, 6 Jul 2008 07:56:58 -0700 (PDT), Leon <l...@btinternet.com>
wrote:

>On 6 Jul, 07:15, tns1 <t...@cox.net> wrote:
>> 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?
>
>Microchip tends to keep parts in production. The new PIC32 (MIPS core)
>might be a good choice.

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

Marcin Wolcendorf wrote:
> Jonathan Kirwan wrote:
>> On Sun, 06 Jul 2008 07:36:43 GMT, "FreeRTOS.org" <n...@given.com>
>> wrote:
>>
>>> <snip>
>>> If you are worried about future support consider a lifetime buy of 
>>> the components.
>>
>> 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.
> 
> 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.
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.

On Sat, 05 Jul 2008 23:15:21 -0700, tns1 <t...@cox.net> wrote in
comp.arch.embedded:

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

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:

http://www.microsoft.com/downloads/details.aspx?FamilyId=6D58729D-DFA8-40BF-AFAF-20BCB7F01CD1&displaylang=en

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
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

On Sun, 06 Jul 2008 08:07:05 GMT, "FreeRTOS.org" <n...@given.com>
wrote in comp.arch.embedded:

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

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
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jim Granville wrote:
> tns1 wrote:
>> 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.
> 
> Why not ?  PC104 and variants are long life, and the new Intel Atom
> runs x86 code fine.
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?

> 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 :)
> 
>> 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.
> 
> 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.
>
Good point.

>> I am leaning towards the ARM architecture or perhaps MIPs - something 
>> that already has a very large installed base to guarantee continued 
>> support. Thoughts?
> 
> How many Decades, exactly ?
20-40yrs
> 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.
Good to know.
> 
> 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 ?
Not very.
> 
> -jg
> 

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.

Frank-Christian Kruegel wrote:
> On Sat, 05 Jul 2008 23:15:21 -0700, tns1 <t...@cox.net> wrote:
> 
>> 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.
> 
> You might consider using softcores in FPGAs. That means that the cpu and all
> peripherials are coded in VHDL or Verilog and compiled into logic that can
> be loaded into an FPGA. If a silicon gets unavailable, you just recompile
> your source for another one. Ok, it'll be a bit more work than just
> recompiling, but much less then changing the system architecture.
> 
> Mit freundlichen Grüßen
> 
> Frank-Christian Krügel

Softcore/FPGA solutions do seem attractive from the view of being able 
to exactly duplicate the design far down the road using very different 
programmable logic devices. The extra design effort and the 
validation/qualification to meet the safety requirements will probably 
nix this idea. At least with a hard core, the manuf. has done a lot of 
this for you. Besides, point me to a 32bit risk soft-core that is 
open-source (not vendor specific), and has reached mainstream.

tns1 wrote:
> Marcin Wolcendorf wrote:
>> Jonathan Kirwan wrote:
>>> On Sun, 06 Jul 2008 07:36:43 GMT, "FreeRTOS.org" <n...@given.com>
>>> wrote:
>>>
>>>> <snip>
>>>> If you are worried about future support consider a lifetime buy of 
>>>> the components.
>>>
...
>> Automotive companies are good at it- the airbag ECU, for example, has 
...
>> a part, that will be around in 15 years, go for automotive. They might 
>> be not the fanciest parts, though.
>>
>> M.W.
> 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? 

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.

tns1 wrote:

> Softcore/FPGA solutions do seem attractive
  [snip]
> Besides, point me to a 32bit risk soft-core that is 
> open-source (not vendor specific), and has reached mainstream.

Perhaps the LEON series from Gaisler at http://www.gaisler.com?

SPARC architecture, space applications, fault-tolerant versions.


-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

On Sun, 06 Jul 2008 23:10:49 +0300, Niklas Holsti
<n...@tidorum.invalid> wrote:

>tns1 wrote:
>
>> Softcore/FPGA solutions do seem attractive
>  [snip]
>> Besides, point me to a 32bit risk soft-core that is 
>> open-source (not vendor specific), and has reached mainstream.
>
>Perhaps the LEON series from Gaisler at http://www.gaisler.com?
>
>SPARC architecture, space applications, fault-tolerant versions.

Yes, this was my first thought, too. These cores are being used in harsh,
mission-critical environments in radiation tolerant FPGAs (mainly Actel
Anti-Fuse technology), so they are known good. And being SPARCs, it should
be no problem to get the gcc sources and build a cross compiler for about
any Unix-like environment.


Mit freundlichen Grüßen

Frank-Christian Krügel