Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Mon, 19 Aug 2013 16:14:20 +0000

Hi Joern,

drvUserCreate will be called once for each record.  Do you have 2 records using "28.A11BE9000000/temperature" as the drvInfo field, and 2 records using "28.AD31A3020000/temperature"?  That would explain why it is called twice for each device.

asynPortDriver was really designed to have its parameter library be defined in the constructor, i.e. you call createParam() to define all of the drvInfo strings that your driver will recognize in the constructor.  Then when device support initializes the records it finds the parameters already defined in the parameter library.

This is not what you want to do, you want to define the parameters in the parameter library at iocInit using drvInfo field from the record links.  I think this should be possible, though I have never tried it.  You would need to do the following:

- Implement drvUserCreate in your driver as you have done.

- Call this->findParam to see if the parameter has already been defined.  If it has not then call asynPortDriver->createParam().  You need to keep track of how many parameters have been defined and increment the index in the call to createParam().

- Call the base class asynPortDriver::drvUserCreate, which will assign pasyUser->reason.  You could do this in your derived method, but it's better to call the base class in case it adds additional features in the future.

- In your readFloat64 function you will do:

  int function = pasynUser->reason;
  const char *paramName;

  getParamName(function, &paramName);

paramName will now contain the string you specified in the drvInfo field, i.e. "28.A11BE9000000/temperature".

I don't know anything about the 1-wire protocol.  Is it binary or ASCII?  If it is based on "messages" then you might be able to write a generic driver that simply implements asynOctet, and then use streamDevice to define the protocols.

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Jörn Wüstenfeld
Sent: Monday, August 19, 2013 9:22 AM
To: [email protected]
Subject: asynPortDriver question

Hi,

I have some Questions concerning the asynPortDriver class. I'm currently 
trying to implement a driver, that reads via the OneWireFilesystem library 
some 1Wire devices connected via an USB adaptor.
I implemented this driver based on the asynPortDriver class. In the 
drvUserCreate function, I read the device Id and the parametername to access, 
fom the drvInfo string.
A printout in this function gives for two defined devices:

>2013/08/19 11:31:44.631 oneWireAsynPortDriver:drvUserCreate: path = 
28.A11BE9000000/temperature pasynUser = 866c28
>2013/08/19 11:31:44.632 oneWireAsynPortDriver:drvUserCreate: path = 
28.A11BE9000000/temperature pasynUser = 867038
>2013/08/19 11:31:45.793 oneWireAsynPortDriver:drvUserCreate: path = 
28.AD31A3020000/temperature pasynUser = 867b48
>2013/08/19 11:31:45.793 oneWireAsynPortDriver:drvUserCreate: path = 
28.AD31A3020000/temperature pasynUser = 867f98

With in total 4 different pasynUser structures. Why is this function called 
twice for each device? And with different asyUser structures?

How can I decide in e.g. The readFloat64 function, which device to read? The 
asynUser structure does not contain any information on the record which is 
trying to read.
What would be the correct way to handle multi device bus systems, without 
setting up a seperate driver for each device!
In principle I can dynamicaly scan the bus in the constructor and set up the 
command list, to be used in drvUserCreate as pasynUser->reason is the only way 
to tell read/write functions what to do.
BUT: It seems, that drvUserCreate is only called once during initialization 
and not for each access to device. How can I force the call of drvUserCreate 
before each call to read/write functions?
I hope that someone can give me a hint on what I'm doing wrong.

With kind regards, 
Joern

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System