David Gravereaux wrote:
On 03/18/2013 10:34 PM, Chuck Harris wrote:
It's not like you won't have to be doing some polling
somewhere in your GPIB software no matter what the board.
Not one bit. An example to a DM5010 to setup async reading of measures:
-> ACV; RQS ON; MODE RUN
You can believe that if you want, but your OS knows the truth.
now when SRQ is raised with a status byte from it of 132 returned from
the serial poll, I call ibrd() then go back to WaitSRQ() and repeat for
each measurement taken.
I'm not ever asking if it is ready, it tells me.
The throughput is blazing and made a world of difference using the same
technique with my AA5001 for doing 3-D plots of freq/level/thd when the
number of points taken are quite high.
Also helps tremendously using this method when your count of involved
devices on your buss is high and you're interacting with all of them for
large test suites.
PS. the I/O model isn't USB, it's being emulated as a serial device
which is fine as it stands except for the application layer of the
prologix communication which forces you into command/response.
Actually it is. Standard USB devices cannot interrupt anything. They
are slaves in a master slave relationship. Unless the master asks, the
slave stays mum.
It may seem like your USB port interrupts the OS when you stick a thumb
drive, etc... into the jack, but that is only because the OS is polling
the USB ports until if finds one that talks back.
-Chuck Harris
