I need help. I feel like the sorcerer's apprentice. Once I've called
setInterruptReportHandlerCallback, and received all the reports I want,
how do I stop the callback?
Using the HID Utilities, Allen Ingling and I have written an extension
to MATLAB, PsychHID.mexmac, which provides MATLAB-user-level access to
HID commands. It most ways it works well, providing reliable two-way
communication with a number of HID-compliant devices, including
keyboard, mouse, and the PMD-1208FS data acquisition device. This is
very useful and we provide it free to the user community: http://psychtoolbox.org/daq.html
However, though useful, our code has a fatal flaw. To receive reports
from the PMD-1208FS we cannot use GetReport (the device rejects the
request by stalling), so we use setInterruptReportHandlerCallback
instead. setInterruptReportHandlerCallback works very well indeed while
we want it. The problem is getting rid of it when we no longer need it.
It seems that once we set up a callback using
setInterruptReportHandlerCallback, we are doomed to crash
(segmentation errors from within CF) when we try to shut down the
callback by anything short of quitting the MATLAB application. We would
like to shut down the callback when our extension is about to be
flushed from memory, or when we are notified that our device has been
unplugged. However, all our attempts to shut down the callback result
in crashes. The crashes are neither prompt nor reliable, and are thus
difficult to track down.
Fernando suggested that we destroy our "connection to the
IOHIDInterface (the callback is released in the destructor for the
IOHIDDeviceClass)." However, I think we are already doing that, without
success.
Initially, we open our connection using this:
if(!HIDHaveDeviceList())HIDBuildDeviceList(NULL, NULL);
At the end, when we are about to be flushed, we close our connection
using this:
if(HIDHaveDeviceList())HIDReleaseDeviceList();
HID_Utilities.c shows that HIDReleaseDeviceList() calls
hid_DisposeDevice(), which calls HIDCloseReleaseInterface(). I think
this is doing what Fernando suggested, but I'm not absolutely sure.
The crashes are a bit hit and miss, so it's possible that I've not
tallied them quite right. However, my impression is that we have no
problems if we never call setInterruptReportHandlerCallback. If we do
call setInterruptReportHandlerCallback, then things work perfectly,
successfully doing many elaborate communications, until we: unplug and
reinsert the device, or flush our extension and try to run it again. My
theory is that setInterruptReportHandlerCallback just won't let go.
I've pasted below the relevant bits of code, omitting the error
checking. ("error" is always zero.)
Incidentally, I don't know if it's relevant, but the PMD-1208FS is a
composite device with four interfaces. In our code, below, we treat it
as four devices, calling setInterruptReportHandlerCallback for each
interface, since the PMD-1208FS sends reports through all four.
// Enable the callback. This works fine the first time. However, if I
enable, disable (see below), and then re-enable, I don't get any
callbacks.
if(!ready[deviceIndex]){
error=(*interface)->createAsyncPort(interface,&(port[deviceIndex]));
error=(*interface)-
>createAsyncEventSource(interface,&(source[deviceIndex]));
CFRunLoopAddSource(CFRunLoopGetCurrent(),source[deviceIndex],myRunLoopMo
de);
error=(*interface)-
>setInterruptReportHandlerCallback(interface,buffer,bufferSize,ReportCal
lback,buffer,(void *)deviceIndex);
ready[deviceIndex]=1;
}
// This works fine until I disable (see below).
reason=CFRunLoopRunInMode(myRunLoopMode,0.001,false);
// Disable. This does stop the callbacks, but seems to damage things.
After this we get crashes and cannot re-enable the callback.
// Therefore, we never call this bit of code, even though it's what the
documentation seems to suggest.
#if 0
if(ready[deviceIndex]){
ready[deviceIndex]=0;
CFRunLoopSourceInvalidate(source[deviceIndex]);
source[deviceIndex]=0;
if(port[deviceIndex]!
=0)mach_port_deallocate(mach_task_self(),port[deviceIndex]);
port[deviceIndex]=0;
}
#endif
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
