At WWDC 2019, Apple announced a new driver architecture. More and more types of drivers are supposed to run in userspace instead of in the kernel. Among the first affected drivers types – according to the announcement – are USB-to-serial drivers.
This type of drivers is supposed to be implemented using the USBSerialDriverKit, and Apple published early documentation for it. However, the pages have disappeared. There are still indexed in Google, e.g.: https://developer.apple.com/documentation/usbserialdriverkit. But they all lead to a 404. Related driver kits, e.g. USBDriverKit, are still online.
Why have the documentation and most likely also the related APIs disappeared – both from the web site as well as from macOS Catalina beta 3? Will they still be part of the final macOS Catalina?
No reason was ever given why it disappeared. I guess it just wasn't ready yet.
Anyhow, it has reappeared with macOS Catalina 10.15.4 or 10.15.5.
I'm not sure how relevant it is for third parties. There is a limited number of USB-to-Serial chips available and many are already covered:
USB CDC ACM: The official USB standard for USB-to-serial communication. Driver provided by Apple out of the box. If you have any control over the hardware, this should be your preferred solution as it works on all modern operating systems without further driver installation. This is the protocol usually implemented when the USB-to-serial conversion is implemented in software (in a MCU with a USB peripheral).
FTDI chips (such as FT232x, FT2232, FT4232): Popular chip for USB-to-serial conversion. Chinese clones exist as well. Driver is provided by Apple out-of-the-box.
Silicon Labs CP210x chips: Popular chip for USB-to-serial conversion. Driver is provided by Apple out-of-the-box.
WCH CH34xx chips: Popular chip for USB-to-serial conversion from the Chinese manufacturer WCH. Driver is provided by Apple out-of-the-box.
Prolific PL230x chips: Chips for USB-to-serial conversion from a Taiwanese manufacturer. No user-space driver available yet.
So the Prolific driver is the only one missing. With the up-coming Apple Silicon based Macs, they will probably have pressure to deliver it by the end of 2020. Looking forward to it.
Related
There was a discussion here that is now closed: https://stackoverflow.com/questions/25871579/what-is-the-difference-between-rtos-and-embedded-linux#:~:text=Many%20RTOS%20are%20not%20full,essentially%20the%20scheduling%20kernel%20only.&text=Critically%20Linux%20is%20not%20real%2Dtime%20capable
The accepted answer could be summarised as "Critically Linux is not real-time capable".
However, I think this is misleading. When it comes to an OS like linux, you have to distinguish between applications, the kernel, and device drivers.
According to my understanding (having written many Unix device drivers and worked on the Unix kernel decades ago), the device drivers and the kernel are real-time capable.
Device drivers respond to hardware events (interrupts) and the kernel, in turn, can perform actions based on these events.
So, yes, while it's true that certain real-time features are not available to applications, if you have the capability of writing a device driver, you can circumvent this limitation by moving your application logic into a specialised device driver or kernel module.
(Of course it has to make logical sense to do that...)
Have I missed something? Does anyone disagree with this?
Where are the step-by-step instructions to write a generic driver to a USB-connected developer board for MacOS using IOKit/DriverKit (publicly shown in WWDC 2019) in Xcode?
The only documentation I'm aware of is:
DriverKit reference
WWDC 2019 Session 702
The DriverKit version of IOKit is intended to have a similar API to the in-kernel IOKit, so I guess they expect you to be familiar with that.
Note that in many cases when writing drivers for USB devices, you don't need to use either DriverKit or a kext, and instead can use the userspace IOUSB libraries directly. You only really need to use DriverKit or a kext if the kernel is the consumer of your driver. You haven't said what your driver will do, so I can't say which is best in your case. DriverKit is still extremely limited, so unless you want to write a HID or serial port driver, there are few reasons to choose it at the moment.
We develop applications using ble beacons. One of the beacons providers offering beacons with MiniBeacon firmware. I guess MiniBeacon firmware makes it possible to configure the beacon in iBeacon and Eddystone format simultaneously. Is it correct ?
I searched but could not find much information about MiniBeacon firmware. Does it have any known compatibility issues with Eddystone or iBeacon format or any known performance issues ?
Sorry for asking such a generic question. Thanks a lot.
Reg,
It does not look to me like the firmware supports Eddystone, at least not at the link referenced in the comment below the question. That firmware is 3 or 4 years old by the changelog, dating to before the release of Eddystone.
The README mentions iBeacon compatibility, and if that format is indeed supported, it would be compatible with the Android Beacon Library if the library is configured with the proper BeaconParser for iBeacon.
You may wish to check with the firmware author to see if a newer version is available supporting Eddystone.
Can I use Serial Port Profile (SPP) to communicate with iOS devices over Bluetooth Low Energy (v4.0) without the need for MFi Chip?
If you're designing something from scratch (rather than trying to interface to an existing SPP-enabled device), there is a possible solution.
Laird Technologies make a Bluetooth Low Energy Module (BL600), which can be loaded with a virtual serial port application. This creates a service which is similar to the SPP; at the remote end it can just be treated as a plain serial port (albeit rather low speed). You could roll your own service to do something similar on other devices.
It's not the most elegant solution, but seems to work okay, and far easier than trying to get MFi certification.
If you cannot control the peripheral's protocol choice:
The Serial Port Profile (SPP) is still supported by Bluetooth 4.0. However, Bluetooth 4.0 Low Energy uses different pysical and link layer protocols that are not backwards compatible with older Bluetooth standards. Current iOS and Android devices use "dual mode" interfaces that support the backward compatible part of BT 4.0 and the Low Energy standard.
Bluetooth 4.0 Low Energy does not support SPP whereas regular Bluetooth 4.0 does!
I found a Cordova/Phonegap Plugin on GitHub that might serve as a source of inspiration for you. They advertise to support SPP on iOS and Android alike.
If you are in control of the peripheral, i.e. you implement the peripheral's software:
Bluetooth 4.0 Low Energy communication makes use of the Generic ATTribute Protocol. Based on GATT there exist a number of profiles but no serial port profile.
The good news is that implementing your own proprietary serial port profile on iOS, Android and your device is fairly simple. The API instructions for your BTLE module/SoC should provide some examples for existing profiles.
As soon as you see how simple implementing your own profile is, you will probably choose to go for a more use case specific profile which will save you lots of power on your (battery powered?) peripheral.
Just to clear up John Parsons comment from Feb 16th - the BL600 is definitely not discontinued whatsoever.
vSP works well for a low level, low throughput data connectivity using BLE for iOS devices, as well as Android. Video showing the solution working to an iPad are at this link and full source code is available for the iOS application as well http://www.lairdtech.com/Support-Center/Technical-Library/Videos/VSP-Bridge-Command/#.UwYvzGJ_s1w
There are no MFi requirements for BLE connectivity on iOS.
MFi is only relevant to Classic Bluetooth data connections to / from iOS devices, where you need to use Apple's iAP protocol, be a MFi licensee, use an external Apple Authentication IC and pay a royalty to Apple.
NO,you can't. BLE not support SPP.
No, you can't. In general, it's important to remember that any Bluetooth Classic profile isn't necessarily applicable for Bluetooth Low Energy. With BLE however, you can easily create your own custom service/profile, specially tailored towards your particular application. As far as I know, all BLE communication with iOS is currently allowed without participating in the MFi. You can also take a look at this page for further information on SPP and BLE.
I'm searching for SPP for iOS myself and found a German supplier, lintech.de, that has products for "Bluetooth meets Apple" claiming to support/emulate SSP, apparently using their own embedded software layer combined with iAP. "BlueMFI software communicate with APPLE devices using the iAP (iPod Accessory Protocol) and manage the data communication with the Apple authentication chip...BlueMFI software is designed to run on a variety of hardware platforms (Bluetooth modules), and interested users can obtain the relevant evaluation kits. LinTech’s Bluetooth modules with BlueMFI software not only support the APPLE iAP protocol via Bluetooth, but they are also able to communicate with standard Bluetooth devices." Haven't tried this yet, just exploring and sharing.
I won't say SPP is directly supported under iOS 7, Apple says no. Won't argue :)
But...
I use connectblue modules OBS421 and OBS425 on a data collection project.
BLE modules have SPP profile enabled and I transmit data from my sensors to the iOS devices using BTLE module in SPP mode.
Works pretty fine under iOS 6 and 7
That said, I was having trouble with MFi bluetooth devices under iPhone 5S, that's why I moved to BTLE.
Drawback with BTLE, it's limited to 20 bytes at a time.
I had to adjust hardware and software, but was easy.
You have programmable chips such as Bluegiga BL112 that are doing the job. It is the cable replacement code.
I'm integrating it actually for both iOS and Android 4.3. It works at least on the demo board.
I'm looking at developing a device which will need to support Ethernet over USB (hosted in Linux, XP, and Vista). As I understand it, Vista and Linux support the industry standard USB CDC. However, in classic Windows style, XP only supports it's own Remote NDIS. So, now I'm thinking of just bowing down and doing it over RNDIS, as opposed to rolling my own CDC driver for XP.
I've been reading some older documentation that says even XP is pretty buggy with NDIS (suprise!). Does anyone have experience with XP's RNDIS drivers? Are they safe for product development? Any insight would be much appreciated.
We use RNDIS at work. and I've found that it blue screens my machine every now and again (about every month or two). However others (at my work) have not had this happen, so it could just be the particular device that I use.
I think it is stable enough for development, so give it a go.
The problem here is that Linux does not support RNDIS in the host mode, and you can't develop custom driver due to MS RNDIS license restrictions. MAC does not support RNDIS as well due to same reason (licensing).
So if you need multiplatform solution you need a standard approach which is CDC/ECM.
There is number of available CDC/ECM XP/VIsta solutions in the market,you can google for them i don't want to advertise our solution here :)
After doing my own research and testing, a single NDIS device works reasonably well. However, if you are at all needing to support multiple NDIS devices, you are out of luck. My system became extremely unstable and was essentially unusable. This was very reproducible.
I would not recommend NDIS in any type of multiple-device scenario.
if you are looking for commercial solution, Jungo does provide decent ECM solutions works for Windows/Linux/Mac. The only problem is that you have to pay them non-trivial royalty fee if you are going for a mass volume product.