uno USART examples fail due to too high baudrate

[rursprung]

the USART examples for the arduino uno fail when i try to run them. ravedude fails with the following error (note that the first two characters printed come from USART, though already the 2nd one is garbled):

hYthread '<unnamed>' panicked at [...]\ravedude-0.1.6\src\console.rs:34:32:
called `Result::unwrap()` on an `Err` value: Error { kind: InvalidData, message: "Windows stdio in console mode does not support writing non-UTF-8 byte sequences" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

PuTTY doesn't crash but shows a lot of garbled text.

i narrowed it down to the baud rate of 57600. if i switch this to 9600 (obviously both in the code instantiating the serial connection as well as the call to ravedude or in PuTTY) then the problem goes away.

do others have the same issue? i remember that i had this issue before with arduino uno, i think 75600 baud is at the upper limit of what the hardware can handle and using a slower baudrate makes it work more consistently (though slower; but for something as simple as these examples that's irrelevant).

maybe it'd make sense to reduce the default baud rate for the examples?

[Rahix]

Hm, I was even able to get 115200 baud working okay in the past IIRC so I'd expect this to not be too bad. What board and MCU are you using here?

I think there is a second issue here: ravedude shouldn't crash in such situations. We either need to simply remove the unwrap() here: https://github.com/Rahix/avr-hal/blob/f6b79dccbb36808b06f9c5d3e0050dc72ccc25cf/ravedude/src/console.rs#L34C20-L34C20 or implement some sort of input sanitization to ensure we only output correct UTF-8...

[Rahix]

(And off-topic: Are you at 37c3 by any chance? :D)

[rursprung]

What board and MCU are you using here?

i'm using some obscure arduino uno clone called gscheiduino (the manufacturer is also discontinuing it, so i wouldn't recommend it to anyone 😉) which i got from university (i think due to supply chain issues they couldn't get the real arduino unos at the time) running with an atmega328p.

so yeah, maybe this is just an issue of this board?

(And off-topic: Are you at 37c3 by any chance? :D)

no, but i wish you a lot of fun there! 😄

[Rahix]

Hmm, so there is this ugly ugly hack that's needed on some boards to get certain serial baudrates working correctly. Maybe you're hitting some version of that? The code is this one:

avr-hal/avr-hal-generic/src/usart.rs

Lines 130 to 140 in f6b79dc

	// hardcoded exception for 57600 for compatibility with the bootloader
	// shipped with the Duemilanove and previous boards and the firmware
	// on the 8U2 on the Uno and Mega 2560.
	//
	// https://github.com/arduino/ArduinoCore-avr/blob/3055c1efa3c6980c864f661e6c8cc5d5ac773af4/cores/arduino/HardwareSerial.cpp#L123-L132
	if CLOCK::FREQ == 16_000_000 && br.ubrr == 34 && br.u2x {
	// (CLOCK::FREQ / 8 / 57600 - 1) / 2 == 16
	Baudrate::with_exact(false, 16)
	} else {
	br
	}

[rursprung]

Hmm, so there is this ugly ugly hack that's needed on some boards to get certain serial baudrates working correctly. Maybe you're hitting some version of that?

no clue. but if i'm the only one reporting this i'm happy to just ignore it. i'm just playing around a bit with this device, so i don't care if it doesn't run with higher baud rates. i have no intention of using it for anything more serious.

[kallemooo]

The Uno is using a 16 Mhz crystal, and using a 16 Mhz crystal on an AVR causes for example the frequencies 57.6 kbit and 115.2 kbit to be outside of the 1% error normally needed for an UART.
I normally recommend to be below 0.5% error.

To be able to select a good bit rate the Wormfood AVR bit rate calculator is a nice tool.

To get 57.6 kbit below 1% error, U2Xn must be set to 1. It is still above 0.5% so it might not work. 115.2 kbit is not working at all.