EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Ideas / Suggestions for the future of VME-CPU Operating Systems
From: Dirk Zimoch <[email protected]>
To: <[email protected]>
Date: Thu, 21 Sep 2017 10:06:29 +0200
Hello Götz,

Switching from vxWorks to Linux for our VME IOCs was a <del>lot of fun</del> ... uhm ... interesting.

The Linux OS we use is based on ELDK 5.2 using U-Boot as the boot loader. See http://www.denx.de/wiki/ELDK-5/WebHome

Luckily there have been BSPs in ELDK for similar systems (using the same processor at least). The manufacturer of the board has provided us with the necessary modifications to U-Boot to get the board running. They provided a Linux driver for the VME bridge as well but we basically had to re-do it from scratch.

We used the latest RT-patched Kernel available at that time. Upgrading the kernel is a bit of a mess because the kernel API changes all the time and one needs to modify self-made kernel drivers with every upgrade.

The trickiest part with VME on Linux was to get the VME interrupts into users space without hanging up the whole system. (The standard Linux VME support is a kernel-only API which does not help bringing interrupts to EPICS.) Also, as a context switch is involved, this has considerably more latency than in vxWorks.

But all in all, I think it was worth the effort because you have so much more debugging possibilities with Linux than with vxWorks. Most important you won't always crash the whole OS when you have a bug in your code -- except if the bug is in the kernel driver -- or you manage to screw up the bus bridge. :-)

I do not know if ELDK has support for the various MVME* boards but you can ask DENX.

Best regards,
Dirk

On 20.09.2017 11:28, Goetz Pfeiffer wrote:
Hello,

at the Helmholtz-Zentrum Berlin (https://www.helmholtz-berlin.de/) we
use EPICS for our control system.

We have a growing number of soft IOCs with Linux and VME bus based IOCs
mostly running RTEMS and
some vxWorks 5.4 (Tornado 2.02).

Our CPU boards are MVME162 and MVME2100. We have replaced more than half
of the old MVME162 boards with
MVME2100 boards, of which we bought a large supply some years ago.

After migrating most VME CPUs to RTEMS 4.9 we have run into some problems:

  * Newer CPU boards like the MVME5500 require the "beatnik" board
    support, which only works with RTEMS 4.10
  * RTEMS 4.10 has some problems regarding the "cexp" shell and doesn't
    work on some of our IOCs.
  * cexp, the shell for RTEMS is not compatible with RTEMS 4.11 and
    4.12, but we need it for dynamic loading of objects
  * gesys, the component that is used to create the RTEMS kernel seems
    to be a bit of a mess
  * RTEMS 4.11 and 4.12 are not supported by the EPICS base
  * Debian Packages for RTEMS are no longer maintained
  * The intersection of the people using RTEMS and the ones using EPICS
    seems to be small and getting smaller, so with problems we are much
    on our own

A possibility would be to use vxWorks again. Our current vxWorks version
is /very/ old and has to be updated. Problems here:

  * MVME2100 boards do not seem to be supported by vxWorks 6
  * Possibly high costs for CPU licenses for vxWorks

What are your experiences with this ?

Do you still use VME bus systems ?

Is there a future for RTEMS in EPICS control systems ?

Are there alternatives to RTEMS and vxWorks ?

Greetings,

  Goetz Pfeiffer


References:
Ideas / Suggestions for the future of VME-CPU Operating Systems Goetz Pfeiffer

Navigate by Date:
Prev: RE: dbVerify removed from EPICS 3.16 michael.abbott
Next: Re: Ideas / Suggestions for the future of VME-CPU Operating Systems Goetz Pfeiffer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Ideas / Suggestions for the future of VME-CPU Operating Systems Michael Davidsaver
Next: Re: Ideas / Suggestions for the future of VME-CPU Operating Systems Goetz Pfeiffer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·