Difference between revisions of "How To Write Device Support that uses Asyn Driver"
m |
|||
| Line 3: | Line 3: | ||
Writing software that calls Asyn is confusing until you understand the approach you need to take. There are very good reasons behind the design of Asyn which is intended to simplify the work of writing robust, portable code, but this does result in the need to learn the Asyn approach. Once you understand the choices that Asyn has made though, writing the software is actually simpler than it would be without asyn. | Writing software that calls Asyn is confusing until you understand the approach you need to take. There are very good reasons behind the design of Asyn which is intended to simplify the work of writing robust, portable code, but this does result in the need to learn the Asyn approach. Once you understand the choices that Asyn has made though, writing the software is actually simpler than it would be without asyn. | ||
This document assumes that you're writing an EPICS Device Support layer for a moderately complicated instrument or device that interfaces through an RS232 or similar serial port, and hence you need to use the '''asynOctet''' generic serial interface. If you're wanting to use some other Asyn interface then the techniques discussed here should still apply, but some of the specific code will need to change. If the device you're controlling is simple you may be better off using the | This document assumes that you're writing an EPICS Device Support layer for a moderately complicated instrument or device that interfaces through an RS232 or similar serial port, and hence you need to use the '''asynOctet''' generic serial interface. If you're wanting to use some other Asyn interface then the techniques discussed here should still apply, but some of the specific code will need to change. If the device you're controlling is simple you may be better off using the [http://www.aps.anl.gov/epics/modules/soft/asyn/R4-2-1/HowToDoSerial/tutorial.html devGpib interface layer] (which also works with serial devices now that it's been converted to use Asyn). If it's available the Streams serial device layer from Dirk Zimoch may be even better, as it will be able to send and parse many typical serial message formats without your having to write any C code at all. | ||
== Getting Started == | == Getting Started == | ||
Revision as of 18:05, 15 April 2005
Introduction
Writing software that calls Asyn is confusing until you understand the approach you need to take. There are very good reasons behind the design of Asyn which is intended to simplify the work of writing robust, portable code, but this does result in the need to learn the Asyn approach. Once you understand the choices that Asyn has made though, writing the software is actually simpler than it would be without asyn.
This document assumes that you're writing an EPICS Device Support layer for a moderately complicated instrument or device that interfaces through an RS232 or similar serial port, and hence you need to use the asynOctet generic serial interface. If you're wanting to use some other Asyn interface then the techniques discussed here should still apply, but some of the specific code will need to change. If the device you're controlling is simple you may be better off using the devGpib interface layer (which also works with serial devices now that it's been converted to use Asyn). If it's available the Streams serial device layer from Dirk Zimoch may be even better, as it will be able to send and parse many typical serial message formats without your having to write any C code at all.
Getting Started
First, you will need to write the code for a basic device support layer. I won't cover the details of that here but will assume that you are familiar with the device support interface.
This document is not yet complete...
--AndrewJohnson 13:03, 15 Apr 2005 (CDT)
