Hi Mike,
On 04/20/2016 12:31 PM, Michael Westfall wrote:
> We are in fact wanting to port the vmi5588 driver to EPICS OSI
> compliance, so that it can run on an RTEMS IOC.
>
> Since you wrote that driver originally, maybe you have some idea as to
> how to proceed?
Wow, I haven't looked at that code since the '90s. Do you know of any
changes made since the 2002 version published by Observatory Sciences?
BTW OSL only seem to be publishing the driver code, so I don't have
access to the device support at all. Looking at the source code that I
just downloaded from them I can see why you are asking about the
registry, but unfortunately I don't think it quite fits what you need to
replace symLib.
Neither the registry nor the underlying gpHash facility from libCom
provide an suitable equivalent to the symEach() function that is called
in rmPrintSymbols() to scan through all of the known symbols in turn.
That means you'll have to write a bit more code in the driver to fully
replace symLib, and I would recommend using libCom's gpHash facility
directly to avoid the registry's overhead.
In order to be able to scan all of the loaded symbols the driver will
have to keep a linked list of them, and it will also need a gpHash to do
fast lookups by name. There are several examples found in Base's
dbStatic library, look at how drivers (struct drvSup) are stored (by
dbDriver() in dbLexRoutines.c) and retrieved (sequentially from the
pdbbase->drvList by dbWriteDriverFP() and by name lookup in the
pdbbase->pgpHash by dbFindDriver() in dbStaticLib.c).
You should create your own gpHash table using gphInitPvt() rather than
trying to re-use the one in pdbbase, and you'll also need an ELLLIST.
For each symbol you'll need a data structure like the struct drvSup
containing an ELLNODE, a name, and storage for the page number and
offset (or you could combine them into a single epicsInt32).
Note that the 3rd argument to the gphFind() and gphAdd() routines can be
any pointer; its value is only used to distinguish between different
types of objects stored in the hash table — the same pointer value must
be passed to gphFind() that was given in gphAdd() for the object being
looked for. It doesn't matter what it actually points to though, and in
this case I would use a different pointer for each of the RM_TYPE_*
symbol types.
HTH; if you need more detail on anything let me know. I'd also be happy
to review your code changes if you like.
- Andrew
--
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery
-- Mathias Verraes
- References:
- How to use registry to replace vxWorks symLib? Michael Westfall
- Re: How to use registry to replace vxWorks symLib? Andrew Johnson
- Re: How to use registry to replace vxWorks symLib? Michael Westfall
- Navigate by Date:
- Prev:
Re: How to use registry to replace vxWorks symLib? Michael Westfall
- Next:
Re: Script BOY IntensityGraph to show areaDetector output of variable size Phil Atkin
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: How to use registry to replace vxWorks symLib? Michael Westfall
- Next:
Dropped frames from GigE cameras on Linux Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|