| 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Field support |
| From: | "Rees, NP (Nick)" <[email protected]> |
| To: | <[email protected]> |
| Date: | Fri, 17 Apr 2009 16:02:11 +0100 |
All,
Attached is the result of the field support work I did at the codeathon.
There are two files - a gzipped patch file which is a patch against the
version of base I downloaded this morning labeled 17 April 2009, and a
makeBaseApp application which implements a default version of field
support.
New files in base are:
- src/dbStatic/fldSup.h - This declares the new field Support
structure and helper routines. There are a
number of forward structure declarations,
because I wasn't sure about the exact
order of include files.
- src/fldSupParams.c - additional dbStaticLib routines for saving
and restoring field support parameters.
- src/db/dbAccessFldSup.c - These routines have extracted all the if
(prset->function) (*prset->function)(param)
type calls for field support into one file
so they are done consistently. It also
reduces the number of changes needed in
dbAccess.c and the convert routines.
- src/db/dbAccessFldSup.h - header file for the above. Since all the
field support routines now have their
prototypes fully declared this uncovered a
number of times where longs were being
passed as int's in get_precision in the
convert routines. This is a bug and should
be fixed.
Other files changed (apart from Makefiles) are dbAccess.c and the
convert routines in src/db; dbBase.h, dbStaticLib.c and dbLexRoutines in
src/dbStatic, and iocInit.c. I have re-used the driver support registry
because I couldn't be bothered to implement something special for field
support (why do we have all these separate registry's anyway?).
The test app provides a default version of field support
(fldSupDefault.c) that provides a fairly traditional implementation for
cvt_dbaddr, get_array_info, put_array_info, get_units, get_precision,
get_graphic_double, get_control_double and get_alarm_double. It isn't
ready for prime time - there are a few printf's just to reassure you
that things are working. However it is basically there. The dbd for the
VAL field of a waveform record now looks like:
field(VAL,DBF_NOACCESS) {
prompt("Value")
asl(ASL0)
special(SPC_DBADDR)
fldSup(fldSupDefault_fset)
fldSup_bptr(BPTR)
fldSup_type(FTVL)
fldSup_nelm(NELM)
fldSup_nord(NORD)
fldSup_prec(PREC)
fldSup_units(furlongs)
fldSup_hopr(HOPR)
fldSup_lopr(LOPR)
fldSup_drvh(HOPR)
fldSup_drvl(LOPR)
fldSup_hihi(HOPR)
fldSup_high(HOPR)
fldSup_low(LOPR)
fldSup_lolo(LOPR)
pp(TRUE)
extra("void * val")
}
This is a lot longer than before, but you no longer need any of the
record support routines...
I hope its fairly obvious, but the values in the fldSup_ bits can be
other fields in the same record or constants. If you leave them out then
the corresponding field support routine returns S_db_noRSET.
As to what else to do, I was going to experiment with supporting arrays
and maybe strings a bit more. I am not sure what else it is good for,
but that may come.
I also don't quite know how this fits in with Andrew's code generation
work, but that is mainly because I don't know what that is. Andrew, is
there any reference for that anywhere - I would be interested in knowing
what you are getting at there - I know what you are doing in principal,
but not in practice.
Any comments are welcome.
Cheers,
Nick Rees
Principal Software Engineer Phone: +44 (0)1235-778430
Diamond Light Source Fax: +44 (0)1235-446713
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Attachment:
fldSupBase_20090417.patch.gz
Description: fldSupBase_20090417.patch.gz
Attachment:
testFldSup.tgz
Description: testFldSup.tgz