RE: EPICS Base's support on Phar Lap ETS

["Jeff Hill" <johill@lanl.gov>]

Hi Alex,

 

Integration of your efforts into the distribution sounds like a great idea to me. This will of course be beneficial for LabVIEW / EPICS integration.

 

Ø  Only WinSock 1.1 is supported on Phar Lap

 

That’s unfortunate because newer Winsock interfaces have been around for a long time, and we do use them to query the list of network interfaces that are attached. What is implied functionally is that EPICS can populate the address lists for search requests and beacons automatically (EPICS_AUTO_ADDRESS_LIST=YES) if winsock II is available – otherwise not. As I recall, the winsock II interface is not available initially only on certain archaic W95/98/NT windows OS, and furthermore I think that we are currently not supporting system that don’t have winsockII because as, at one time, it wasn’t difficult to upgrade older systems.

 

Ø  You cannot create a process, only one process allowed on PharLap

 

Really not an issue because on such systems {currently RTEMS and vxWorks} we just spawn off a thread instead. We only need to stub out which one is allowed in an OS specific code.

 

Ø  Thread Priority Range is (-128 to 127), much like VxWorks' (0 to 256)

 

Ditto – we only need to stub out in OS specific code the code that maps the priority.

 

So I see three issues that someone will need to look into:

1)      The pharlap constraints are strongly reminiscent, if I recall correctly, of Windows CE constraints. So perhaps we should try to look for a source code structure that will allow also Windows CE to be easily integrated.

2)      Packaging is maybe also an important issue as we might prefer to have a common directory under libCom/osi/os that is shared by pharlap, win32, and Windows CE so that the code is properly organized for easy maintenance. Perhaps we will need folders under osi/os called winXX, WIN32, pharlap, and WINCE?

3)      Do we give up on querying the network interface on pharlap and Windows CE or is there some OS specific plug-in we can implement? That approach is certainly easily accommodated by the current structuring of the source code if alternative callable interfaces exist specific to pharlap. In fact, we already have an OS specific plug in for winsock as I recall.

 

Thanks for your efforts,

 

Jeff

 

From: core-talk-bounces@aps.anl.gov [mailto:core-talk-bounces@aps.anl.gov] On Behalf Of Alex.Chen@ni.com
Sent: Monday, August 18, 2008 3:51 AM
To: core-talk@aps.anl.gov
Subject: EPICS Base's support on Phar Lap ETS

 

Hi guys,

    We're trying to migrate EPICS Base to Phar Lap ETS ( a real-time operating system from Ardence ) these days, and it turns out the modified Base works well on Phar Lap. Phar Lap's system API is much like the WIN32 API, with the differences as follows:
1. Thread Priority Range is (-128 to 127), much like VxWorks' (0 to 256)
2. You cannot create a process, only one process allowed on PharLap
3. Only WinSock 1.1 is supported on Phar Lap
4. Other minor issues...

    What I want say is can we make some contribution to the EPICS Base, let the libCom support a new realtime OS Phar Lap ETS? Any suggestions from you guys are appreciated :-)

Thanks,

Alex Chen | R&D, NI China | Tel: +86 21 50509810 ext.3221