La lecture et l'écriture à l'USB (HID) interrompre les points de terminaison sur Mac

Je suis tente de communiquer avec un plutôt périphérique USB spécifique et de développer à la fois Windows et Mac code pour le faire.

Le périphérique est un périphérique USB avec une interface HID (classe 3) avec deux points d'extrémité, une entrée d'interruption et une interruption de la production. La nature de l'appareil est telle que les données sont envoyées à partir de l'appareil sur l'entrée d'extrémité seulement lorsque des données sont demandées à partir de l'hôte: l'hôte envoie des données qui le périphérique répond sur son entrée d'interruption de point de terminaison. L'obtention de données de l'appareil (l'écriture) est beaucoup plus simple...

Le code pour Windows est plutôt simple: je reçois une poignée de l'appareil, puis en appel, soit ReadFile ou WriteFile. Apparemment, une grande partie de la sous-jacentes du comportement asynchrone est une abstraction de l'extérieur. Il semble bien fonctionner.

Sur Mac, cependant, c'est un peu collante. J'ai essayé un certain nombre de choses, aucun qui ont été pleinement réussie, mais ici sont les deux choses qui semble la plus prometteuse...

1.) Tenter d'obtenir l'accès à l'appareil (USB) via IOUSBInterfaceInterface, itérer sur les systèmes d'extrémité pour déterminer l'entrée et la sortie des points de terminaison, et (espérons-le) de l'utilisation de ReadPipe et WritePipe de communiquer. Malheureusement, je suis incapable d'ouvrir l'interface une fois que je l'ai, avec la valeur de retour (kIOReturnExclusiveAccess) en notant que quelque chose a déjà l'appareil ouvert exclusivement. J'ai essayé d'utiliser IOUSBinterfaceInterface183, de sorte que je pouvais l'appeler USBInterfaceOpenSeize, mais que les résultats dans le même retourner la valeur de l'erreur.

--- mise à jour 7/30/2010 ---

Apparemment, Apple IOUSBHIDDriver correspond au début de l appareil et c'est ce qui est probablement la prévention de l'ouverture de la IOUSBInterfaceInterface. Depuis le creusement du sujet il me semble que la façon la plus courante pour prévenir la IOUSBHIDDriver à partir de la correspondance est d'écrire un code-moins kext (extension du noyau) avec une sonde de score. Cela permettrait de match au début, la prévention de la IOUSBHIDDriver de l'ouverture de l'appareil, et devrait, en théorie, permettez-moi d'ouvrir l'interface et à écrire et à lire, pour les effets directement. C'est OK, je préfèrerais ne pas avoir à installer quelque chose sur l'ordinateur de l'utilisateur. Si quelqu'un connaît une solide alternative je serais reconnaissant pour l'information.

2.) Ouvrir l'appareil comme un IOHIDDeviceInterface122 (ou plus tard). À lire, j'ai mis en place un async port, source de l'événement et de la méthode de rappel à appeler lorsque les données sont prêtes lorsque les données sont envoyées à partir de l'appareil sur l'entrée d'interruption de point de terminaison. Cependant, pour écrire les données que l'appareil a besoin — pour initialiser une réponse je ne peux pas trouver un moyen. Je suis perplexe. setReport généralement écrit pour le contrôle de l'ordinateur d'extrémité, plus j'ai besoin d'une écriture qui ne vous attendez pas à une réponse directe, pas de blocage.

J'ai regardé autour en ligne et ont essayé beaucoup de choses, mais aucun d'entre eux me donne le succès. Tous les conseils? Je ne peux pas utiliser une grande partie de l'Apple HIDManager code depuis beaucoup de qui est de 10,5+ et mon application doit fonctionner sur 10.4 ainsi.

