I have a small fleet of DC Boarduinos. I like to program them with my FTDI cable I got from Adafruit. The problem is they don't work.
It used to be, I could plug and unplug the FTDI cable from my USB port, and when I did that it would attach to /dev/ttyUSBN+1 each time I replugged it. Then I would be able to upload one time, then I would have to plug and unplug the cable again.
This was annoying enough, but now for some reason when I plug and unplug the cable, it always goes back to /dev/ttyUSB1 and so I can't even do that anymore and I have to reboot my system in order to upload more than one time.
I've tried to google for a fix but I haven't found anything. Does anyone know how I can fix the issue or at least get my system to go back to attaching the FTDI cable to a new TTY every time?
Sounds like your system is broken if it requires a reboot to get it to show up again. My experience has always been that the first device is /dev/ttyUSB0. If I plug in a second device it is ttyUSB1, etc. I haven't done any unplugging/replugging to see what happens, but I would expect the system to use the first available ttyUSBn when a device is plugged in.
If I used linux much, I'd create some udev rules so that the names are the same as they are on the Mac. The FTDI driver for the Mac includes the serial number as part of the device special file, which I find extremely useful. A set of udev rules can duplicate that on linux.
Sounds like your system is broken if it requires a reboot to get it to show up again.
It doesn't require a reboot to show up again. When I plug and unplug the cable, it always shows up as /dev/ttyUSB0. This is probably what is supposed to happen.
The trouble is that due to a bug in the FTDI drivers, /dev/ttyUSBN can only do one upload, for some reason. So I have to reboot if I want to upload more than once.
It used to be that plugging and unplugging the cable would cause it to be detected as /dev/ttyUSB1, then /dev/ttyUSB2, etc. and I could upload once each time.
Google tells me that this is a known bug in the FTDI drivers, but how are other people getting around this? Is nobody using FTDI cables on Linux?
Which package of linux (ubuntu, slackware, etc...). kernel version? Arduino software version?
Does the /dev device disappear when you unplug the cable? Have you checked the system logs? We will need all the details to help you.
Ubuntu 10.04. The /dev/ttyUSB0 goes away when I unplug the device and dmesg says that it has been unplugged and detects it when it plugs in just fine. And of course it always works...exactly 1 time. So it's not like it doesn't work.
I assumed it was related to this bug but I'm not a kernel hacker by any means, I just know it doesn't work, and the plugging-and-unplugging trick isn't doing it anymore.
Here's some people talking about what sounds like a similar issue, but I don't understand it whatsoever
my opinion: I think the first thing I would do is upgrade my Ubuntu system to the latest stable version, I believe it is version 10.10. More people use it = more people to help when you have a problem.
known bug in the FTDI drivers
This bug was fixed is later version of the kernel and then broke again
I use Ubuntu 10.04 32 bit with Arduino 0022. It works fine with Duemilanove (FTDI) and Uno.
Kernel is :
Linux 2.6.32-28-generic i686 (The current one that comes in with the updates).
Haven't had any problem with Linux and Arduino since I was on Ubuntu 8.04. I always use Synaptic to install the prerequisites and then just extract the downloaded zip file to my home folder and run it from there. Never had to do any messing with root or changing access on anything. The Duemilanove comes up as /dev/ttyUSB0 and the Uno as /dev/ttyACM0 except if its been unplugged for less than a minute or two when it resorts to /dev/ttyUSB1 .
This article has been on the playground for almost 2 years now.
It covers the issue of the FTDI cable using RTS instead of DTR. The workaround is not perfect, but tolerable most of the time. Code improvements always welcome.
A related post on the adafruit forum provides a similar solution using python instead of perl.
