I posted this same question back in April, but it was on a Friday afternoon and no-one responded - though I'm certain someone can clarify my situation for me. I'm new to device drivers in general but have found reasonable success in getting up to speed. I've hit a roadblock in my conceptual understanding and would appreciate some guidance from those "in the know."
My end goal is to have two /dev/tty.serialPort devices simultaneously accessible to userland applications.
My hardware is a single USB device with two interfaces. The first interface corresponds to a Modem (AT) "port" ( published as an IOModemSerialStreamSync ) and the second corresponds to a proprietary serial interface (published as an IORS232SerialStreamSync ).
I've tried several tactics to accomplish my end goal, but I've run into an obstacle in my most hopeful solution. My latest attempt uses a single AppleUSBCDCSampleDriver-based .kext that probes both interfaces and publishes the services separately. When the allocateResources method is invoked (from userland) I compare pointers with the port requested to determine which of the two interfaces should be opened. This has been successful in allowing me to create both /dev/tty.serialPort-001 /dev/tty.serialPort-002 "ports" and I can successfully open and communicate over either. However, when I attempt to communicate over the second "port" when the first is already open, the first "port" gets blocked (ceases to function) and the second port works properly. That is, I have two ports A and B. If I open A and then open B, A gets blocked.
My questions are:
1) As I'm using the AppleUSBCDCSampleCode as a base for this, and this is a "Device" driver (not an interface driver) is this the proper way of making both interfaces accessible?
1a) That is, given that the USBCDC Device driver matches the device (and takes control of it) should I use one .kext for both interfaces ? If using one .kext is the proper method of making both "ports" accessible, how can I keep them from blocking each other?
1b) If this is NOT the proper method, would it be possible to adapt the USBCDCSampleCode to singly match an interface and NOT act as a "Device" driver? (and have two .kexts). If have two USBCDC-based .kexts load, with each responsible for just one interface, how do I keep them from blocking each other?
4) Worst case, I believe that I could simply have the USBCDCDevice driver publish the IOModemSerialStreamSync service and access the secondary "port" directly from userland (presumably starting from Deva Example)? I'd rather not do this, but its an option, right?
Given my level of inexperience, I'm encouraged that I've been able to get this far, but I'm not confident that I can resolve this situation without some assistance. In fact, in the months since I last gave up, I've re-examined the code and reread a bunch of doc and the situation isn't any clearer.
Thanks for the help.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
