Utilising the `atmega2560`'s "USART in SPI Mode" about avr-hal

[Rahix]

whilst also preventing usage of the USART for USART purposes.

This part is actually very simple. The UsartSpi driver constructor consumes the USART peripheral, just like the current UART driver consumes it. Due to Rust's ownership rules, this means only one of the two can ever exist:

    let dp = atmega_hal::Peripherals::take().unwrap();
    let pins = atmega_hal::pins!(dp);
    let mut serial = Usart::new(
        dp.USART0, // <- USART0 is moved into `serial` here
        pins.pe0,
        pins.pe1.into_output(),
        Baudrate::<crate::CoreClock>::new(57600),
    );

    let mut spi = UsartSpi::new(dp.USART0, ...);  // <- compiler error because USART0 was moved previously and is no longer available

[Rahix]

I'd create a completely new module for USART as SPI. usart_spi I guess.

[Rahix]

Yes, this isn't supported yet.

If anyone is interested in working on a "USART as SPI" driver and needs guidance on how to do this, feel free to ping me!

[CoolSlimbo]

I'll gladly give this a shot in implementation, if you could aid a hand in the direction it needs to go in!

Currently, my confusion is just on how one would implement it, whilst also preventing usage of the USART for USART purposes.

[Rahix]

if you could aid a hand in the direction it needs to go in!

Generally, you'll need to add a usart_spi module in avr-hal-generic, similar in structure to the existing spi or usart modules. This defines the generic UsartSpi driver and a macro for the MCU-specific HALs. This macro is then instanciated in atmega-hal to implement USART as SPI for the available USART peripherals.

[CoolSlimbo]

Roger on that. I do see that now, I was over-engineering that way to much...

I'll get to work on implementing the driver, however, would this preferred to be in the USART or SPI module?