I'm using an iduino from "Fundamental Logic" (http://spiffie.org/kits/iduino/parts3.shtml), which has a pre-installed FT232 chip for USB connection. The board works fine when using port com4. It also works fine if I install a different, pre-arduinoized, atmega168, also using port com4.
However, I have seperate USB to TTL Serial converter kit(http://store.fundamentallogic.com/ecom/index.php?main_page=index&cPath=6), which uses an FT232RL conversion chip. I wanted to test it out. I tried using this converter on the Iduino, I get a message stating "cannot find com4". I get the same message no matter which atmega 168 is used in the iduino. (the iduino's pre-installed usb/ttl converter is left unconnected) When I try to change com ports in the tools menu, I'm given the choice of com3. I tried com3, and I get error messages, and the sketch won't upload to the board.
After switching things around, I found that the problem only arises when using seperate USB to TTL Serial converter kit. I get the same results when using the seperate converter on another board.
Why would there be this confusion between USB to TTL converters if they are using the same type of converter chip ?
Thanks for the quick response.
OK, here goes.
(1) iduino with its original usb connector works fine.
(2) switch to seperate usb to ttl convert. kit (leaving original unconnected), verify- works fine, try to upload I get "cannot find com4, did you use proper port in tools menu?"
(3) I look in tools menu and find com3 as a choice. I click on com3, and try again.
(4) When trying again, verify works OK, try to upload I get messages:
"PROBLEM UPLOADING TO BOARD" Then comes the kiss of death messages:
avrdude: stk 500_get sync(): not in sync: resp 0x00
avrdude: 500_disable(): protocol error, expect=0x14, resp=0x51
I've seen these messages before, from a board that I don't/can't use. I've also searched throughout the internet for an answer, and have read posts on this forum, and have never read of a clear cut answer to the problem. Just a lot of guesses.
I suspect it has something to do with port selection or port use. I tried to do some changing in my device manager, but things just got worse. So I put everything back where it all started out.
I'm using a laptop,new, with Windows Vista, and have downloaded FTDI virtual COM port driver (VCP) 2.04.16
Why don't you prove out your Windows enviroment first. Reboot, plug in serial USB cable. Run hyperterminal, set to whatever com port is now active, put a jumper wire on the TTL side of the serial USB cable convertor from Xmit to Rec pins. This should create a loop back path such that what ever you type in HT should be received back.
No hyperterminal on vista, but I downloaded one and got it working with one of my arduino sketches - works like it had ought to on com4. Data from sketch shows up real nice on ht.
If you need a serial terminal program (now that Vista no longer includes HyperTerm), you can try PuTTY. The latest PuTTY has an added serial mode in addition to the well-established Telnet and SSH modes.
Posted by: Anachrocomputer Posted on: Today at 01:16:02
If you need a serial terminal program (now that Vista no longer includes HyperTerm), you can try PuTTY. The latest PuTTY has an added serial mode in addition to the well-established Telnet and SSH modes
Yep, did that, got one working, as I stated previously.
No hyperterminal on vista, but I downloaded one and got it working with one of my arduino sketches - works like it had ought to on com4. Data from sketch shows up real nice on ht.
It was a regular hyperterminal; not sure if I want to put putty in my new computer. ;D
Posted by: retrolefty Posted on: Yesterday at 21:59:33
Why don't you prove out your Windows enviroment first. Reboot, plug in serial USB cable. Run hyperterminal, set to whatever com port is now active, put a jumper wire on the TTL side of the serial USB cable convertor from Xmit to Rec pins. This should create a loop back path such that what ever you type in HT should be received back.
Yep, did this, too. It also works with seperate USB to TTL converter.
I don't think there is any confusion when creating virtual COM ports by the FTDI driver. The driver simply identifies the individual FTDI chip and creates a virtual COM port for it.
In Windows, you can see the virtual (USB) COM ports listed in Device Manager (System Properties/Hardware/Device Manager).
If you have 2 identical arduino boards (or for that matter, 2 identical FTDI chips), open Device Manager and expand the "Ports" node; then connect your first arduino/FTDI chip, and you will see a new port listed. Now disconnect the first and connect your second arduino/FTDI chip. You will see a new COM port listed and the old one gone. Smart way for the FTDI driver to manage multiple FTDI chips.
Posted by: florinc Posted on: Today at 03:32:05
I don't think there is any confusion when creating virtual COM ports by the FTDI driver. The driver simply identifies the individual FTDI chip and creates a virtual COM port for it.
In Windows, you can see the virtual (USB) COM ports listed in Device Manager (System Properties/Hardware/Device Manager).
If you have 2 identical arduino boards (or for that matter, 2 identical FTDI chips), open Device Manager and expand the "Ports" node; then connect your first arduino/FTDI chip, and you will see a new port listed. Now disconnect the first and connect your second arduino/FTDI chip. You will see a new COM port listed and the old one gone. Smart way for the FTDI driver to manage multiple FTDI chips.
Yes, I see this happening, but it still doesn't work. I see the port as it is on com4, while USB is connected to FTDI chip #1, and the board works just fine.
When I pull USB from chip #1, then connect to FTDI chip#2, device manager shows automatic port change from com4 to com3, the same happens in tools> serial port, sketch will not upload to board on com3, whether I click on com3 (in tools) or not; I get those avrdude messages, which nobody seems to know what they stand for.
Is ther something else that needs to be done in the device manager?
So then this seems to be a serial communication issue, not a device driver issue.
If I understand correctly, you can see the COM ports in the Arduino IDE, you can select them accordingly, but when you do the upload of the sketch, you get errors.
I am not familiar with iduino, but it may be that the bootloader uses a different baud rate than other standard bootloaders (those used in the original arduinos). Is this the only board you have? Can you try an arduino/freeduino/seeduino?
Posted by: florinc Posted on: Today at 16:16:48
So then this seems to be a serial communication issue, not a device driver issue.
If I understand correctly, you can see the COM ports in the Arduino IDE, you can select them accordingly, but when you do the upload of the sketch, you get errors.
I am not familiar with iduino, but it may be that the bootloader uses a different baud rate than other standard bootloaders (those used in the original arduinos). Is this the only board you have? Can you try an arduino/freeduino/seeduino?
I have one other board, an RBBB(really bare bones board) that doesn't use a USB connection; it uses a TTL to serial converter that connects to a serial port on a PC. I never could get it working with the serial port. I tried connecting the USB / TTL converter to that and got negative results.
the FTDI wants the working Iduino on com4, which works fine, and the seperate USB/TTL converter on com3; negative function.
Right now, it looks like I can use only one arduino board.
Posted by: Grumpy_Mike
Quote:
When I pull USB from chip #1, then connect to FTDI chip#2, device manager shows automatic port change from com4 to com3,
Yes that's what is supposed to happen. A different FTDI chip will show up as a different com port so you can use more than one at a time.
Yes, I see that. Its interesting to know that more than one board can be connected at one time. Thanks, Mike.
Well folks, I'm sorry for all the consternation, but I found the problem, at least I got things working. I switched the RX and TX leads around. The pin marked RX on the Iduino board is now connected to the TX pin on the seperate USB to TTL converter, and vica-versa. So now things work. I don't know the reasoning behind why the pins are marked in reverse order. I guess it must be transmit (TX) from one chip to receive (RX) in the next chip in line. Well, there ya go. :-[ :-[
