Experimental Physics and Industrial Control System
|
My definition of a synchronous device transaction is one that must be
completed without
interrupts or one that will complete faster than the overhead required
to service the
interrupt, including the context switch back to the requesting process.
John Sinclair
Heinrich du Toit wrote:
On Mon, 2007-09-10 at 17:21 -0500, Mark Rivers wrote:
Emmanuel,
I am a little confused, and cannot find a clear way to define
synchronous devices. Are PCI devices (ADC/DAC, frame grabber) all
synchronous devices? I would think so, but after all maybe not...
According to the EPICS Application Developers Guide synchronous devices
those for which the processing can be done "without waiting". This
obviously has room for interpretation, but a rule of thumb might be that
it takes no more than 1 msec or so to complete. Not all PCI devices
will fall in this category. Consider a frame grabber: if this were
implemented using the asyn Int32Array or asynOctet interface, and the
driver implemented the "read" operation as trigger a frame, wait for
acquisition to complete, and return the data, this might take 1/30
second or longer. This would definitely need to be asynchronous.
However, if the driver were constantly caching frames and just returned
the most recent one immediately, it could be synchronous. Thus, what
model to use depends on how the driver is written.
I'm not sure but I think there is a bit of confusion around the
sync/async stuff here :)
It seem that Emmanual is thinking about asynchronous/asynchronous in
terms of hardware communication method. For example you can define a
UART interface as asyn and an SPI interface as sync.
But sync/async inside ASYN driver doesn't have anything todo with the
actual hardware communication method. The option simply decides if the
ASYN processing is done in a seperate thread for each port or not.
(Hope I got that right :)
So you can use ASYN sync/asyn for any device.
But if you use ASYN sync and the processing blocks, it will block all
other ports also and all processing of records also I think.
So if processing is going to take longer than a few msecs then it is
usually better to use asyn processing :)
I hope I didn't confuse any more :D
If I did hopefully somebody can help me also.
-H
- Replies:
- Re: asyn for synchronous devices Maren Purves
- References:
- RE: asyn for synchronous devices Mark Rivers
- RE: asyn for synchronous devices Heinrich du Toit
- Navigate by Date:
- Prev:
Re: RT linux Heinrich du Toit
- Next:
Re: asyn for synchronous devices Maren Purves
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: asyn for synchronous devices Heinrich du Toit
- Next:
Re: asyn for synchronous devices Maren Purves
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 10 Nov 2011 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|