InformationsquelleAutor Demi | 2010-07-30
  1. 31

    J'ai maintenant un travail Mac pilote pour un périphérique USB qui nécessite la communication par le biais de l'interruption des points de terminaison. Voici comment j'ai fait:

    Finalement, la méthode qui a bien fonctionné pour moi a été l'option 1 (noté ci-dessus). Comme indiqué, j'ai eu des problèmes d'ouverture de la COM-style IOUSBInterfaceInterface de l'appareil. Il est devenu évident au fil du temps que c'était dû à la HIDManager la capture de l'appareil. J'ai été incapable d'arracher le contrôle de l'appareil de l'HIDManager une fois qu'il a été capturé (même pas le USBInterfaceOpenSeize appel ou de l'USBDeviceOpenSeize appels fonctionne).

    De prendre le contrôle de l'appareil, j'avais besoin de le saisir avant que le HIDManager. La solution à ce problème est d'écrire un sans code de kext (extension du noyau). Un kext est essentiellement un module qui se trouve dans System/Library/Extensions qui contient (en général) un fichier plist (propriété de la liste) et (occasionnellement) un noyau pilote de niveau, entre autres éléments. Dans mon cas, je voulais seulement le plist, qui permettrait de donner les instructions pour le noyau par rapport à ce qu'il corresponde. Si les données donne une plus grande sonde score que le HIDManager alors je pourrais essentiellement la capture de l'appareil et de l'utilisation d'un espace utilisateur conducteur de communiquer avec elle.

    Le kext plist écrit, avec quelques détails spécifiques modifié, est comme suit:

    <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>OSBundleLibraries</key>
<dict>
<key>com.apple.iokit.IOUSBFamily</key>
<string>1.8</string>
<key>com.apple.kernel.libkern</key>
<string>6.0</string>
</dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleGetInfoString</key>
<string>Demi USB Device</string>
<key>CFBundleIdentifier</key>
<string>com.demiart.mydevice</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>Demi USB Device</string>
<key>CFBundlePackageType</key>
<string>KEXT</string>
<key>CFBundleSignature</key>
<string>????</string>
<key>CFBundleVersion</key>
<string>1.0.0</string>
<key>IOKitPersonalities</key>
<dict>
<key>Device Driver</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.apple.kernel.iokit</string>
<key>IOClass</key>
<string>IOService</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>idProduct</key>
<integer>12345</integer>
<key>idVendor</key>
<integer>67890</integer>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
</dict>
</dict>
<key>OSBundleRequired</key>
<string>Local-Root</string>
</dict>
</plist>

    La idVendor et idProduct valeurs donnent le kext de la spécificité et de l'augmentation de sa sonde score suffisamment.

    Afin d'utiliser le kext, les éléments suivants doivent être faites (dont mon installateur pour les clients):

    1. Changer le propriétaire de root:wheel (sudo chown root:wheel DemiUSBDevice.kext)
    2. Copiez le kext pour les Extensions (sudo cp DemiUSBDevice.kext /System/Library/Extensions)
    3. Appeler le kextload utilitaire pour charger le kext pour une utilisation immédiate sans redémarrer (sudo kextload -vt /System/Library/Extensions/DemiUSBDevice.kext)
    4. Toucher le dossier Extensions de sorte qu'au prochain redémarrage de la force d'un cache de reconstruire (sudo touch /System/Library/Extensions)

    À ce stade, le système devrait utiliser le kext pour garder la HIDManager à partir de la capture de mon appareil. Maintenant, que faire avec elle? Comment écrire et lire?

    Voici quelques simplifiée des extraits de mon code, moins toute erreur de manipulation, qui illustrent la solution. Avant de pouvoir faire quoi que ce soit avec l'appareil, l'application a besoin de savoir quand le dispositif d'attache (et se détache). Notez que ce n'est que pour les fins de l'illustration — certaines de ces variables sont au niveau de la classe, certains sont globales, etc. Voici le code d'initialisation qui définit l'attacher/détacher des événements jusqu':

    #include <IOKit/IOKitLib.h>
