Hi Andrew,
Thank you for the comprehensive response!
Your recommendations are on par with what I was thinking and what most
other people have suggested to me in private emails. The MVME series of
VME SBCs seems the logical choice given that the community has great
experience with them and the two main candidate real time OSes work well
with it.
I mentioned Linux having RTAI Linux in mind, but I don't think there are
many users of that in the EPICS world. Given the magnitude of the task
ahead of me, I am willing to "go with the flow" and select vxWorks or
RTEMS, and leave the experimentation for the future.
I noticed that most similar facilities are using vxWorks 5.5, but I
believe there is another stream, 6.7. Is there any reason to stick to
5.5 or is it irrelevant for the typical EPICS application?
cheers
Dimitris
On Mon, 2009-08-17 at 11:38 -0500, Andrew Johnson wrote:
Hi Dimitris,
Welcome to the EPICS community!
On Sunday 16 August 2009 18:22:33 Dimitrios Tsifakis wrote:
We currently have custom made systems based on older technology that
some may regard as obsolete. After reading a lot about EPICS on the net,
I have come to the conclusion that EPICS is the most reasonable choice
for upgrading our systems. As a first approach, I would like to replace
the current VME SBCs in the computer control crates with more modern
ones that can run vxWorks, RTEMS or Linux of some sort. After doing a
quick survey of the market, I have come to the conclusion that there are
many choices that will meet all the requirements, but are there any VME
SBCs that are preferred by the community for use with EPICS?
EPICS should run on almost any VME SBC that has a BSP for the appropriate OS,
but the community has experience with a limited subset of the boards
available, and if you're going to need much hand-holding you might be better
off limiting your choices to those about which we can answer questions.
Your first issue should be what RTOS you're going to use.
I don't recommend choosing Linux for VME SBCs because of the complications of
writing kernel device drivers for Linux, especially since a standard VMEbus
interface has only very recently made it into the Kernel staging area. It is
possible to mmap() VME cards into user space, but interrupt response from
such configurations leaves quite a lot to be desired. Of course if you have
experience in this area then Linux may work out fine, but don't expect much
help from us on that aspect.
That leaves a choice between vxWorks and RTEMS (unless you want to port EPICS
to another RTOS). In the past most drivers were written to use the vxWorks
APIs directly, but that is becoming much less common since we have an
OS-independent layer in EPICS and converting vxWorks drivers to use this
instead has been pretty common. As a result several recent projects have
decided to use RTEMS, which avoids having to pay annual fees to Wind River.
The advantage of vxWorks is that almost every VME SBC comes with a vxWorks
BSP, whereas RTEMS support is less common. The cost of paying OAR to write
an RTEMS BSP for your choice of hardware is not huge though, and in your
position you can probably pick boards that are already supported. VxWorks
BSPs often need tweaking slightly, and having the WRS paid support won't
preclude the need for developing some local vxWorks expertise so that aspect
of the cost is probably about even (although longer-term RTEMS may be more
flexible and work out cheaper). One advantage of picking RTEMS and a
currently-supported SBC is that you can still change your mind and switch to
vxWorks later on without having wasted any money paying for the OS!
If you're looking for a cheap work-horse SBC and don't need a top-performing
CPU, the Emerson (formerly Motorola) MVME3100 board is well-supported under
RTEMS and is used at more than one EPICS site. There are also BSPs available
for the Emerson MVME5500 and MVME6100 boards if you need more CPU power.
RTEMS also supports several older MVME boards such as the 167, 2700 and 2100
if you have existing hardware you'd like to re-use.
HTH,
- Andrew
