EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: double buffered waveformRecord
From: Michael Davidsaver <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Wed, 23 Jan 2013 10:02:41 -0500
On 1/22/2013 8:39 PM, Andrew Johnson wrote:
You can simplify it even more; use &prec->val instead of &prec->bptr as the field identifier to db_post_event() because cvt_dbaddr() doesn't need to change the paddr->pfield value at all then, it's already pointing to the val field on entry.

Ok, I'll try this.

Is this completely backwards compatible with existing waveform device support?

For "normal" use of waveformRecord by device support I think this change should have no effect. What may break are any explicit calls to db_post_event(), could would become no-op's. I haven't come across any examples of this, so I can only speculate.

I get the impression that it should be, but I haven't checked. If so even the waveform record changes would be acceptable to merge into 3.15. I would like some documentation on how to do double-buffering in device support though.

Of course.

As a start, the basic rules are

1) BPTR and the memory it is currently pointing to can only be accessed while the record is locked. 2) BPTR must always point to a piece of memory large enough to accommodate the maximum number of elements.

BTW, have you looked at the aai record type in 3.15 at all? I'm not saying it would necessarily be better than the waveform for your needs, but it is similar but with slightly different buffer semantics. Would it be sensible to make similar changes to this?

I haven't looked closely yet, but I think something very similar can be done for both aai and aao. There is no reason this feature couldn't be used to put arrays into a driver without an extra copy. My preference would be to modify all three recordtypes if feasible.


Michael


Replies:
Re: double buffered waveformRecord Michael Davidsaver
References:
double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Andrew Johnson
Re: double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Andrew Johnson
Re: double buffered waveformRecord Ralph Lange
Re: double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Andrew Johnson

Navigate by Date:
Prev: Re: double buffered waveformRecord Andrew Johnson
Next: Re: double buffered waveformRecord Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: double buffered waveformRecord Andrew Johnson
Next: Re: double buffered waveformRecord Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·