Re: RTMES vs VxWorks

[Till Straumann <strauman@slac.stanford.edu>]

We started using RTEMS 8 years ago as our RTOS of choice for
the upgrade of the control system for the SPEAR3 electron
storage ring at the Stanford Synchrotron Radiation Lab.

The most demanding real-time application (among others)
is the electron-beam orbit feedback which is a distributed
system involving 21 CPUs communicating over a timing system
and a dedicated LAN using raw ethernet packets for communication.

The feedback system updates at a rate of 4kHz (250us
cycle time) and requires an interrupt latency less
than a few microseconds.

The transverse position of the beam is calculated by
2 CPUs which are dedicated to beam-position monitor
data acquisition and processing. The orbit information is
forwarded over dedicated ethernet links to a central
feedback CPU which computes new setpoints for steering
magnets using the PowerPC's AltiVec vector-coprocessor.
The setpoints are propagated to 18 other computers
controlling the corrector magnets.

The total processing time including data acquisition,
processing and communication is < ~750us.

All of the involved CPUs also concurrently (but at
a lower priority) run EPICS for control
and monitoring purposes and handle a lot of processing
and networking.

This orbit-feedback system has been running smoothly for
about 2 years now.

RTEMS is also employed for most parts of the LCLS (Linac Coherent
Light Source) control system - which is a quite big project -
and is being used on the data-acquisition side of
the LCLS, too.

We have used RTEMS on several platforms: various VME powerpc SBCs,
credit-card sized Coldfire embedded CPUs, the powerpc core in virtex-4
FPGAs and a CPCI x86 SBC.

When we started, some IMO crucial components (e.g., NFS client,
a more powerful shell supporting symbol-table access and run-time
loading), were unavailable for RTEMS but they have since been
developed.

We also have implemented multiple RTEMS BSPs.

Existing EPICS driver and device-support implementations
for vxWorks can usually be ported fairly easily. In most cases
this only involves migrating the use of OS objects such as
tasks, semaphores etc. from vxWorks to the EPICS OSI API.


WKR
-- Till

GOURNAY Jean-Francois wrote:
> Hello All,
>
> We are in the design phase of a new accelerator project which will be 
> built in the frame of the so-called “broader approach of the ITER 
> project”. The goal of this accelerator (Eveda) is the validation of 
> the solutions for the future high power accelerator IFMIF 
> (/International Fusion Materials Irradiation Facility). /
>
> The control system will be based (of course) on Epics with VME IOCs. 
> The question is which RT OS to use? We are users of VxWorks for a very 
> long time for several projects and we were always very happy with this 
> system. It’s expensive and we are no more privileged customers of 
> VxWorks but it’s for sure a great product. As we saw some interest for 
> RTEMS in the community, we did complete tests with Epics including the 
> port of drivers for our favourite modules. All this was satisfactory, 
> so we are really now at a cornerstone… and we need some feedback of 
> facilities using RTEMS. What are the advantages or drawbacks based on 
> your experience? Reliability? Off-the-shelf availability of drivers 
> (for PMC modules for example)? availability of great features of 
> VxWorks like the global symbol table or the interactive functions 
> call? Etc …
>
> Many thanks,
>
> Jean-François
>
> J.F. Gournay
>
> CEA Saclay
>
> IRFU/SIS