-
|
As requested, reposted in the correct section. ContextI'm attempting to make the SG90 servo motor to work with the arduin_hal crate. What I've done so farAs far as I've figured out, the main issue with the This is what I figured out so far to get a decent resolution on the atmega2560:
//! # Servo
//!
//! Servo interface for the Arduino Mega 2560 board.
//!
//! ## Servo control
//!
//! * 20 ms PWM period required = 50 Hz
//! * Control range: 0.5 to 2.5 ms for a 0 to 180 degrees rotation.
//!
//! ## Arduino Mega2560 interface
//!
//! * Timer/Counters
//! * TC0: 8-bit
//! * TC1: 16-bit
//! * TC2: 8-bit
//! * TC3: 16-bit
//! * TC4: 16-bit
//! * TC5: 16-bit
//!
//! ### 16-bit Timer/Counter application
//!
//! #### Prescaler selection
//!
//! Best possible control resolution (Direct clock, no prescaler):
//! * 16 bit register = 2^16 = 65 536 maximum range for TOP.
//! * Prescaler:
//! * Direct: 16 MHz = 62.5 ns per clock tick --> 4 ms maximum cycle time.
//! * Prescale8: 16M/8 = 2 MHz = 0.5 us per clock tick
//! * 32.8 ms maximum cycle time
//! * Resolution: 180 degrees in 4000 steps = 0.045 degrees per step.
//! * Prescale64: 16M/64 = 250 kHz = 4 us per clock tick
//! * 262 ms maximum cycle time
//! * Resolution: 180 degrees in 500 steps = 0.36 degrees per tick.
//!
//! #### PWM configuration
//!
//! We want to achieve a 50 Hz PWM period. We'll use WGM mode 14 as with this mode
//! we're able to set TOP using ICRn. That will define the overall PWM frequency.
//! The duty will be set using the channel output compare OCRnx.
//!
//! The desired frequency calculation is defined in ATMega docs on page 148:
//!
//! f<sub>OCnxPWM</sub> = f<sub>csl_I/O</sub> / (N * (1 + TOP))
//!
//! where:
//! * f<sub>clk_I/O</sub> is the system clock frequency in Hz (16e6 Hz).
//! * f<sub>OCnxPWM</sub> is the PWM frequency in Hz.
//! * N is the prescale factor (1, 8, 64, 256 or 1024).
//!
//! ##### Prescale8
//!
//! To achieve a 50 Hz PWM frequency with Prescale8, we need to set TOP to 39 999 (0xC34F).
//!
//! ##### Prescale64
//!
//! To achieve a 50 Hz PWM frequency with Prescale64, we need to set TOP to 4 999 (0x1387).
//!
//! * TOP: 5003 = 0x138B
//!
//! We'll choose for Fast PWM with TOP set by ICRx (1, 3, 4 or 5).
//! OCRnx will be used to set the duty cyle.
//!
//! Control range with prescale64:
//! * 0.5 ms = 125 ticks
//! * 2.5 ms = 625 ticks
//! --> This is actually not possible using the internal clock?
After that I figured out that I should just set the registers properly to use FastPWM mode 14, which uses register ICRn to set TOP and then use registers OCRnA OCRnB or OCRnC to define the duty cycle. 
fn main() -> ! {
let dp = arduino_hal::Peripherals::take().unwrap();
let pins = arduino_hal::pins!(dp);
// let mut serial = default_serial!(dp, pins, 115200);
// let _ = debug_dump(&mut serial, &dp.TC1);
// pin 11 PWM setup TC1 channel A
let tc1 = dp.TC1;
tc1.tccr1a().reset();
tc1.tccr1b().reset();
tc1.tccr1c().reset();
// Compare mode set-up in register TCCR1A
// - bits 7:6 - COM1A1:0 = Output compare mode for OC1A (for channel A)
// - bits 5:4 - COM1B1:0 = Output compare mode for OC1B (for channel B)
// - bits 3:2 - COM1C1:0 = Output compare mode for OC1C (for channel C)
// WGM 1110 => (wgm bits 0 and 1 go in register A, bits 2 and 3 go in register B) FastPWM with ICRn to define TOP and OCRNX to define compare output.
tc1.tccr1a().write(|w| unsafe {w.com1a().bits(0b10).wgm1().bits(0b10)}); // non-inverting mode Compare output mode for fast-pwm
tc1.tccr1b().write(|w| unsafe {w.wgm1().bits(0b11).cs1().prescale_8()});
// Setting TOP to IRC1 to achieve 50 Hz cycle.
tc1.icr1().write(|w| w.set(39999u16));
// Setting output compare on channel C to define the PWM duty cycle.
tc1.ocr1a().write(|w| w.set(4000u16));
// Toggle pin 11 to output the OC3A output.
pins.d11.into_output();
loop {}
}Driver implementationI'm attempting to generalise my code as much as possible into a driver. First method - Extending
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
Hi! First of all, welcome here :) You've taken up quite the challenge, these generic safety-through-typing abstractions are really hard to get right and require a lot of Rust and Rust macro wizardry... If you just care about your specific application, I think it would be entirely reasonable to just wrap your code into a struct and be done with it: pub struct PwmServoMotor {
pin: Pin<Output, PB5>,
timer: TC1,
}The next step up is making this work for all timers and output pins. The code skeleton you've shown in your second method goes into the right direction. But you will need to implement this for a ton of timer/pin combinations so there really isn't much choice but to write a macro for it. And this is where things start to get unwieldy... Essentially you have to do what was done in the avr-hal/mcu/atmega-hal/src/simple_pwm.rs Lines 1 to 1193 in e5c8f37 Regarding your first method: I wouldn't extend the // With explicit driver struct
let servo_driver = avr_servo_driver::PwmServoMotor::new(
dp.TC1,
pins.pb5.into_output(),
);
// With extension trait, which you explicitly have to import
use avr_servo_driver::PinExt as _;
let servo_driver = pins.pb5.into_pwm_servo(dp.TC1);I think the first option is much easier to read and understand. With all that out of the way, one more thing: Using a timer for servo control is nice because it happens entirely off-cpu. But it limits you to how many servos you can control. That's why, for example, the official Arduino C++ servo library instead just uses a timer to schedule an interrupt for updating an arbitrary number of GPIO output pins. This allows creating as many servos as you want from a single timer peripheral. At the cost of a bit more CPU time, of course. |
Beta Was this translation helpful? Give feedback.
-
|
Many thanks for all the information! It's quite a challenge yes, but a good opportunity to go in depth on how embedded systems work. Since I'm putting in the effort and I'm using so much of community info and tools, I figured that turning it into a crate may be a nice return to the community if it ends up being used 😃 I think I'll go with the explicit struct method and then indeed go on and write a macro for it. I may be back for more questions later on in the process. Let's see where I get first 😄 There may be a first question though: If I want to test on different chipsets, I suppose QEMU is the way to go. But do you have a reference on how to test PWM signal output when using QEMU? I'm googling but haven't found something useful yet (which surprises me, so it may be that I'm using the wrong terminology) |
Beta Was this translation helpful? Give feedback.
-
|
For simulation, I've always used You may find @Patryk27's https://codeberg.org/pwy/avr-tester interesting. But to be honest, I would not try simulating hardware interaction too much. There are too many variables, making simulation results an unreliable indicator of whether the real hardware works. I would always test with real hardware and rather build a test-harness around a real board than to use simulation. |
Beta Was this translation helpful? Give feedback.
Hi! First of all, welcome here :)
You've taken up quite the challenge, these generic safety-through-typing abstractions are really hard to get right and require a lot of Rust and Rust macro wizardry...
If you just care about your specific application, I think it would be entirely reasonable to just wrap your code into a struct and be done with it:
The next step up is making this work for all timers and output pins. The code skeleton you've shown in your second method goes into the right direction. But you will need to implement this for a ton of timer/pin combinations so there really isn't much choice but to write a m…