FTDI Community
General Category => Discussion - Drivers => Topic started by: kalle on September 10, 2020, 12:20:41 PM
-
The current VCP driver can't be installed on macOS 11 beta 6 as Apple seems to consider it a "legacy system extension" (https://support.apple.com/en-us/HT210999). Is there any plans to provide a driver that works on macOS 11?
-
Hello,
We are currently working on a .dext version of the driver to be compatible with the newer versions of macOS.
However in macOS 10 Apple distributed a VCP driver built into the OS which works for all standard FTDI devices, this was called AppleUSBFTDI.kext pre-Catalina and AppleUSBFTDI.dext in Catalina. I haven’t had a chance to look at macOS 11 yet, but I believe the inbuilt apple driver should still be included.
Best Regards,
FTDI Community
-
I use two (2) devices with a FTDI chip. An RT Systems USB-62C cable and a Microham USB Interface III.
The RT Systems USB-62C cable works fine with the built-in .dext in macOS 11 Big Sur Beta 6. The Microham USB Interface III doesn't.
-
Hello,
I am unfamiliar with the Microham USB Interface III, could you share its details from the hardware monitor similar to the attached screenshot?
Best Regards,
FTDI Community
-
Here it is (in macOS Catalina):
(https://www.imgdumper.nl/uploads9/5f5fa0dcdc05e/5f5fa0dcd91ee-Schermafbeelding_2020-09-14_om_18.54.34.jpg)
in macOS 11 Big Sur:
(https://www.imgdumper.nl/uploads9/5f5fa36177059/5f5fa3616da6a-Schermafbeelding_2020-09-14_om_19.04.59.png)
-
Hello,
I see that your device is using the Product ID (PID): 0xEEEF with our default FTDI Vendor ID (VID): 0x0403.
This VID/PID combination is included in our VCP driver (FTDIUSBSerialDriver.kext), however it is not included in the inbuilt Apple VCP driver (AppleUSBTDI.dext).
Unfortunately at this time we do not have a .dext version driver available for macOS 11 Big Sur, but we hope to have this available shortly.
Best Regards,
FTDI Community
-
Hi there, we are also looking forward to the .dext driver version.
We have a few products using the default FTDI vendor ID with our own PID (granted by FTDI some years back). Will our VID/PID combination also work in the upcoming .dext driver?
Thanks
-
Hello,
We have a few products using the default FTDI vendor ID with our own PID (granted by FTDI some years back). Will our VID/PID combination also work in the upcoming .dext driver?
If your VID/PID combination is currently included in our macOS VCP driver's Info.plist file then yes it will be included in the .dext version of the driver.
Best Regards,
FTDI Community
-
Big Sur is officially being released today, and there is still no VCP driver available. We have thousands of customers out there with FTDI devices that use a custom VID/PID who are inevitably going to be updating to Big Sur, rendering our equipment completely unusable.
I know FTDI has been working on an update for Big Sur for a while, but can we get a timeline for when it will actually be available? I'll be happy to test a beta version if you have it ready now...
-
Hello,
I have chased the development team up for a relapse schedule for the new .dext driver.
When a beta is available I will post this for community user testing.
Best Regards,
FTDI Community
-
Any updates?
Thanks,
Jeff
-
It is now 5 months since the first developer beta of Big Sur, why is there still no updated driver? Can there be at least an update on how far along it is, 10%? 90%?
-
Hello
It is now 5 months since the first developer beta of Big Sur, why is there still no updated driver? Can there be at least an update on how far along it is, 10%? 90%?
Are you using a device with a non default VID/PID combination?
As far as I am aware our developers are still waiting on Apple clarifying some questions on .dext development. Unfortunately I do not have an updated schedule for release at this point. But this is a top priority for us and I will update when I have any new information.
Best Regards,
FTDI Community
-
Thanks for the reply.
I'm using a FT2232HL, and the Apple driver returns "SetTTY (fd 5): ioctl failed: Invalid argument" when trying to use channel 0 with screen, and a similar error through Python:
File "/Users/user/.espressif/python_env/idf4.2_py3.9_env/lib/python3.9/site-packages/serial/serialposix.py", line 272, in open
self._reconfigure_port(force_update=True)
File "/Users/user/.espressif/python_env/idf4.2_py3.9_env/lib/python3.9/site-packages/serial/serialposix.py", line 435, in _reconfigure_port
termios.tcsetattr(
termios.error: (22, 'Invalid argument')
Strangely, trying to use channel 1 sometimes doesn't report an error though I can't test whether serial actually works as its pins aren't exposed appropriately on this board - they're usually for JTAG.
Another reason I need the FTDI drivers too is so that I can edit the Info.plist and prevent the serial driver from being loaded on the JTAG channel. A workaround before was to unload the Apple (and FTDI) driver, start the debugger and load the driver - which prevents the driver enumerating the JTAG channel. Loading and unloading the Apple dext seems to be unreliable at best right now, and even then it doesn't help with the ioctl error.
-
Hello,
Thanks for the details.
Just to confirm you are seeing this error only on big sur with the inbuilt apple driver?
Best Regards,
FTDI Community
-
FYI also to this thread: I've tried to ask in Apple forums whether it would be possible to somehow utilize Apple's dext driver for FTDI devices with custom PID, but haven't got any answers... :(
https://developer.apple.com/forums/thread/659891 (https://developer.apple.com/forums/thread/659891)
-
Hi,
we are in a similar situation here, we currently use libftd2xx.dylib with our VID/PID. Do you plan to release a libftd2xx.dext?
Best Regards,
Daniele
Hello
It is now 5 months since the first developer beta of Big Sur, why is there still no updated driver? Can there be at least an update on how far along it is, 10%? 90%?
Are you using a device with a non default VID/PID combination?
As far as I am aware our developers are still waiting on Apple clarifying some questions on .dext development. Unfortunately I do not have an updated schedule for release at this point. But this is a top priority for us and I will update when I have any new information.
Best Regards,
FTDI Community
-
Hello,
The D2XX driver is a dynamic library file on macOS and is not related to the kernel/driver extension migration currently happening with the VCP driver.
What issues are you seeing with the D2XX driver?
Hi,
we are in a similar situation here, we currently use libftd2xx.dylib with our VID/PID. Do you plan to release a libftd2xx.dext?
Best Regards,
Daniele
Best Regards,
FTDI Community
-
You are right, my mistake.
I do not want to hijack this thread, but the question is if the libftd2xx.dylib can run under Apple ARM architecture. As far as I know the current 1.4.4 dylib has only x86_64 support.
Best Regards,
Daniele
-
Hello,
My understanding is that the Rosetta 2 binary translator will allow for x86_64 libraries and applications to run on the new Apple M1 processors with minimal performance loss. But I will raise this with the developers and see if they can clarify.
We of course intend to rebuild the libftd2xx.dylib for the ARM platform, but we are currently concentrating on the VCP .dext transition.
Best Regards,
FTDI Community
-
Hello,
Thanks for the details.
Just to confirm you are seeing this error only on big sur with the inbuilt apple driver?
Best Regards,
FTDI Community
Yes, I can't load the FTDI driver at all.
I reinstalled Big Sur and initially it worked, but it has broken again. I think it may have something to do with VMWare Fusion, as it seemed to break when that was running. However I have since deleted all traces of Fusion (including kexts) and the problem persists.
The attachment shows the message that it has loaded the driver but then trying to access the serial ports with screen again shows SetTTY (fd 5): ioctl failed: Invalid argument.
Quite often attaching the FT2232 results in an enumeration error shown in the second attachment. Does Apple write their driver independently of yourselves? If so, i'll submit a big report to them.
Thanks.
-
FYI also to this thread: I've tried to ask in Apple forums whether it would be possible to somehow utilize Apple's dext driver for FTDI devices with custom PID, but haven't got any answers... :(
https://developer.apple.com/forums/thread/659891 (https://developer.apple.com/forums/thread/659891)
I'm pretty sure I read somewhere you can subclass the Apple driver with a VIP/PID of your own and the Apple driver will load. I can't help you with exactly how though I'm afraid!
-
Hello,
Yes that is correct, Apple develop their VCP driver independently from our VCP driver.
Best Regards,
FTDI Community
-
Hi All,
Hardware producer using ft232RL in our products here. we are getting more and more reports of people unable to use their devices after upgrading to Big Sur.
-amount of chips used: about 1k.
-location of devices: worldwide.
question: for what type of devices is the new driver from apple enabled? any specific product ID? we are using 0403:6001
would it be an idea that you as ftdichip aks apple to open up their driver?
It looks kinda unprofessional to me that a third party has a driver earlier than the producer of the chip
Is there anything i can do to help? I'm loosing customers!
-
Hello,
The inbuilt apple driver (AppleUSBFTDI.dext) should work with any default FTDI VID/PID combination.
The FT232R default VID is 0x0403 and its PID is 0x6001, this definition is included in the Info.plist file for the AppleUSBFTDI.dext.
On macOS 10.15 we had noticed that a Wacom Tablet driver was preventing both our VCP driver and apples VCP driver from attaching to devices and providing a COM port in the '/dev' folder. This may still be the case for some of your customers on Big Sur, however it could be an issue with the Apple driver itself.
I will contact the driver development team to see if they can request Apple to open up their driver, however I cannot guarantee this will be possible.
Best Regards,
FTDI Community
-
good point.
Another thing i was thinking about: what happens with the old kext if the system is updated from lets say 10.15 to 11.0? is it completely disabled and ignored, or somehow still claiming things it shouldn't. we had problems with that earlier when 10.15 came out.
Unfortunately I am not able to play around with mac os 11.0 Big Sur as I am completely linux based (besides a small virtual windows box to flash the FT232R.)
-
Hello,
The .kext version of the VCP driver will not load on macOS 11 and shouldn't be inadvertently claiming devices connected to the machine.
Best Regards,
FTDI Community
-
It is also identical to that shown below in at least one of their older products too, the Microham MicroKeyer II.
I have the same inability to use that device until the .dext VCP driver is available for Big Sur.
Chris, N0UK
Here it is (in macOS Catalina):
(https://www.imgdumper.nl/uploads9/5f5fa0dcdc05e/5f5fa0dcd91ee-Schermafbeelding_2020-09-14_om_18.54.34.jpg)
in macOS 11 Big Sur:
(https://www.imgdumper.nl/uploads9/5f5fa36177059/5f5fa3616da6a-Schermafbeelding_2020-09-14_om_19.04.59.png)
-
Hello,
I've doubled checked the above Product ID in the info.plist file and it looks like there are no special settings being used for this device. As such programming the device to use its Default product ID would all you to use it with the inbuilt Apple VCP driver. Are you aware of which FTDI product this device uses?
I've had an update from the developers, and they are currently working on resolve signature issues with the .dext driver package.
Best Regards,
FTDI Community
-
I've doubled checked the above Product ID in the info.plist file and it looks like there are no special settings being used for this device. As such programming the device to use its Default product ID would all you to use it with the inbuilt Apple VCP driver. Are you aware of which FTDI product this device uses?
Are you sure? I received the following comment from microHAM:
Herwig,
Yes, you can change PID using tools FTDI provides, but than interfaces will not work with our Windows Router software anymore and it will be violation of FTDI rules and warranty for interface. I recommend you to wait until FTDI releases driver for Big Sur.
Apple is causing issue by creating own driver for default chip PID and breaking devices usability for manufacturers who play by rules, hope FTDI will backup their customers quickly.
Default chip PID is reserved only for experimenting, small batch or for certified FTDI OEM partner. Neither Anytone, RT System or Kenwood is FTDI official OEM partner. Using default PID in non OEM commercial product is violation of rules. Only owner of VID (FTDI) can assign PID to particular manufacturer/product or product range. Same VID/PID cannot be used by different manufacturers on different devices for different functionality, that's basic rule set by USB-IF authority (usb.org) and that's the reason why we have asked FTDI for assigning range of custom PIDs and using them for many years.
73 Jozef OM7ZZ
-
Hello,
Here is the entry for the device with the 0xEEEF product ID:
<key>microHAM USB Port</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>idProduct</key>
<integer>61167</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>
And for reference here is a standard FT232R device:
<key>FTDI R Chip</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>bcdDevice</key>
<integer>1536</integer>
<key>idProduct</key>
<integer>24577</integer>
<key>idVendor</key>
<integer>1027</integer>
</dict>
The Microham device hasn't defined any special settings for latency timer, buffer sizes of buad rate aliasing, which is where my original comment stems from. However the have omitted the bcdDevice field which may cause issues depending on which IC they are using. If they are advising their software wont work when the FTDI defaults are used then I would stick with this advice. But in general as a stop gap solution it is perfectly fine to re-program a device to use FTDI defaults.
Best Regards,
FTDI Community
-
Thanks for the information. I changed the PID of the microHAM USB Interface III to 0x6001 (24577) and it works now with the standard macOS Big Sur .dext
-
Related to this, it seems that there's some problem with the kext driver version 2.4.4 notarization, so the installer refuses to start even on macOS 10.15.
-
Any update on VCP drivers for Big Sur? I'm hearing daily from upset customers that their device does not work.. and Big Sur has been out for months now.... :(
-
Hello,
Unfortunately there hasn't been any updates from our driver team as of yet, but I will be sure to post any updates when I receive them.
Best Regards,
FTDI Community
-
It's been more than another month now... it seems clear that nobody is actually working on this. The new driver requirements are not *that* horrible - they are no longer .kext, but Apple is pretty transparent about how you need to set them up and sign them etc.
Any chance we'll get new drivers from FTDI this quarter?
03/19/2021 Update: No. No chance they'll get this out this quarter. Maybe this summer.
-
This is getting really pretty old. When is this problem going to get any attention?
-
Thanks for the information. I changed the PID of the microHAM USB Interface III to 0x6001 (24577) and it works now with the standard macOS Big Sur .dext
Thanks for verifying that it's possible to get a Microham device working with Big Sur's native driver. What exactly did you have to do to get it working? Presumably just editing some text configuration file, but which/how?
Chris, N0UK
microKEYER II user!
-
@n0uk
I changed the PID with FTDI's FT_Prog software on a Windows computer. It's a pretty easy exercise.
-
I was reminded of this problem by one of my customers. can someone give the developers some strong coffee? and make it a very big red point on the top of their list? this is becoming very embarrassing.
-
Hello,
I have be liaising with the driver team recently and they are making good progress. We are currently establishing which features supported in our driver but not in the Apple driver are most pertinent for a beta release. For example, baud rate aliasing or latency timer settings.
If you are using any of these feature please let me know.
Best Regards,
FTDI community.
-
@n0uk
I changed the PID with FTDI's FT_Prog software on a Windows computer. It's a pretty easy exercise.
Thanks
-
On macOS 10.15 we had noticed that a Wacom Tablet driver was preventing both our VCP driver and apples VCP driver from attaching to devices and providing a COM port in the '/dev' folder. This may still be the case for some of your customers on Big Sur, however it could be an issue with the Apple driver itself.
I just registered an account on this forum to confirm that uninstalling Wacom resolved my connection issues.
I was fighting this problem for several days before I found this solution. I hope that my confirmation saves someone else some time.
Wacom drivers are the worst...
-
I have an FT23R-based USB-Serial device running on Big Sur and it's used for bidirectional serial communications with a legacy device, making use of flow control using the RTS and CTS pins. However, with both the Big Sur OS-integrated driver, and with the FTDI-published VCP beta driver dated 2021-05-18 (https://ftdichip.com/Drivers/vcp-drivers/) for macOS 11 the file transfers only work in one direction - from mac to the device. Retrieving files from the device to the Mac does not work.
The same USB-Serial device works fine for transfers in both directions on Windows 10 using the same open source client software, so there appears to be something fundamentally broken with this driver. I also found this error report, which may be the same issue (CTS not working properly?):
https://www.gitmemory.com/issue/serialport/node-serialport/2243/834035511
-
Hello,
Thank you for your feedback, I have reported this back to the development team for investigation.
Best Regards,
FTDI Community
-
Hello. My name is Scott Miller and I am a BCI researcher. I too am experiencing severe latency issues with the VCP driver on macOS 11. I am using a MacBook Pro M1 running the latest version of Big Sur.
I read this entire thread and several others blog threads across the internet. I emailed and spoke with Cameron from FTDI tech support in Oregon. Cameron was very helpful. He let me know that the latest 1.4.7 driver runs on both x86_64 and arm64. I tried modding the 1.4.7 driver on my M1 but ran into the same code signing issues described by others in this thread.
Cameron also reached out to the FTDI team in the UK on my behalf. That team replied with some links which talk about how to build my own driver, but that's not very useful to me at this point in time.
I also tried calling tech support in Glasgow, during normal working hours in GMT, but was unable to reach anyone at all. The voice mailboxes are all full, and not even an operator answered my calls. I tried repeatedly.
I suspect that FTDI is for some reason unable to obtain a DriverKit entitlement from Apple. Is that the case? Has FTDI made any progress on this issue?
-
Hello Scott,
Thank you for your question.
I would like to apologise that you haven't be able to contact any via phone in the UK office, unfortunately we are still working form home currently.
We are currently investigating how to generate a codeless .dext wrapper for any Info.plist modifications which might be required by an end user.
Is this what you are trying to achieve?
Could you describe the latency issues you are seeing?
Hello. My name is Scott Miller and I am a BCI researcher. I too am experiencing severe latency issues with the VCP driver on macOS 11. I am using a MacBook Pro M1 running the latest version of Big Sur.
I read this entire thread and several others blog threads across the internet. I emailed and spoke with Cameron from FTDI tech support in Oregon. Cameron was very helpful. He let me know that the latest 1.4.7 driver runs on both x86_64 and arm64. I tried modding the 1.4.7 driver on my M1 but ran into the same code signing issues described by others in this thread.
Cameron also reached out to the FTDI team in the UK on my behalf. That team replied with some links which talk about how to build my own driver, but that's not very useful to me at this point in time.
I also tried calling tech support in Glasgow, during normal working hours in GMT, but was unable to reach anyone at all. The voice mailboxes are all full, and not even an operator answered my calls. I tried repeatedly.
I suspect that FTDI is for some reason unable to obtain a DriverKit entitlement from Apple. Is that the case? Has FTDI made any progress on this issue?
Best Regards,
FTDI Community.
-
Yes I am trying to modify the Info.plist to adjust the latency and buffer settings, because I am experiencing extreme jitter in the timestamp intervals. The issue is so severe that unless I can correct it, I cannot use the FTDI chip for my experiments.
My teammate is using the same chip on his older, Intel-based MacBook Pro. He is also running the latest version of Big Sur. He tried the unmodified 1.4.7 driver, and a modified 2.4.4 driver. The unmodified 1.4.7 provides smoother streaming with less jitter than the modified 2.4.4, but it's still not good enough for our experiments.
The following are the settings he added to the Info.plist of the 2.4.4 driver:
<dict>
<key>InBufferSize</key>
<integer>128</integer>
<key>LatencyTimer</key>
<integer>24</integer>
</dict>
Can you recommend a different driver or different modifications for him?
--Scott
-
Hello Scott,
Thank you for the details.
The Latency timer and buffer settings are the correct settings to alter in this case.
However as I'm sure you have noticed performance on different machines can vary, this is due to the inherent nature of USB.
USB products can’t reliably be used in real-time applications with time interval resolution guarantees.
Sometimes the behaviour of USB can be a problem and applications cannot be guaranteed throughput.
If there is more USB traffic then the OS and USB have to schedule the communication with each of the USB devices.
It’s highly dependent on the OS and USB Host and is out with our control.
You could take a look at the following App notes:
Data Throughput, Latency & Handshaking (https://www.ftdichip.com/Support/Documents/AppNotes/AN232B-04_DataLatencyFlow.pdf)
Optimising D2XX Data Throughput (https://www.ftdichip.com/Support/Documents/AppNotes/AN232B-03_D2XXDataThroughput.pdf)
These apply to all of our USB products.
The latency timer can only be set to 1ms minimum for our High Speed USB products and nothing less, and 2ms for our Full Speed USB products (like FT232R inside the USB-RS485-WE cable).
Best Regards.
FTDI Community
-
Thanks for the docs. The VCP doc is informative, but it does not contain instructions for MacOS. Can you please also send me instructions for reconfiguring your VCP driver on MacOS.
-
Hello,
Unfortunately we currently only have instructions for the previous .kext version of the driver:
https://ftdichip.com/wp-content/uploads/2020/08/TN_105-Adding-Support-for-New-FTDI-Devices-to-Mac-Driver.pdf (https://ftdichip.com/wp-content/uploads/2020/08/TN_105-Adding-Support-for-New-FTDI-Devices-to-Mac-Driver.pdf)
The edits to the info.plist would remain the same in terms of the latency timer and inbuffersize attributes, however Apple stipulating a codeless .dext approach for modifying drivers in macOS 11. The driver team are currently looking into the best way to produce a codeless .dext.
Best Regards,
FTDI Community
-
Thanks again! That is indeed a useful doc. What is the latest version of MacOS for which those instructions are valid?
-
Hello,
That would be the last version of macOS to support .kext drivers, this would be 10.15, but there is an extra notarization step for .kext drivers required by Apple in 10.15, that is not noted in that document. As such it would be safe to assume these instructions work up for drivers up till macOS 10.14.
Best Regards,
FTDI Community
-
Hello,
That would be the last version of macOS to support .kext drivers, this would be 10.15, but there is an extra notarization step for .kext drivers required by Apple in 10.15, that is not noted in that document. As such it would be safe to assume these instructions work up for drivers up till macOS 10.14.
Best Regards,
FTDI Community
Hi "FTDI Community" / moderator,
I've been in contact with @scottmiller regarding his difficulty adjusting the macOS 11 FTDI 'latency' setting. (macOS 11 is required for Apple hardware using the new M1 CPU.) For our Windows customers, this is extremely easy: they just bring up the Windows driver control panel, and type in the new Latency value. In this case '1' ms is the Latency value we need for optimum packet latency with the OpenBCI Cyton product.
What we are requesting: is a similarly easy way to do this on macOS 11. That should not require modifying Info.plist files, or signing a driver. It should be an external file that you look for, upon driver loading time. This would have fields similar to a .plist, for adjusting values like are possible on Windows. But it would not have to be a .plist, could even be something simple like one line per adjustment: "variablename value".
Can you give us a timeline for when FTDI will release this macOS 11 compatible driver with adjustable settings? The lack of this is causing great difficulty with our Mac customers.
Thanks,
William Croft
OpenBCI Forum admin
-
Hi, as a manufacturer of equipment that utilizes many hundreds of your FT231XQ chips, we would like an update on the status of a configurable macOS 11 driver. Our customers MUST be able to set the Latency Timer to 1 ms, to flush the radio packets into the laptop for real-time EEG processing.
This was 'possible' with older drivers, but such drivers cannot be used by newer Macs using the M1 CPU chips. Those machines are limited to macOS 11.
We realize that your driver is in 'beta', but this capability seems WAY overdue, many months overdue.
I'd appreciate an acknowledgement that your engineers are prioritizing a workable solution.
William Croft
OpenBCI
https://openbci.com/ (https://openbci.com/)
-
Hello,
I have be liaising with the driver team recently and they are making good progress. We are currently establishing which features supported in our driver but not in the Apple driver are most pertinent for a beta release. For example, baud rate aliasing or latency timer settings.
If you are using any of these feature please let me know.
Best Regards,
FTDI community.
Could I get an acknowledgement from "FTDI community" FTDI staff member? You explicitly asked on MARCH 17, SEVEN MONTHS ago, for customer needed capability in your macOS 11 Big Sur FTDI driver. Both Scott and I (post yesterday) have an urgent need for the ability to set the Latency Timer in your driver. WITHOUT needing code signing or Info.plist editing.
What is the timeline and estimate for availability? Is ANYONE at FTDI actually concerned that customers using many hundreds of your chips, are now facing increasing customer complaints?? And that we will drop purchasing of your chips in the future?
William Croft
OpenBCI
https://openbci.com/ (https://openbci.com/)
-
Hello,
We have received your email and are in contact with our R&D team about this.
Please continue to work with us on email as the forum is maybe not the best medium to get the quickest support.
Best Regards,
FTDI Community
-
It is now February 2022, have there been any developments with the VCP driver on macOS 11. I particular, how to set latency?
-
Hello,
FTDI’s Mac OS X10.15 and macOS 11/12 VCP driver can change the latency timer but you will need to edit the info.plist but this means that the driver would need to be resigned as driver signing is enforced on macOS:
https://ftdichip.com/drivers/vcp-drivers/ (https://ftdichip.com/drivers/vcp-drivers/)
See TN_105 Adding Support for New FTDI Devices to Mac Driver. (https://ftdichip.com/wp-content/uploads/2020/08/TN_105-Adding-Support-for-New-FTDI-Devices-to-Mac-Driver.pdf)
Signing requires you to join the Apple Dev program and applying for a signing certificate.
The other alternative for MacOS is to use the D2XX (https://ftdichip.com/drivers/d2xx-drivers/) drivers. See the Mac OS X Installation Guide (https://ftdichip.com/wp-content/uploads/2020/08/AN_134_FTDI_Drivers_Installation_Guide_for_MAC_OSX-1.pdf) and the D2XX Programmer’s Guide (http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf) and the FT_SetLatencyTimer API.
Example d2xx code is provided with the d2xx driver download.
Best Regards,
FTDI Community
-
A workaround solution now exists for setting Latency on macOS 11
It was created by Matt Keeter. It is a small C program running on macOS, that sets the latency to any desired value. The program needs to be run once per FTDI usb device insertion, since the latency value is not remembered in the macOS driver.
For links see this post and thread on our OpenBCI Forum discussion board:
https://openbci.com/forum/index.php?p=/discussion/comment/17915/#Comment_17915
https://openbci.com/forum/index.php?p=/discussion/3108/ftdi-driver-latency-timer-for-macbook-m1#latest
I would hope that FTDI management makes this available to those not reading this FTDI Community thread.
William Croft
OpenBCI Forum moderator
-
I have an FT23R-based USB-Serial device running on Big Sur and it's used for bidirectional serial communications with a legacy device, making use of flow control using the RTS and CTS pins. However, with both the Big Sur OS-integrated driver, and with the FTDI-published VCP beta driver dated 2021-05-18 (https://ftdichip.com/Drivers/vcp-drivers/) for macOS 11 the file transfers only work in one direction - from mac to the device. Retrieving files from the device to the Mac does not work.
The same USB-Serial device works fine for transfers in both directions on Windows 10 using the same open source client software, so there appears to be something fundamentally broken with this driver. I also found this error report, which may be the same issue (CTS not working properly?):
https://www.gitmemory.com/issue/serialport/node-serialport/2243/834035511
This issue I described above is still present today using macOS Monterey (12.4) with the built-in driver, and also using the beta VCP driver 1.50 dated 2022-06-13.
The Github issue I quoted above about broken CTS support (now a broken link) can be found here:
https://github.com/serialport/node-serialport/issues/2243
-
Hi,
Can you clairfy, what open source client software' are you using? Have you tried with a terminal programs like PuTTY or Coolterm?
The application has to specify CTS/RTS support. It can be selected with those two terminals mentioned above.
Regards
FTDI Community
-
The software is EazyLink2, a serial file transfer utility for the Cambridge Z88 computer:
https://sourceforge.net/projects/z88/files/EazyLink%20Desktop%20Client/
This software requires hardware flow control. It is a multiplatform application built on the Qt5 framework, and it uses the Qt5 Serial Port implementation.
https://wiki.qt.io/Qt_Serial_Port
I ended up giving up with the FTDI serial device and bought a Keyspan serial dongle. This works perfectly with EazyLink2. It allows for reliable bidirectional transfers with no errors, which means that the FTDI driver isn't functioning correctly. The money I spent on an FTDI dongle was wasted.
-
To adjust Latency, delete your FTDI VCP driver and use Apple's default driver with their latency IOCTL function.
See this post:
https://openbci.com/forum/index.php?p=/discussion/comment/18231/#Comment_18231
on this thread:
https://openbci.com/forum/index.php?p=/discussion/3108/driver-latency-timer-fix-for-macos-11-m1-m2
William Croft
Forum admin, OpenBCI