Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 6 Jan 2017 22:46:53 +0000

Hi Konrad,

What you outline basically sounds like the right approach.

You may not even need to set ASYN_CANBLOCK, although it won't hurt.  That is used to indicate that a call from device support to the driver can take a "long time" (> 1 ms?).  In your case simple register writes will be very fast, and even the firmware update call from device support will be fast, since it just starts a thread doing the slow work.

> I guess I need to acquire and release some lock for each write operation to ensure these commands do not get
> mixed up with communication initiated by other records. Would the asynPortDriver::lock/unlock methods be the right way to handle this?

Yes, that is the lock you should use.

> Can you point me to drivers that I could use as an example?

Many of the areaDetector drivers use this approach.  In that case it is slow input (i.e. read an image) rather than slow output, but the concepts and implementation are identical.

You can look at the AndorCCD::dataTask function in areaDetector/ADAndor/andorApp/src/andorCCD.cpp.  It takes the lock when it needs it and releases the lock when doing slow operations that don't need the lock.

Mark

-----Original Message-----
From: Konrad, Martin [mailto:[email protected]] 
Sent: Friday, January 06, 2017 4:31 PM
To: EPICS Tech Talk; Mark Rivers
Subject: Asyn: example driver for slow device?

Hi Mark,
I am intending to implement a driver for an FPGA-based device based on
asynPortDriver. One of the features my IOC should support is
reading/writing FPGA firmware from/to the device using waveform records.
My device supports reading/writing the firmware in small blocks.
Reading/writing a single block doesn't take too long but writing the
whole image can take a few minutes.

Here is what I have in mind:

- Set ASYN_CANBLOCK

1. Client reads firmware image from file, caputs it to the waveform record.
2. Asyn calls writeInt8Array in my driver which copies the data,
notifies the waveform-writer thread and returns. This releases the Asyn
lock and ensures other records can communicate with the device.
3. The waveform-writer thread iterates over the image and writes it
block-by-block in the background. I guess I need to acquire and release
some lock for each write operation to ensure these commands do not get
mixed up with communication initiated by other records. Would the
asynPortDriver::lock/unlock methods be the right way to handle this?
4. Once the waveform-writer thread is done it calls back Asyn to report
completion.

- For writes to simple registers the write function writes the data
immediately and calls Asyn to report completion.

Is this the right approach? Can you point me to drivers that I could use
as an example?

Thanks a lot,

Martin

-- 
Martin Konrad
Control System Engineer
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824-1321, USA
Tel. 517-908-7253
Email: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System