Comments (12)
I don't have any immediate idea what might be wrong ... Here's a few questions, maybe we can narrow it down a bit?
- Do the TX and RX leds show any activity? Especially, does TX indicate that the program is sending data as it should?
- What program are you using to connect to the serial console on your host?
- Modify the serial example to continously send some data, then cycle through baudrates on your host. Do you, at any point, see either the output or some gibberish?
from avr-hal.
I've pushed commit 7caed3a ("generic: serial: Fix U2Xn not being reset") to fix your original problem. I'd keep this issue open, though, for discussing the other baudrate mismatch topics ...
from avr-hal.
I'm getting gibberish on serial port.
Ugh, reading is hard; just noticed this ... In that case, this is most likely a baudrate mismatch of some sort. What program are you using on the host to read from the serial console?
from avr-hal.
Thanks! You are right, there were baud rate mismatch. I was able to RX/TX correctly at 19200, despite setting baud rate in code to 9600. With the rate in the code 57600, I was able to connect at 115200. So basically it was always doubled rate. When I've submitted the issue, I've tried only lower baud rates, so wasn't able to find correct one.
I believe there is some issue causing this. I'm happy to help fix it, but need some pointers where to look at.
from avr-hal.
Hm, I think I found something: Please flash a test program, power off the arduino entirely, turn it back on and try again. Will this lead to using the correct baudrate?
Could you also try adding the following patch?
diff --git a/avr-hal-generic/src/serial.rs b/avr-hal-generic/src/serial.rs
index 280f92da1cf1..677ba3841d91 100644
--- a/avr-hal-generic/src/serial.rs
+++ b/avr-hal-generic/src/serial.rs
@@ -57,6 +57,8 @@ macro_rules! impl_usart {
let brr = CLOCK::FREQ / (16 * baud) - 1;
self.p.[<ubrr $n>].write(|w| unsafe { w.bits(brr as u16) });
+ self.p.[<ucsr $n a>].reset();
+
// Enable receiver and transmitter but leave interrupts disabled.
self.p.[<ucsr $n b>].write(|w| w
.[<txen $n>]().set_bit()
If any of the above helps, here's what I suspect: Arduino firmware sets the U2Xn
bit in its serial driver which doubles the configured baudrate. This bit isn't currently cleared in avr-hal
because it should be disabled by default. But maybe in some weird circumstances it might have stayed enabled (or was set by the bootloader?) so you got the behavior you observed. The above patch would fix this by properly disabling the bit every time.
from avr-hal.
Reading into this a bit more, it seems we might want to enable U2Xn
as well:
You should be aware that the Arduino software sets the U2X bit, so the correct UBRR value is 16. This results in a "closer" 115200bps bit rate (2.1% off), which is why it was done. If you use 8 without UX2 set, you'll get 3.7% error IN THE OTHER DIRECTION. The combined error is more than the ~5% that Async can easily tolerate.
Additionally, the above post links to this workaround in Arduino Core:
// 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. Also, The baud_setting cannot
// be > 4095, so switch back to non-u2x mode if the baud rate is too
// low.
if (((F_CPU == 16000000UL) && (baud == 57600)) || (baud_setting >4095))
{
*_ucsra = 0;
baud_setting = (F_CPU / 8 / baud - 1) / 2;
}
Not sure if we should add that ... It is specific to arduino boards and might be entirely wrong for non-arduino usecases. OTOH without it, we might see more baudrate mismatch problems.
from avr-hal.
Please flash a test program, power off the arduino entirely, turn it back on and try again. Will this lead to using the correct baudrate?
I've trurned it off, wait 10+ seconds, and plugged it back. It didn't help.
If any of the above helps, here's what I suspect: Arduino firmware sets the
U2Xn
bit in its serial driver which doubles the configured baudrate.
Looks like this is the case. I've applied the path you provided and it works as expected.
from avr-hal.
Additionally, the above post links to this workaround in Arduino Core
This workaround is exactly for 8U2 serial chip which I have on Arduino Uno rev2. Nowadays, most common is rev3, which have different chip.
from avr-hal.
Looks like this is the case. I've applied the path you provided and it works as expected.
Great to hear, I'll apply this patch properly this evening (hopefully)!
This workaround is exactly for 8U2 serial chip which I have on Arduino Uno rev2. Nowadays, most common is rev3, which have different chip.
Okay, maybe you can do some tests to see how unstable our current settings are? E.g. if you try using 115200 baud, does it work reliably?
from avr-hal.
115200 with patch applied is totally unreliable, I receive broken data.
57600 with patch applied is reliable, can send and read data.
115200 without patch (57600 set in the code, 2*57600 = 115200 in terminal) is reliable, I can send and read received data.
from avr-hal.
Ok, at least that's in line with what I'd expect after reading about the Arduino implementation ...
from avr-hal.
Let's close this issue here and continue the baudrate topic in #80 where I've started to outline possible solutions.
from avr-hal.
Related Issues (20)
- Panic while trying to write to serial using `ufmt::uwriteln` HOT 4
- Add configurable board options to ravedude HOT 3
- Get pin number HOT 6
- Program freezes if compiled in debug mode.
- ravedude should check rust target against selected MCU HOT 3
- Document clock type design in more detail HOT 1
- cargo build - error[E0658] - proc_macro::Literal::byte_character(byte) HOT 9
- can't find crate for `core` HOT 12
- cargo build - error[E0658] - proc_macro::Literal::byte_character(byte) HOT 4
- Very weird error when compiling a very basic program: __addsf3 multiple defenitions HOT 9
- Ravedude freezes on programmer uploading HOT 5
- Arduino Nano: avrdude error: programmer is not responding HOT 11
- Watchdog intterupt mode HOT 1
- [Solved] Cannot find `pwm` in `embedded_hal` HOT 2
- peripherals type alias HOT 2
- Enhance `avr_hal_generic::renamed_pins! {}` to also generate type aliases for each pin
- tier 3 target and broken HOT 6
- Utilising the `atmega2560`'s "USART in SPI Mode" HOT 10
- Issue with math calculations with floats to serial port output HOT 6
- Incorrect ADC readings after toolchain bump HOT 15
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from avr-hal.