-
I run the timer0 on 328p in normal mode with 1024 prescaler to get 15625 ticks periods. #![no_std]
#![no_main]
#![feature(abi_avr_interrupt)]
use arduino_hal::prelude::*;
use panic_halt as _;
#[arduino_hal::entry]
fn main() -> ! {
let dp = arduino_hal::Peripherals::take().unwrap();
let pins = arduino_hal::pins!(dp);
let mut serial = arduino_hal::default_serial!(dp, pins, 57600);
dp.TC0.tccr0a.write(|w| unsafe { w.bits(0) }); // Ensure normal mode selected.
dp.TC0.tccr0b.write(|w| w.cs0().prescale_1024()); // 16m / 1024 = 15_625
loop {
let tick = dp.TC0.tcnt0.read().bits();
ufmt::uwriteln!(&mut serial, "TICK: {}", tick).unwrap_infallible();
}
} The serial output skips some of the values:
When I lower the printing freq I get a somewhat more adept result:
And finally if I lower the resolution with
And I also confirm this with other mod values like 26, 33 etc. and I'm sure the values are there but serial output slows down the CPU so much that I can't print every value in real-time. My question: is there a quicker way to print these values to serial console than using |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Serial (UART) is unfortunately inherently very slow. You are sending data at 57600 baud which means each character takes at least 190µs. You can add that up for the messages you are sending, it should pretty closely match the timer increments you see. You cannot speed this up, the serial protocol is just this slow by design.
|
Beta Was this translation helpful? Give feedback.
Serial (UART) is unfortunately inherently very slow. You are sending data at 57600 baud which means each character takes at least 190µs. You can add that up for the messages you are sending, it should pretty closely match the timer increments you see. You cannot speed this up, the serial protocol is just this slow by design.
ufmt::uwriteln!()
usesUsart::write_byte()
under the hood which synchronously sends out one byte of data. You could instead enqueue your data to be sent into a ring buffer and then transmit the next byte each time theUsart
fires itsDataRegisterEmpty
interrupt. This would at least not block your program during transmission, but you cannot send any more data this way …