Having an problem with the 14400 baud rate on an Mega Board.
With Serial1 Tx Connected to Rx the following code works on 9600 and 19200 baud rates
but on 14400 the pulse width varies from bit to bit (from 50 to 100 uSec)
void Setup()
{
Serial.begin(14400);
Serial1.begin(14400);
}
void loop()
{
if( Serial.available())
{
int inByte = Serial.read();
Serial1.write(inByte);
}
if(Serial1.available())
{
int inByte = Serial1.read();
Serial.write(inByte);
}
}
T3bear:
on 14400 the pulse width varies from bit to bit (from 50 to 100 uSec)
How did you arrive at that conclusion?
I was watching the input and output pulses on a scope. The pulse width seems to right and consistent for 9600 and 19200 baud.
More Information->
I modified the code to send and receive on Serial. only at 14400 baud
loop()
{
if(Serial.available()
{
int inbyte = Serial.read();
Serial.write(inbyte);
}
}
Results->
Using the Serial Monitor->
sending 'r' or 'y' the return is 'r' or 'y'
sending 'R' or 'Y' the return is 'r' or 'y'
Upper case is returned as lower case
sending a string of characters return trash
again other baud rates work fine
I recall some trouble with 57600 baud .. but no other.
Which IDE are you using 1.0, 0.22, 0.23?
have you tried another version of the IDE?
I am using IDE 1.0, will give another a try. Thanks
I tried IDE 0022 and got the same results
Also tried 3 different Mega boards
and 3 different Uno boards
14400 baud always the problem.
What is the full frame time (start bit to stop bit) of a byte leaving the processor (pin 1 on the Uno)?
Transmitting a zero will make the measurement easier...
void loop( void )
{
Serial.write( (byte)(0x00) );
delay( 1000 );
}
Overall byte times @ 14400 baud>
Overall time of a byte from PC/SerialMonitor = 875 uSec
Overall time of a byte from UNO to PC/SerialMonitor = 835 uSec
The transmitted bits from the UNO are shorter than the bits from the PC
What frame time do you get at 9600 baud? What about 19200?
When sending a zero byte, is the frame is a continuous low signal?
New byte times for 14400 baud:
The Uno Tx pin is high is goes low for 625 uSec then return high(the previous value was in error)
on incoming from PC the Rx is high and goes low for 725 uSec before returning high
For 9600 baud
Tx time = 975 uSec
for 19200 Buad
Tx time = 460 uSec
T3bear:
New byte times for 14400 baud:
The Uno Tx pin is high is goes low for 625 uSec then return high(the previous value was in error)
Perfect match (625.5us is the expected value).
on incoming from PC the Rx is high and goes low for 725 uSec before returning high
Corresponds to 12413.8 baud.
Good news: The code on the Uno is correct. Bad news: The code on the ATmega16U2 has a bug.
what is the next step?
unrelated question:
Is it possible to read/write a block (8 bits) of digital ports in one command?
Thanks for your help
unrelated question
Yes it is called direct port manipulation - Arduino Reference - Arduino Reference -
T3bear:
what is the next step?
If you want it fixed quickly, you will probably have to do it yourself (or hire someone). I believe the problem is with the SERIAL_2X_UBBRVAL macro called here...
https://github.com/arduino/Arduino/blob/master/hardware/arduino/firmwares/arduino-usbserial/Arduino-usbserial.c#L209
If you want the problem fixed in future boards, I suggest reading how others have sought redress..
At a minimum, please report the problem here (include a link to this topic)...
http://code.google.com/p/arduino/issues/list
If you remain unsure how to proceed, report back. Maybe someone else can offer better advice then I've given.
I believe the problem is with the SERIAL_2X_UBBRVAL macro
how do you figure? The 57600bps special case was because the bootloader (which is "hard" to change) was using 57600 (as close as possible) without the "double-speed" option, while the usb/serial device was using 57600 as close as possible WITH the u2x option, and they were on opposite sides of "correct", making them far enough apart to not talk to each other (even though theoretically, each was with "allowable" tolerance WRT the actual bitrate.
The mega should talk fine to its own usb/serial port, because they should have consistently picked "which side" of 14400to be on, and other devices (most other devices) should be OK if they're closer to correct.
And I can't think of a reason why a serial port couldn't talk to itself or another serial port on the same arduino (with the same bitrate generator decisions), EVER, even if the resulting bitrate were WAY off of what was expected (it should still be the same for receiver and transmitter.)
westfw:
how do you figure?
You have point. The problem could also be in the USB handler of the ATmega8U2.
The mega should talk fine to its own usb/serial port, because they should have consistently picked "which side" of 14400to be on, and other devices (most other devices) should be OK if they're closer to correct.
I agree. But that's not the issue...
The sketch tries to set the ATmega328 baud rate to 14400. The evidence indicates that worked.
Serial Monitor tries to set the ATmega8U2 baud rate to 14400. The evidence indicates that did not work.
It this on Linux?
In my case it's Vista / 32 bit / Arduino 1.0-rc2. (Thank you for the dependency check feature!)
My apologies. The bug is in Serial Monitor not in the ATmega8U2.
@T3bear: Just use a different terminal program.