#include <IOKit/IOCFPlugIn.h>
#include <IOKit/usb/IOUSBLib.h>
#include <mach/mach.h>
#define DEMI_VENDOR_ID 12345
#define DEMI_PRODUCT_ID 67890
void DemiUSBDriver::initialize(void)
{
IOReturn                result;
Int32                   vendor_id = DEMI_VENDOR_ID;
Int32                   product_id = DEMI_PRODUCT_ID;
mach_port_t             master_port;
CFMutableDictionaryRef  matching_dict;
IONotificationPortRef   notify_port;
CFRunLoopSourceRef      run_loop_source;
//create a master port
result = IOMasterPort(bootstrap_port, &master_port);
//set up a matching dictionary for the device
matching_dict = IOServiceMatching(kIOUSBDeviceClassName);
//add matching parameters
CFDictionarySetValue(matching_dict, CFSTR(kUSBVendorID),
CFNumberCreate(kCFAllocatorDefault, kCFNumberInt32Type, &vendor_id));
CFDictionarySetValue(matching_dict, CFSTR(kUSBProductID),
CFNumberCreate(kCFAllocatorDefault, kCFNumberInt32Type, &product_id));
//create the notification port and event source
notify_port = IONotificationPortCreate(master_port);
run_loop_source = IONotificationPortGetRunLoopSource(notify_port);
CFRunLoopAddSource(CFRunLoopGetCurrent(), run_loop_source, 
kCFRunLoopDefaultMode);
//add an additional reference for a secondary event 
// - each consumes a reference...
matching_dict = (CFMutableDictionaryRef)CFRetain(matching_dict);
//add a notification callback for detach event
//NOTE: removed_iter is a io_iterator_t, declared elsewhere
result = IOServiceAddMatchingNotification(notify_port, 
kIOTerminatedNotification, matching_dict, device_detach_callback, 
NULL, &removed_iter);
//call the callback to 'arm' the notification
device_detach_callback(NULL, removed_iter);
//add a notification callback for attach event
//NOTE: added_iter is a io_iterator_t, declared elsewhere
result = IOServiceAddMatchingNotification(notify_port, 
kIOFirstMatchNotification, matching_dict, device_attach_callback, 
NULL, &g_added_iter);
if (result)
{
throw Exception("Unable to add attach notification callback.");
}
//call the callback to 'arm' the notification
device_attach_callback(NULL, added_iter);
//'pump' the run loop to handle any previously added devices
service();
}

    Il y a deux méthodes qui sont utilisés comme des callbacks dans ce code d'initialisation: device_detach_callback et device_attach_callback (tous deux déclaré à des méthodes statiques). device_detach_callback est simple:

    //implementation
