Following up on the recent fast serial sendin thread, I was playing around the Firmata and noticing that a lot of bytes never get thru when running at 115200 baud. I see the Tx LED flash on the Arduino for each byte, but the program doesn't get the bytes a lot of the time. When I switched the baud rate to 57600 and no other changes, it seems to get every byte.
The dtools people seem to have similar experience with 115200 baud on the Arduino, but say that they got 115200 working at 8E1 or 8N2. Serial.begin() doesn't provide those options, unfortunately.
I get lots of comm. errors at 115.2k with parity NONE (8N1), but comm. seems to work with any parity scheme or a second stop bit. Hypothesis: we have some slight timing problems and need to add one extra bit per byte sent to the ATmega8.
Also, I noticed that they seem to be using uart.h from AVR LIB, which provides circular buffers on Tx and Rx. Perhaps this would be useful for Arduino.
Hmm... that's definitely a problem we need to fix. Do you have a sketch that demonstrates the problem?
We were using the uart files from AVR LIB, but because they offer much more flexibility then we need in Arduino (or expose in the API), they were adding a lot of space to the core Arduino libraries. It might be worth, however, using a circular buffer on transmit, too, to see if maybe that fixes the problem of dropped bytes.
I tried a simple sketch (code below) and didn't see any dropped bytes (in either the Arduino serial monitor or screen). What program were you talking to? What sketch were you using?
int c = 0;
void setup()
{
Serial.begin(115200);
}
void loop()
{
Serial.print('A' + c, BYTE);
c = c + 1;
if (c == 26) {
Serial.println();
c = 0;
}
}
I don't have one packages up neatly yet, but I will make one. I haven't tried much with one-way communications, it's always been with a back and forth, and usually with a lot of traffic.
That would be great. I'll try to play with back-and-forth communications if I have time, but having a sketch illustrating the problem would definitely speed up the process.
you either need to use a different baudrate like 76800 or replace the crystal (xtal) with one which allows generating the 'exact' right baudrate of 115200. 16mhz (default on most arduino) gives
3.7% error, which usually is too much for the other side to work without error correction.
the usart in the avr (arduino cpu) generates the baudrate by prescaling (dividing) its cpuclock from the crystal by a calculated value (UBRR), which can only be a int, not a float.
My setup communicates over 1k of data at 115200 without ever missing a beat (once a minute for the past 8 months). Its quite a large sketch (14.6k, too big for a 168) but since much of it is time critical, it doesn't use any delays. It does use an interrupt though. It works without issue on 3 different genuine Arduinos. It might go screwy if I attempted to use one of my cheap homebrews with ceramic resonators though. The crystals in my arduinos keep time to within a second a day which may or may not be typical.