USB<->RS232 - slightly off-topic

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I recently bought an Arduino Mega2560 board to use in a one-off project. This question is not about the atmega2560 or the code running on it, but about the atmega16U2 that board uses for its serial<->USB bridge. Essentially, this bridge seems to drop characters.

Hardware setup:
==

A) mega2560 --RS232-> 16U2 --USB-> PC (linux)

B) mega2560 --RS232-> 16U2 --USB-> PC (WinXP)

C) mega2560 --RS232-> FTDI --USB-> PC (WinXP)

I am running Br@y's terminal on the WinXP PC to monitor the characters sent by the mega2560, and just "cat /dev/ttyXXX" on the linux one. There is no traffic in the opposite direction.

mega2560 Firmware
==

I have run two sets of firmware on the mega2560:

1) an arduino sketch which sends a burst of about 20 characters once every few seconds, at 9600 baud.

2) a gcc-compiled program (not based on any arduino code or libraries) which keeps the RS232 transmitter saturated at up to 115200 baud.

Results:
==

Firmware (1) on hardware (A) drops characters very occasionally - maybe a burst of 5-10 characters once or twice per day.

Firmware (2) on hardware (B) drops characters every few seconds at 9600 baud, and drop them all over the place at 115200 baud.

Firmware (2) on hardware (C) seems to be OK, but hasn't been so exhaustively tested.

Other combinations are untested as yet.

Conclusion
==
This seems to point the finger at the 16U2 chip that forms the RS232<->USB bridge on the arduino mega2560 board, but if this is the case I am surprised not to have found others with similar experiences here, on the arduino forums, or more generally. I have however seen reports of other bugs with it, so I was wondering if there is any wisdom available here before I either abandon it (in favour of the FTDI) or start trying to debug its code.

Christopher Hicks
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

"cat /dev/ttyXXX"

Wouldn't minicom be a better idea? (I also use GtkTerm sometimes).

As the 2560 has multiple UARTs what happens if you connect a USB-TTL cable from ebay ($2) to a different pair of TXDn/RXDn pins and use that UART instead? That would isolate whether it really is a 16U2 issue or a more general USB issue (those cables use Prolific/Microchip/FTDI USB-UART chips rather than the 16U2).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

one quick test to see if a small speed issue try 9600 baud with 2 stop bits.

Do you know of errors in the u16 code?
And perhaps the Atmel usb driver

Add admitt that I use FDTI chips, at least in the old days they where the best, and windows have the driver.

Last Edited: Wed. Jul 9, 2014 - 09:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the quick replies.

clawson wrote:
Quote:

"cat /dev/ttyXXX"

Wouldn't minicom be a better idea? (I also use GtkTerm sometimes).

Maybe, but that's not the issue. I just wanted to reassure the reader that it was not likely to be the terminal program (or lack of it) dropping characters.

clawson wrote:

As the 2560 has multiple UARTs what happens if you connect a USB-TTL cable from ebay ($2) to a different pair of TXDn/RXDn pins and use that UART instead?

Yes, that's essentially what I did (with an FTDI cable). I tried UART1 with the FTDI cable, and also just tapping off the UART0 Tx signal so that it fed the 16U2 and the FTDI cable together. The results seemed to confirm that the path via the 16U2 dropped characters, but the path through the FTDI did not. There was a slight issue in that either WinXP or the Br@y terminal objected to having both the FTDI cable and the 16U2 connected simultaneously.

sparrow2 wrote:
Do you know of errors in the u16 code?
And perhaps the Atmel usb driver

No, I don't know. That's exactly what I am asking here, before I assume that to be the case and dig further in that direction. If the 16U2 on the arduino mega does drop characters I would be surprised not to see it mentioned elsewhere, which is why I am slightly cautious of trusting my diagnosis.

CH
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how do you tell the 16U2 which baudrate to use?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I possess two UNO clones and one MEGA clone.
I presume that the m16u2 firmware is the same for both UNO and MEGA.

I suppose I could read it out of each m16u2 on each board to verify.

No, I have never found any UART problems with UNO or MEGA hardware and respected PC terminal.
However, both the 'crap' Terminal on AS6.1 and the 'crap' Terminal on AS6.2 are completely unusable. (@9600 baud on Vista-32 or Win7-64)

I can't believe that there is any hardware problem with the m328P or the m2560

115200 baud is not much for any USB driver, or for the 16MHz AVRs. Is your WinXP PC very old or slow?

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I have never found any UART problems with UNO or MEGA hardware and respected PC terminal.

Thanks. That's a very useful data point. More careful testing is clearly needed before pinning the blame firmly on the firmware in the 16U2.

sparrow2 wrote:
how do you tell the 16U2 which baudrate to use?

I assume this is done from the PC end via the virtual COM port driver. If it were wrong, you'd get either nothing, or total gibberish, not mostly correct data with a few dropped characters.

CH
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem seems to be Bray terminal, believe it or not. I'm not sure what happened on the linux setup (and it's not to hand to retry).

On the WinXP machine, Bray terminal (v.1.91b 20140110B) has the following problems:

1) Bray refuses to start when both the FTDI and 16U2 are plugged into USB. It flashes something onto the screen too fast to see and then quits. It starts OK with either of the FTDI or the 16U2 on its own.

2) Whilst Bray is receiving data, the CPU load shoots up to 50%, which on a dual core machine probably means that there is a single thread that never sleeps.

I picked another terminal program at random, which turned out to be RealTerm 2.0.0.70, and this runs and displays data from both USB-serial bridges simultaneously at 250000 baud with no evidence of any dropped characters.

Oooh - while I was typing this Bray terminal just suddenly spontaneously quit and disappeared...

I've been using Bray terminal for years with no problems. I suspect the current version available for download is broken. I'll contact the author.

CH
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bet it isn't Brays itself but the USB driver in the kernel code that's eating 50%

(which was one of Sparrow's points above).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at the COM port Properties of a FTDI Arduino and a 16U2 UNO, the FTDI has monster 4096-byte buffers. The 16U2 driver only has 16-byte FIFO buffer.

Mind you, your PC would have to be badly overstretched to lose bytes with the small FIFO.

Does the AS6.2 Terminal work on other people's PCs?

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It could be a bug in the driver and some weird interaction between the Bray terminal and the driver, but the fact that this other terminal program, RealTerm, seems to work fine with the same cables does seem to point the finger at Bray.

The differing buffer sizes could explain why the FTDI is better, but even that turns out to have been dropping somecharacters at 115200 baud with Bray, and not with RealTerm (even at double that speed).

I've got a slightly older version of Bray on my PC at work so I'll try that for interest.

CH
==

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've noticed Bray's dropping chars in the past.
Especially with large amounts of fast 'bursty' data.

It seemed related to the windows screen update. I noticed if I minimized brays terminal first before sending the data, then nothing was lost.

Just some behavior to be aware of.

-carl

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

H. Carl Ott wrote:
I've noticed Bray's dropping chars in the past.[...] It seemed related to the windows screen update.
Yes, I noticed that too. I am now in touch with Bray, and have mentioned this suggestion.

CH
==