I’m trying to hook up an ftdi ft232r usb->serial chip to my atmega168. I’ve done this for numerous past projects, all of which only received a couple bytes at a time from the computer side of things. My current use requires me to send up to 300 bytes in some instances. The problem I’m running into is that I’m getting framing errors when I try and send a stream of characters from the computer to the controller. I’ve seen many posts of people saying you need to pause between messages, and while I admit this has solved the problem in the past for me, the fact is that according to the datasheets you shouldn’t have to pause. I’m setting up the serial communication on the computer side using the termios.h structures. I’m running the uart baud rate at 115200, and using an external crystal at 18.432 Mhz.
I took a look at the data line coming from the ft232r to the atmega with an oscilloscope, but I really need a logic analyzer to make sense of it. I know other people have run into this issue, anyone figure it out without putting the pause in the program? I don’t wanna go into details on why that’s not an option, but suffice it to say that it’s not.
update: I realized I was looking at the wrong data line for the ft232 to the atmega on the scope. (stupid mistake). Now that I’m looking at the right one, I see that the bit stream is perfect going into the atmega. So I can rule out any errors on the computer side, or the ft232 chip. The problem has to be with the atmega. At 2 bytes, I get no framing errors, at 3 it’s very rare, and at 4+, it’s every time. However, even at 4 bytes, the bitstream is perfect going into the controller, all stop bits and star bits are present, but I still get framing errors, not on every byte though. I’m using peter fleury’s uart library on the atmega, which uses the receive interrupt to place data into a linked list buffer. I have a lot of other interrupts going as well, but the time to process one byte from the receive interrupt should be small. And if that was the problem, I would think I would get buffer overrun errors, not framing errors. Any ideas? Anyone???
115Kbaud is pressing your luck in many regards, starting with baud rate error vs. ideal, crystal inaccuracies.
And the famous one:
Transmitter sends constantly, back to back bytes.
Receiver loses frame synch. All it needs is two stop bits to re-synch. But the protocol is 8N1.
And receiver’s firmware must be coded correctly and execute quickly.
I have to disagree with you on 115k baud pushing my luck. It’s the baud rate that is used on the monome, with nearly the same ftdi chip and uC. Also, according to the datasheets this is well within the limits when using an 18.423 Mhz crystal. As for the stop bits, I am sending two just to be safe, but it doesn’t solve the problem, and truthfully, it shouldn’t make a difference. Many people send packets over 100 bytes and don’t have an issue, it’s often a quick fix to add a delay between bytes, but it’s really avoiding the problem, and the problem is fixable. I think this conversation would be better suited for the avr forums, so I posted there instead. If anyone’s interested in the results go here:
http://www.avrfreaks.net/index.php?name … ic&t=94333