External Hardware Development for File Transfer System

Question

Mr. Bruce Wayne OP

Created 2w

Replies 1

Boosts 0

Participants 2

Howdy!

I'm in the R&D phase of this project and I need help. I can't find any sources that verify what I want to do is even possible.

I need to connect an iPhone or iPad using a USB cord to an external device which will transfer files to the iPhone or iPad. I have an app already made which can organize the files and whatever else I need to do (app is from a similar project). I'll refer to this device as Alfred (for poops and giggles)

The plan (if possible) is for Alfred to recognize my app and use its documents folder as the destination of the transfer. The iDevice doesn't have to communicate with Alfred, but that would be a bonus.

I don't want Alfred to run on an SOC. My goal is to have it be as simple as possible. No OS, just firmware. If the only way to interact with Apple Devices is Bluetooth or Wifi than so be it. If Matter or Thread could be utilized I wouldn't be apposed.

Any help with this project would be greatly appreciated. Thanks in advance.

Boost

Answer 1

DTS Engineer OP

Apple

2w

I'm in the R&D phase of this project and I need help. I can't find any sources that verify what I want to do is even possible.

There are lot of options here, but the real issue is exactly what tradeoffs you want to make and the complexity of the hardware involved. Also, the difference between iOS and iPadOS is quite significant, as DriverKit on iPadOS opens up a whole other set of options. I'm going to ignore the DriverKit approach, but let me know if an iPadOS only solution is acceptable.

Next, a clarification on this point:

The plan (if possible) is for Alfred to recognize my app and use its documents folder as the destination of the transfer.

Regardless of the route you choose, your hardware's role in the "recognition" process is going to be quite limited. Every solution I'm aware of is going to involve your app "pushing" data to your accessory, not your accessory "pulling" data off the device. Related to that point, one of the major issues is simply "how does your app wake up so that it can send data to the accessory".

In any case, off the top of my head, here's the rough list:

Your app can directly access the a mass storage device through UIDocumentPickerViewController. Note that a bookmark bug means you can't reliably preserve access to a particular location, so you'd need to regularly be selecting the location through the app.
You could build an MFi licensed accessory and use the ExternalAccessory framework. This has the advantage of allowing reliable background access, however, actual bandwidth through the ExternalAccessory framework is not particularly good.
It doesn't seem to have been widely used but, in theory, it's possible to create an "ethernet" accessory. Ethernet has been fully supported by iOS for many years (iOS 8? 10??) and, in my experience, actually works quite well. Bandwidth wise, it's the highest bandwidth option other than a true mass storage device. The main issue here is how your app wakes up to communicate with it, but aside from that it could work very well. One thing to note here is that by "ethernet" I'm referring to the general wire protocol, not specifically "CAT-5". In a product I was designed around this, the USB to ethernet bridge would either be embedded in the hardware itself or implemented in the SOC software stack so, as far as the user was concerned, it would work just like any other USB accessory.

Looking at a few things other options:

Wifi. This the ethernet approach without wires. Bandwidth will be marginally lower than ethernet, but the main issue is how/why your app wakes up to communicate.
Bluetooth. The issue here is that bluetooth bandwidth is MUCH more limited than all of the options above. Unless the data involved is very, VERY small, this just isn't a reliable option. However, it does provide the opportunity to wake in the background and might be useful if you were mixing solution.
Thread. This has the same bandwidth issues as bluetooth (if not worse) and no ability to wake in the background.
Matter. This doesn't really belong on the list, as matter doesn't actually define a transfer bus (there are "Matter over WiFi" accessories). However, the other issue here is that the main reason iOT (internet of things) protocol like Matter or HAP (HomeKit Accessory Protocol) exist because they routinely exchange payloads that are MINISCULE compared to "typical" network communication. For example, most HAP over WiFi commands are in the 10 -> 100 byte (yes, that's 10 BYTES) range, despite the fact that it uses JSON for it's wire format and makes no real effort to "shrink" it's payloads. Similarly, bulk data transfer is definitely NOT what these protocols were designed for.

All that background leads to here:

I don't want Alfred to run on an SOC. My goal is to have it be as simple as possible. No OS, just firmware. If the only way to interact with Apple Devices is Bluetooth or Wifi than so be it.

The CORE issue here is what kind of hardware you're willing to use and the relevant cost. On paper, you could combine bluetooth (to wake your app app) and ethernet (for fast transport) to do on demand bulk data transfer between your app and the accessory. However, I don't know how practical that is without a pretty robust SOC and supporting hardware.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0