/dev/tty.* and /dev/cu.* and AppleUSBFTDI

Apple Mac OSX
User avatar
Kenjutsu
Posts: 134
Joined: Fri May 29, 2015 8:26 am

/dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by Kenjutsu » Fri Jun 26, 2015 6:01 pm

Recently I have been struggling to upload to my Blue Pill (BP) and Maple Mini (MM) clones. The problem arised with whether I choose the /dev/tty.* or /dev/cu.* port of my USB to serial converter.

Using stm32flash, only the /dev/tty.* port works, an not the /dev/cu.* port. For stm32loader.py, both work. For maple_upload, only the /dev/cu.* port works. This was extremely confusing. :?

After a bit of searching, I came across the following: Arduino in OS X 10.9 Mavericks - Serial Port Issues. And there it was, AppleUSBFTDI was causing the problems! I am using a FTDI base adapter, and after unloading the Apple FTDI driver, and only loading the FTDI driver, everything is working again on the /dev/cu.* port :D Only stm32flash refuse to work with the /dev/cu.* port, no matter what.

As always, YMMW ;)
Pieter

OSX: 10.12.6
Arduino IDE: 1.6.12
Blue pill STM32F103C8T6 Dev Board
Maple Mini Clones

User avatar
RogerClark
Posts: 7500
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by RogerClark » Fri Jul 03, 2015 3:57 am

My FTDI adaptors just arrived, so if I have time at the weekend, I will see if they have the same issue on my OSX machines

madias
Posts: 813
Joined: Mon Apr 27, 2015 11:26 am
Location: Vienna, Austria

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by madias » Mon Jul 06, 2015 11:30 am

I have to say that I had already applied this apple_USB_FTDI hack long time ago. (Energia was permanently crashing), so this could be the reason I didn't got such troubles. Maybe a good point for the reference/manual?

User avatar
Kenjutsu
Posts: 134
Joined: Fri May 29, 2015 8:26 am

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by Kenjutsu » Tue Jul 07, 2015 6:35 am

Hi Roger

Have you had time to test your FTDI adaptors yet?
RogerClark wrote:My FTDI adaptors just arrived, so if I have time at the weekend, I will see if they have the same issue on my OSX machines
Pieter

OSX: 10.12.6
Arduino IDE: 1.6.12
Blue pill STM32F103C8T6 Dev Board
Maple Mini Clones

User avatar
RogerClark
Posts: 7500
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by RogerClark » Tue Jul 07, 2015 7:01 am

Yes

Tried it this afternoon

The problem appears to be in STM32Flash

It seems incapable of opening CU devices :-(

I didn't write it, and I don't think its supported by anyone, as I've already had to do some fixes for bugs on the PC where it only allowed COM port numbers from 1 to 9 (i,e single digit numbers)

STM32Flash is a bit convoluted as it supports both Windows and OX and Linux, so it has to separate sets of low level comms interaction code, and I think the makefile decides which low level c file to compile

I took a quick look at the code (its in the repo https://github.com/rogerclarkmelbourne/ ... serial/src
)

So you could take a look at the code to see why the open() call fails on a CU device

But, its not the driver thats at fault, because I connected the FTDI usb serial adaptor to HW serial 1 (PA9 and PA10), and write a sketch using serial1.println - then uploaded the sketch via the bootloader to the board.
And the IDE can open the CU device and I can see the text comming from hardware serial 1.

So its just a bug in STM32Flash :-(

Which I agree should be fixed, but I'm not sure I'm the ideal person to do it. ;-)

User avatar
martinayotte
Posts: 1229
Joined: Mon Apr 27, 2015 1:45 pm

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by martinayotte » Tue Jul 07, 2015 2:00 pm

Looking quickly at the code, I think I found the guilty line around 206 of serial_posix.c of my 0.4 version :

Code: Select all

        /* 1. check device name match */
        if (strncmp(ops->device, "/dev/tty", strlen("/dev/tty")))
                return PORT_ERR_NODEV;
And in Roger's github, the version is a bit different, but same compare problem at line 210 of serial_posix.c :

Code: Select all

	if (startswith(resolved, "/dev/tty")) return 1;
It seems that the failure comes from those compare mismatches !
So, Kenjutsu, maybe you should give it a try by changing that to also support the "/dev/cu" prefix. Let us know if you succeed.

User avatar
RogerClark
Posts: 7500
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by RogerClark » Tue Jul 07, 2015 9:23 pm

Martin

Well spotted.

I think i may as well remove that check, i can't see why it would be beneficial.

Or if there is a reason to check, then we'd need to check for "cu" devices as well as tty.

I suppose the safest course of action is the second solution

User avatar
martinayotte
Posts: 1229
Joined: Mon Apr 27, 2015 1:45 pm

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by martinayotte » Tue Jul 07, 2015 9:45 pm

Well, maybe the solution #1 is good too : removing that check !
Because why the author wished to verify that what we have written at command line is true, since I can decide to create a symbolic link such as /dev/ftdi pointing to /dev/ttyUSB99, that my choice ... ;)

User avatar
RogerClark
Posts: 7500
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by RogerClark » Tue Jul 07, 2015 10:10 pm

Martin

Good point about symlinks

I actually just tried option #2 and it fixed the issue. But so will removing the check altogether.

One thing I have just noticed with the FDTI clone I have, is that its not as reliable at the high baud rate I have defaulted it to.

Edit BTW. There is an issue with the .a file being in git, I need to set git ignore to exclude it,

User avatar
Kenjutsu
Posts: 134
Joined: Fri May 29, 2015 8:26 am

Re: /dev/tty.* and /dev/cu.* and AppleUSBFTDI

Post by Kenjutsu » Wed Jul 08, 2015 6:04 am

I agree with Martin and Roger.

Since we will (mainly) use stm32flash via the Arduino IDE, we know that the device/port sent to stm32flash will be either a /dev/tty or a /dev/cu, thus both will work.

If stm32flash is used "standalone", then the validation makes sense, but for our purposes, I think it is better to remove the validation to get stm32flash working with both, since stm32flash flashes faster than stm32loader.py
Pieter

OSX: 10.12.6
Arduino IDE: 1.6.12
Blue pill STM32F103C8T6 Dev Board
Maple Mini Clones

Post Reply