[iPadOS / USBDriverKit] Communicating with RP2040: Avoiding OS preemption of standard CDC-ACM?

Question

Created 1d

Replies 1

Boosts 0

Participants 2

Hello everyone,

I am currently working on an iPadOS application that requires communicating with a custom hardware board based on the Raspberry Pi RP2040 microcontroller via USB.

My initial thought was to use the standard CDC-ACM (virtual serial port) profile on the RP2040. However, my understanding is that iPadOS's built-in system drivers will automatically claim any standard CDC-ACM interfaces, preempting my custom USBDriverKit driver from matching and taking control of the device.

Is my assumption correct that iPadOS will strictly preempt a standard CDC-ACM device, making a custom DriverKit implementation impossible for that specific class?

Answered by DTS Engineer in 887662022

Is my assumption correct that iPadOS will strictly preempt a standard CDC-ACM device, making a custom DriverKit implementation impossible for that specific class?

No, your assumption is incorrect though that may not change your larger conclusion. In terms of general USB DriverKit matching, your driver can basically match against "anything". There are some edge cases around things like that boot process, but none of that really applies to a serial device like yours. Similarly, it's certainly possible/likely that the system does have a built-in driver that matches your driver, but IOKit matching is sufficiently powerful that you can override the system’s match.

HOWEVER… that doesn't necessarily mean you want to do what you're describing here:

My initial thought was to use the standard CDC-ACM (virtual serial port) profile on the RP2040.

The problem here is that the main reason to choose this approach is that it's "easy" to implement, since user-space serial port communication. However, the problem on here is that none of those user-space APIs are available to you. So, implementing what you're describing requires you to implement:

A DEXT that implements serial communication using "raw" USB commands.
A user client in that DEXT to transfer data out of the DEXT.
Your app reading data in/out of the user client to handle actual communication.

It's certainly possible to do all that, but the work involved is quite significant, far more than simply opening a serial port.

That actually leads me back to here:

I am currently working on an iPadOS application that requires communicating with a custom hardware board based on the Raspberry Pi RP2040 microcontroller via USB.

What are you actually trying to do here? And how flexible is your hardware design?

The suggestion I've made in a few different places is to use "ethernet" as the logical transport bus, not "USB". Done properly, that would let you support iPhones as well as iPads with plenty of communication bandwidth to do "whatever" you wanted to do. Note that this DOESN'T mean "plug your Raspberry Pi into ethernet"- your physical connection can still be over USB, even if that's not what our system "sees". This post has a more detailed description of what I mean by that.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Boost

Answer 1

DTS Engineer OP

Apple

19h

Recommended

Is my assumption correct that iPadOS will strictly preempt a standard CDC-ACM device, making a custom DriverKit implementation impossible for that specific class?

No, your assumption is incorrect though that may not change your larger conclusion. In terms of general USB DriverKit matching, your driver can basically match against "anything". There are some edge cases around things like that boot process, but none of that really applies to a serial device like yours. Similarly, it's certainly possible/likely that the system does have a built-in driver that matches your driver, but IOKit matching is sufficiently powerful that you can override the system’s match.

HOWEVER… that doesn't necessarily mean you want to do what you're describing here:

My initial thought was to use the standard CDC-ACM (virtual serial port) profile on the RP2040.

The problem here is that the main reason to choose this approach is that it's "easy" to implement, since user-space serial port communication. However, the problem on here is that none of those user-space APIs are available to you. So, implementing what you're describing requires you to implement:

A DEXT that implements serial communication using "raw" USB commands.
A user client in that DEXT to transfer data out of the DEXT.
Your app reading data in/out of the user client to handle actual communication.

It's certainly possible to do all that, but the work involved is quite significant, far more than simply opening a serial port.

That actually leads me back to here:

I am currently working on an iPadOS application that requires communicating with a custom hardware board based on the Raspberry Pi RP2040 microcontroller via USB.

What are you actually trying to do here? And how flexible is your hardware design?

The suggestion I've made in a few different places is to use "ethernet" as the logical transport bus, not "USB". Done properly, that would let you support iPhones as well as iPads with plenty of communication bandwidth to do "whatever" you wanted to do. Note that this DOESN'T mean "plug your Raspberry Pi into ethernet"- your physical connection can still be over USB, even if that's not what our system "sees". This post has a more detailed description of what I mean by that.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0