Re: record/device support general style question

[Marty Kraimer <mrk@aps.anl.gov>]

The release notes for R4-3 state:

lockPort/unlockPort

These are new asynManager methods. They can be used in place of 
queueRequest if the caller can block. They have been added to make it 
easier to implement a driver with one addressing scheme that is a 
asynUser of a driver with a different addressing scheme. For example a 
multi-drop serial driver can be implemented that calls a standard serial 
driver.

One use is for what your are describing.

I have not done the following so the ideas may need some refinement.

There are two ports involved:

serialPort - standard serial support that comes with asyn, i.e. serial 
or ethernet
specialPort - The support for your device, e.g. loCuM4.

A stringin recort will be connected to serialPort using 
asynSiOctetCmdResponse or asynSiOctetWriteRead device support, i.e. it 
uses standard asyn devEpics support.

ai, bi, mbbi, records will; be attached via  standard asyn devEpics 
support to specialPort.


The following will happen.

The stringin record can be processed periodically. Each time it is 
processed the following happens:

a command is sent to the the serial port and the response read.
specialPort will be called because it has registered via 
asynOctet:registerInterruptUser.
It breaks the response into individual data items and causes the 
associated ai,bi,mbbi,etc records to process because they have been set 
to be I/O Intr scanned.

So what does the specialPort have to do to make this happen?

It appears as a multi address driver to the records that attach to it.
It is an asynUser of the serialPort.

At initialization it connects to the serial port, locates the asynOctet 
interface and calls asynOctet:registerInterruptUser.

It implements interfaces asynInt32 and asynUInt32Digital.

Please note also that you can use asynDrvUser to pass driver specific 
info from the INP and OUT links to the driver.


Hope this helps you get started.

Marty


Jens Rekow wrote:

> Hi All,
>
> it is rather an architectural/style question that I ran into working on
> the device support for a message based serial/ethernet device (yes, it is
> the LoCuM4).
> Imagine there is a command that retrieves various status values binary
> encoded in a string (bytes, shifted to printable characters...). I would
> like to serve several PV's out of that. (It wouldn't make sense to put so
> much information in just one record, mbbi, whatsoever)!
>
> As always there are different ways to deal with that:
> Worst case that I can think of is to have AsynDriver device support for
> each record, so EACH time ONE of them is processed there would be I/O
> transaction at the interface for retrieving the whole status string and
> the tiny bit (literally!) of interest will be extracted.
>
> My way so far is another: There is one AsynDriver-powered record
> (stringin) which retrieves and holds the status string. That value is read
> by a longin record via dbGetField() in a standard device support, which
> extracts the information and distributes to all the other relevant records
> via dbPutField(). Thus these other records don't need any device/record
> support implementation themselves but are set remotely. Unfortunately this
> complicates handling the alarm/invalid states of these records.
>
> So the question is:
> Would it be better to have already my AsynDriver-powered record, which
> reads the status bytes, distributing the values to the different records
> via dbPutField()?
> Alternatively I like the idea of only one device support implementation
> for several records which is flexible using the INP field as a
> parameter...
>
>
> Any suggestions?
> What could be more 'stylish'?
>
> Thanks in advance,
> Jens
>
>