I'm writing both device and driver support layers for my custom device. I'm trying to make them as generic as possible, but for that purpose I need to pass them some configuration parameters.
They interface with common records: AI, AO, BI and BO. I'm trying to pass those configurations parameters, via INP/OUT field of those records. There are four parameters I would like to pass. For instance, I would like to be able to do something
like:
record(ai, "LOCON$(Addr):ai")
field(DESC, "Local Converter Analog Input")
field(INP, "$(Addr).$(Param1).$(Param2).$(Param3)")
Notes: The separator must not necessarily be the dot character, could be anything. All four parameters are numerical.
Then I would like to parse the resulting string in my init_record code:
char configString[40] = {0};
recGblInitConstantLink(&record->inp, DBF_STRING, configString);
This won't work. And the documentation is very clear about that:
"Input link fields and desired output location fields can specify a constant instead of a hardware or database address. A constant, which is not really an address, can be an integer value in whatever
format (hex, decimal, etc.) or a floating-point value. "
BUT I can access that resulting string using:
record->inp.value.constantStr
Now, I have several questions I couldn't find the answers by myself:
1. Is there another way of passing several (in my case, four) numerical parameters from the record to the device support? Right now I'm accessing the string using record->inp.value.constantStr, but this feels dirty and hacky.
2. I could pack those four values into one unsigned long value, as each one of them is one byte long, but this wouldn't be recommended, would it?
3. If the INP field (when CONSTANT) is a number only (and I have tested the outputs of recGblInitConstantLink with several inputs to confirm that), what is the purpose of that constantStr field in the value union? Is it just to hold the
value before it is parsed?
4. Will I have to write new records or record supports?