armadsen
An ORSSerialPort created with serialPortWithPath:tty.device actually opens the callout path.
Hi, please bear with me, I'm new with Arduino and hardware programming.
During the programming of my Arduino, I've always used the /dev/tty.usbmodemXXX for the serial monitor without issue. And it never works with /dev/cu, I never really thought about it because, well it works with tty, so I just use that. And here I am, trying to use ORSSerialPort to send and receive data with my Arduino;
Serial port usbmodem1441 encountered an error: Error Domain=NSPOSIXErrorDomain Code=16 "Resource busy" UserInfo=0x6080000763c0 {NSFilePath=/dev/cu.usbmodem1441, NSLocalizedDescription=Resource busy}
Why is the ORSSerialPort only wanting to work with cu port? The ORSSerialPortManager only listed the cu paths. Even when I hardcoded the connection (using the Cocoa demo);
_serialPort = [ORSSerialPort serialPortWithPath:@"/dev/tty.usbmodem1441"];
_serialPort.baudRate = @115200;
_serialPort.delegate = self;
[_serialPort open];
I'm getting the exact same error message saying /dev/cu.usbmodemXXX resource is busy.
Any idea how to fix this? I know the tty port is there, I can see it from Arduino.app
I'm not sure what might be going on. I've never seen the cu path fail to open while tty works (it's usually the other way around...). For device discovery, ORSSerialPort doesn't really use the path directly. It uses IOKit's device discovery API. Even when passing a path into -serialPortWithPath:, it actually just matches the path with an IOKit device (see +[ORSSerialPort deviceFromBSDPath:] for this logic), and in fact, the same underlying device is obtained for both the cu and tty paths for a given port.
For reasons that I can no longer completely remember, I decided to always use the callout path as the value for the path property. This is set in -initWithDevice:.
The one place where the path is directly used is in the call to open() in -[ORSSerialPort open]. This is why a port created by passing the tty path to +serialPortWithPath: still opens using the callout path.
So, that's all a long winded, probably-too-technical way of explaining that a quick workaround might be to change this line in -initWithDevice::
NSString *bsdPath = [[self class] bsdCalloutPathFromDevice:device];
to:
NSString *bsdPath = [[self class] bsdDialinPathFromDevice:device];
Let me know if that fixes the problem. I'm also curious to know which particular Arduino board you're using, as well as the version of OS X you're on.
Yes, that did it! Thanks for the speedy response!
2015-02-07 00:40:03.339 ORSSerialPortCocoaDemo[5743:1075470] t1=-1.0
t2=-1.0
power%=46
fan
2015-02-07 00:40:03.343 ORSSerialPortCocoaDemo[5743:1075470] =0
pots=474
2015-02-07 00:40:05.346 ORSSerialPortCocoaDemo[5743:1075470] (null)
2015-02-07 00:40:06.345 ORSSerialPortCocoaDemo[5743:1075470] (null)
2015-02-07 00:40:08.344 ORSSerialPortCocoaDemo[5743:1075470] (null)
2015-02-07 00:40:08.348 ORSSerialPortCocoaDemo[5743:1075470] (null)
2015-02-07 00:40:10.351 ORSSerialPortCocoaDemo[5743:1075470] (null)
2015-02-07 00:40:13.353 ORSSerialPortCocoaDemo[5743:1075470]
2015-02-07 00:40:15.352 ORSSerialPortCocoaDemo[5743:1075470] t1=-1.0
t2=-1.0
power%=46
fan=0
2015-02-07 00:40:15.356 ORSSerialPortCocoaDemo[5743:1075470] pots=474
2015-02-07 00:40:16.356 ORSSerialPortCocoaDemo[5743:1075470] =-1.0
power%=46
fan=0
pots=474
Getting a bunch of nils, but that's not a problem.
I'm on Yosemite 10.10.1 and Uno clone (where I am there is 2 months wait and at 2x the price for the original).
So callout path is cu and dialin path is tty?
Edit: Arduino Uno R3 clone.
Also, Arduino's getting started guide tells us to choose tty:
Select the serial device of the Arduino board from the Tools > Serial Port menu. On the Mac, this should be something with /dev/tty.usbmodem (for the Uno or Mega 2560) or /dev/tty.usbserial (for older boards) in it.
I'm assuming that's received data you're logging. The nulls might be due to data being received that can't be converted to a printable string. I can't tell for sure without seeing your logging code and the data coming in. Anyway, as long as you know what's going on, that's what matters :)
Yes, cu. paths are callout paths, while tty. paths are dialin paths. It's kind of a leftover from the old days, but in short, the tty path would block open() until a carrier detect on the connected modem, while cu. would always open for calling out. Most of the time they're interchangeable. I still wish I knew why the callout path isn't working for you. (Assuming I understand this correctly. It was before my time.)
Anyway, this does raise what could be called a weakness in the ORSSerialPort API. It might make more sense, or at least meet user expectations better, if a port created with the tty path actually opened the tty path! There's some subtlety there due to ORSSerialPorts one instance per hardware port policy, but I think I can come up with an OK solution.
I'm going to leave this issue open for a possible improvement in that area.
Hi Armadsen, I was suffering from the same problem for a couple of days. It looks like cu.xxx is being blocked for rather long time ( up to 3-4 minutes ) even if you properly closing serialPort. It was very annoying. I have noticed, that that locking duration depends on USB Serial vendor : with TI-s MB430-USB it is being blocked for up to 5 minutes and it happens in 9 attempts of 10. For XR-21 the duration varies from 5 - 20 seconds and it happens in ~ 50% cases. Aparently, I have never seen the problem before El Capitan. Anyway, I have modified code to :
NSString *bsdPath = [[self class] bsdDialinPathFromDevice:device];
And it works perfect now: 10 of 10. Thank you so much !
Hello @armadsen ,
it looks like using cu always instead of tty is not always right (e.g. in case of composite device).
It seems to me that it could be a good idea to enable user (of this library) to set explicitly what kind of path to use in initWithDevice:(io_object_t)device. The param could be something like useCallloutPath. The default value could be true for such a key for the backward compatibility.
Shall I create pull request for such a thing? Is there any chance for it to be merged?
Sure, a PR would be most welcome. It needs to not break the existing API, though.
On Jul 27, 2022, at 1:03 PM, Alex Frankiv @.***> wrote:
Hello @armadsen , it looks like using cu always instead of tty is not always right (e.g. in case of composite device).
It seems to me that it could be a good idea to enable user (of this library) to set explicitly what kind of path to use in initWithDevice:(io_object_t)device. The param could be something like useCallloutPath. The default value could be true for such a key for the backward compatibility.
Shall I create pull request for such a thing? Is there any chance for it to be merged?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.