`UsartSpi` Support

[CoolSlimbo]

PR regarding issue #561.

This is just so I have the PR made for now, work still needs to be made on it.

So far, USART0 is implemented for most of the atmega mc's. However, they are not tested, as I am lacking something to test it with.

[stappersg]

Idea, maybe a wild idea: The new code in one #[cfg(any( ))] block?

Anyway: Success with testing.

[CoolSlimbo]

Wait. It actually worked on hardware? Part of me is surprised lol

I'll probably move it into its own module, but can't use one config, because they align to different ports between devices.

[CoolSlimbo]

Currently added in (I think) at minimum all the USART0 implimentations. But there's still a large portion to go, and finding the XCK pin requires getting the datasheet for each.

[CoolSlimbo]

Implements USART, correctly, on all devices. Should past CI successfully.

An example could be in order, however, I am lacking any SPI slaves, so I cannot test this myself.

[Rahix]

An example could be in order, however, I am lacking any SPI slaves, so I cannot test this myself.

SPI can be tested very easily by looping back MOSI to MISO (so TX to RX in this case). We also have this in our real SPI example, maybe it makes sense to add an example that does the same for UsartSpi?

[Rahix]

Hey, there seem to be some compiler errors, as seen in CI. Can you take a look?

[armandas]

I went on and tested the atmega2560-usart_spi-feedback example. I tested USART1, USART2 and USART3 and they all work. USART0 is connected to USB, so I did not test that.

My diff to get it to compile:

diff --git a/examples/atmega2560/src/bin/atmega2560-usart_spi-feedback.rs b/examples/atmega2560/src/bin/atmega2560-usart_spi-feedback.rs
index 3a2d145..bce2ad4 100644
--- a/examples/atmega2560/src/bin/atmega2560-usart_spi-feedback.rs
+++ b/examples/atmega2560/src/bin/atmega2560-usart_spi-feedback.rs
@@ -36,12 +36,12 @@ fn main() -> ! {

     // Create SPI interface.
     let (mut spi, _) = usart_spi::Usart1Spi::new(
-        dp.SPI,
+        dp.USART1,
         pins.pd5.into_output(),
         pins.pd3.into_output(),
         pins.pd2.into_pull_up_input(),
         pins.pd4.into_output().downgrade(),
-        spi::Settings::default(),
+        atmega_hal::spi::Settings::default(),
     );

     loop {

Other configs, for reference:

USART2:

    let (mut spi, _) = usart_spi::Usart2Spi::new(
        dp.USART2,
        pins.ph2.into_output(),
        pins.ph1.into_output(),
        pins.ph0.into_pull_up_input(),
        pins.pd4.into_output().downgrade(),
        atmega_hal::spi::Settings::default(),
    );

USART3:

    let (mut spi, _) = usart_spi::Usart3Spi::new(
        dp.USART3,
        pins.pj2.into_output(),
        pins.pj1.into_output(),
        pins.pj0.into_pull_up_input(),
        pins.pd4.into_output().downgrade(),
        atmega_hal::spi::Settings::default(),
    );

[armandas]

@Rahix I was wondering if it would make sense to re-export configuration structs and enums defined in spi from usart_spi?

[Rahix]

I was wondering if it would make sense to re-export configuration structs and enums defined in spi from usart_spi?

To be honest, I would prefer not to add such re-exports. The more paths there are to reach an item the more convoluted user code will get.