mvme5500, PowerPC, VME, and end-of-life issues

rwas rbtwas at gmail.com
Tue May 14 22:08:22 UTC 2013


Peter Dufault wrote:
>  Arrow recently notified my client using the MVME5500 that it is
>  end-of-life with a last order coming up in June.  I told them to
>  check if the situation is the same for the MVME6100.
>
>  Is there anyone else using PowerPC, VME, and RTEMS that has a similar
>  issue and what are you thinking of?  My thinking is that since you
>  can still get MVME167 boards without too much trouble my client
>  should start a migration to a modern architecture, away from VME, to
>  complete over the next few years.  If the MVME6100 isn't end-of-life
>  then switch to that during the change-over, if not just stick with
>  the MVME5500 during the change.
>
>  Or is there something special about the availability of old boards
>  like the MVME167 that doesn't apply to the MVME5500?

Then there is the mvme177.

For my project, I chose the mvme5500 because of the rtems bsp support. That
and the mvme5500 at the time was plenty fast and considerably cheaper 
than the
later Motorola/Emerson models also available at the time. If there had 
been rtems support for something
like the mvme6100, I would have considered that board as well.

As far as hanging on to the older 68k based vme boards, I'd say it has 
everything to do with supporting
existing code, and making use of existing ?x?orks development licenses.

I can tell you that the military likes VME. It's too bad (IMO) that the 
newer concepts intended to supercede
VME are so Buck Rogers, and force you to ditch your old hardware. From 
my experience, no one in the military
is going to want to spend precious development time spinning up on 
latest over-engineered bus designs when tried
and true, cheap hardware is laying around. They are also not going to 
want to commit the existence of a project to
the hope that some new Buck Rogers hardware is not going to have some 
unforseen gotcha,/show-stopper type problem, when again,
tried and true hardware and development methods exist.

Having one of those (gotcha/show-stopper) can mean your particular 
engineering group is now in the critical path (never pleasant).
And if that does happen to cause one too many slips in schedule, you 
could find your program canceled
(the number of slips you're allowed before the axe falls has shrunk 
dramatically as of late).

Robert W.




More information about the users mailing list