void DemiUSBDevice::device_detach_callback(void* context, io_iterator_t iterator)
{
IOReturn       result;
io_service_t   obj;
while ((obj = IOIteratorNext(iterator)))
{
//close all open resources associated with this service/device...
//release the service
result = IOObjectRelease(obj);
}
}

    device_attach_callback est là que la magie se produit. Dans mon code j'ai cette répartis en plusieurs méthodes, mais ici, je vais vous le présenter comme un grand monolithique méthode...:

    void DemiUSBDevice::device_attach_callback(void * context, 
io_iterator_t iterator)
{
IOReturn                   result;
io_service_t           usb_service;
IOCFPlugInInterface**      plugin;   
HRESULT                    hres;
SInt32                     score;
UInt16                     vendor; 
UInt16                     product;
IOUSBFindInterfaceRequest  request;
io_iterator_t              intf_iterator;
io_service_t               usb_interface;
UInt8                      interface_endpoint_count = 0;
UInt8                      pipe_ref = 0xff;
UInt8                      direction;
UInt8                      number;
UInt8                      transfer_type;
UInt16                     max_packet_size;
UInt8                      interval;
CFRunLoopSourceRef         m_event_source;
CFRunLoopSourceRef         compl_event_source;
IOUSBDeviceInterface245** dev = NULL;
IOUSBInterfaceInterface245** intf = NULL;
while ((usb_service = IOIteratorNext(iterator)))
{
//create the intermediate plugin
result = IOCreatePlugInInterfaceForService(usb_service, 
kIOUSBDeviceUserClientTypeID, kIOCFPlugInInterfaceID, &plugin, 
&score);
//get the device interface
hres = (*plugin)->QueryInterface(plugin, 
CFUUIDGetUUIDBytes(kIOUSBDeviceInterfaceID245), (void**)&dev);
//release the plugin - no further need for it
IODestroyPlugInInterface(plugin);
//double check ids for correctness
result = (*dev)->GetDeviceVendor(dev, &vendor);
result = (*dev)->GetDeviceProduct(dev, &product);
if ((vendor != DEMI_VENDOR_ID) || (product != DEMI_PRODUCT_ID))
{
continue;
}
//set up interface find request
request.bInterfaceClass     = kIOUSBFindInterfaceDontCare;
request.bInterfaceSubClass  = kIOUSBFindInterfaceDontCare;
request.bInterfaceProtocol  = kIOUSBFindInterfaceDontCare;
request.bAlternateSetting   = kIOUSBFindInterfaceDontCare;
result = (*dev)->CreateInterfaceIterator(dev, &request, &intf_iterator);
while ((usb_interface = IOIteratorNext(intf_iterator)))
{
//create intermediate plugin
result = IOCreatePlugInInterfaceForService(usb_interface, 
kIOUSBInterfaceUserClientTypeID, kIOCFPlugInInterfaceID, &plugin, 
&score);
//release the usb interface - not needed
result = IOObjectRelease(usb_interface);
//get the general interface interface
hres = (*plugin)->QueryInterface(plugin, CFUUIDGetUUIDBytes(
kIOUSBInterfaceInterfaceID245), (void**)&intf);
//release the plugin interface
IODestroyPlugInInterface(plugin);
//attempt to open the interface
result = (*intf)->USBInterfaceOpen(intf);
//check that the interrupt endpoints are available on this interface
//calling 0xff invalid...
m_input_pipe = 0xff;  //UInt8, pipe from device to Mac
m_output_pipe = 0xff; //UInt8, pipe from Mac to device
result = (*intf)->GetNumEndpoints(intf, &interface_endpoint_count);
if (!result)
{
//check endpoints for direction, type, etc.
//note that pipe_ref == 0 is the control endpoint (we don't want it)
for (pipe_ref = 1; pipe_ref <= interface_endpoint_count; pipe_ref++)
{
result = (*intf)->GetPipeProperties(intf, pipe_ref, &direction,
&number, &transfer_type, &max_packet_size, &interval);
if (result)
{
break;
}
if (transfer_type == kUSBInterrupt)
{
if (direction == kUSBIn)
{
m_input_pipe = pipe_ref;
}
else if (direction == kUSBOut)
{
m_output_pipe = pipe_ref;
}
}
}
}
//set up async completion notifications
result = (*m_intf)->CreateInterfaceAsyncEventSource(m_intf, 
&compl_event_source);
CFRunLoopAddSource(CFRunLoopGetCurrent(), compl_event_source, 
kCFRunLoopDefaultMode);
break;
}
break;
}
}

    À ce point, nous devrions avoir les numéros de l'interruption des systèmes d'extrémité et ouverte IOUSBInterfaceInterface de l'appareil. Asynchrone de l'écriture de données peut être fait en appelant quelque chose comme: 

    result = (intf)->WritePipeAsync(intf, m_output_pipe, 
data, OUTPUT_DATA_BUF_SZ, device_write_completion, 
NULL);

    où les données sont un char tampon de données pour écrire, le dernier paramètre est facultatif dans le contexte de l'objet pour passer dans le rappel, et device_write_completion est une méthode statique de la forme générale suivante:

    void DemiUSBDevice::device_write_completion(void* context, 
IOReturn result, void* arg0)
{
//...
}

    de lecture à partir de l'interruption de point de terminaison est la même: 

    result = (intf)->ReadPipeAsync(intf, m_input_pipe, 
data, INPUT_DATA_BUF_SZ, device_read_completion, 
NULL);

    où device_read_completion est de la forme suivante:

    void DemiUSBDevice::device_read_completion(void* context, 
IOReturn result, void* arg0)
{
//...
}

    Noter que pour recevoir ces rappels à l'exécution de la boucle doit être en cours d'exécution (voir ce lien pour plus d'informations sur le CFRunLoop). Une façon d'y parvenir est d'appeler CFRunLoopRun() après l'appel de la async lire ou écrire des méthodes à quel point le thread principal bloque lors de l'exécution de la boucle s'exécute. Après la manipulation de votre callback, vous pouvez appeler CFRunLoopStop(CFRunLoopGetCurrent()) pour arrêter l'exécution de la boucle et de la main d'exécution au thread principal.

    Une autre solution (ce que je fais dans mon code) est de faire passer un objet de contexte (appelé "demande" dans l'exemple de code suivant) dans la WritePipeAsync/ReadPipeAsync méthodes de cet objet contient un booléen indicateur d'achèvement (appelé "is_done" dans cet exemple). Après l'appel de la lecture/écriture de la méthode, au lieu d'appeler CFRunLoopRun(), quelque chose comme ce qui suit peut être exécutée:

    while (!(request->is_done))
{
//run for 1/10 second to handle events
Boolean returnAfterSourceHandled = false;
CFTimeInterval seconds = 0.1;
CFStringRef mode = kCFRunLoopDefaultMode;
CFRunLoopRunInMode(mode, seconds, returnAfterSourceHandled);
}

    Cela a pour avantage, si vous avez d'autres threads qui utilisent l'exécution de la boucle, vous ne serez pas quitter prématurément si un autre thread arrêter l'exécution de la boucle...

    J'espère que cela est utile pour les gens. J'ai dû tirer à partir de nombreuses sources incomplets pour résoudre ce problème, ce qui exige un travail considérable pour le faire fonctionner...

    • +1. +100 Cette réponse est génial, et je suis très reconnaissant pour votre travail acharné.
    InformationsquelleAutor Demi
  2. 2

    Après la lecture de cette question à quelques reprises et y réfléchir un peu, j'ai pensé à une autre solution pour l'émulation de blocage comportement de la lecture, mais en utilisant le HID manager au lieu de la remplacer.

    Un blocage de la fonction de lecture d'enregistrer une entrée de rappel pour l'appareil, l'enregistrement de l'appareil sur l'exécution de la boucle, puis bloc en appelant CFRunLoopRun(). L'entrée de rappel pouvez ensuite copier le rapport dans une mémoire tampon partagée et appel CFRunLoopStop(), ce qui provoque CFRunLoopRun() pour retourner, ce qui déblocage read(). Ensuite, read() peut retourner le rapport de l'appelant.

    La première question à laquelle je pense est le cas où l'appareil est d'ores et déjà prévue sur une course en boucle. La planification et alors unscheduling l'appareil en fonction de lecture peut avoir des effets négatifs. Mais que serait un problème si l'application tente d'utiliser à la fois synchrone et asynchrone des appels sur le même appareil.

    La deuxième chose qui vient à l'esprit est le cas où le code d'appel a déjà de l'exécution de la boucle en cours d'exécution (le Cacao et les applications Qt par exemple). Mais, la documentation de CFRunLoopStop() semble indiquer que les appels imbriqués CFRunLoopRun() sont gérés correctement. Donc, il devrait être ok.

    Voici un peu de code simplifié pour aller avec ça. J'ai juste mis en œuvre quelque chose de semblable dans mon HID Bibliothèque et il semble fonctionner, même si je n'ai pas testé beaucoup.

    /* An IN report callback that stops its run loop when called. 
This is purely for emulating blocking behavior in the read() method */
static void input_oneshot(void*           context,
IOReturn        result,
void*           deviceRef,
IOHIDReportType type,
uint32_t        reportID,
uint8_t*        report,
CFIndex         length)
{
buffer_type *const buffer = static_cast<HID::buffer_type*>(context);
/* If the report is valid, copy it into the caller's buffer
The Report ID is prepended to the buffer so the caller can identify
the report */
if( buffer )
{
buffer->clear();    //Return an empty buffer on error
if( !result && report && deviceRef )
{
buffer->reserve(length+1);
buffer->push_back(reportID);
buffer->insert(buffer->end(), report, report+length);
}
}
CFRunLoopStop(CFRunLoopGetCurrent());
}
//Block while waiting for an IN interrupt report
bool read(buffer_type& buffer)
{
uint8_t _bufferInput[_lengthInputBuffer];
//Register a callback
IOHIDDeviceRegisterInputReportCallback(deviceRef, _bufferInput, _lengthInputBuffer, input_oneshot, &buffer);
//Schedule the device on the current run loop
IOHIDDeviceScheduleWithRunLoop(deviceRef, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode);
//Trap in the run loop until a report is received
CFRunLoopRun();
//The run loop has returned, so unschedule the device
IOHIDDeviceUnscheduleFromRunLoop(deviceRef, CFRunLoopGetCurrent(), kCFRunLoopDefaultMode);
if( buffer.size() )
return true;
return false;
}
    InformationsquelleAutor Brandon Fosdick
  3. 2

    Je suis tombé sur cette même kIOReturnExclusiveAccess. Au lieu de la combattre (la construction d'un kext, etc). J'ai trouvé l'appareil et utilisé l'api POSIX est.

    //My funcation was named differently, but I'm using this for continuity..
void DemiUSBDevice::device_attach_callback(void * context, 
io_iterator_t iterator)
{
DeviceManager *deviceManager = (__bridge DADeviceManager *)context;
io_registry_entry_t device;
while ((device = IOIteratorNext(iterator))) {
CFTypeRef prop;
prop = IORegistryEntrySearchCFProperty(device,
kIOServicePlane,
CFSTR(kIODialinDeviceKey),
kCFAllocatorDefault,
kIORegistryIterateRecursively);
if(prop){
deviceManager->devPath = (__bridge NSString *)prop;
[deviceManager performSelector:@selector(openDevice)];
}
}
}

    une fois devPath est défini, vous pouvez appeler d'ouvrir et de lire/écrire..

    int dfd;
dfd = open([devPath UTF8String], O_RDWR | O_NOCTTY | O_NDELAY);
if (dfd == -1) {
//Could not open the port.
NSLog(@"open_port: Unable to open %@", devPath);
return;
} else {
fcntl(fd, F_SETFL, 0);
}
    • travaillez-vous avec un périphérique hid?
    InformationsquelleAutor estobbart