No implementation for SAI I2S

[mtthw-meyer]

As far as I can tell the only implemented functionality for SAI is PDM. The daisy uses SAI I2S for audio I/O to the codec chip. If I can figure it out I may take a shot at implementing it myself.

[richardeoin]

Yes that's correct. A I2S implementation would be great, and I'd be happy to review it. mod/sai.rs contains some functions that are common across all interfaces supported by the SAI, so those should be useful.

There are I2S traits proposed to embedded-hal by @eldruin. They are somewhat similar to the SPI traits, so you can looks at those for reference. A final implementation of those traits will require upgrading to embedded-hal v1.0, but for a prototype I would avoid that.

[eldruin]

There is also a branch of the i2s traits based on embedded-hal 0.2.x which you could use for now so that you do not need to deal with all the 1.0 breakage: i2s-v0.2.x

[mtthw-meyer]

Ok. I'll start there. I'm sure I'll have more questions once I figure out what to ask.

[maxekman]

FYI: I'm (slowly) working on a reference/POC implementation of I2S for the STM32 F4xx (https://github.com/maxekman/stm32f4xx-hal/tree/i2s) with a running demo for the 407G Discovery (https://github.com/maxekman/stm32f407g-disc/tree/dac-support-with-cs43l22). I'll definitely be interested in having/adding support for I2S and SAI for this platform eventually, as that is what I plan to use in a project later on.

[mtthw-meyer]

So far I've gotten an I2S passthru working (sans DMA) and added a split for the DMA channels. Doing a proper safe DMA implementation is beyond what I'm able to do in Rust currently so I'm thinking I just hack something together that works in my daisy library for now and see if I can get anything DMA working.

https://github.com/mtthw-meyer/stm32h7xx-hal/tree/sai-i2s-v0.2.x-1

[richardeoin]

@mtthw-meyer I'd be up for having a sans-DMA I2S implementation PR now. What do you think? I agree that DMA will take several attempts / be complex as you say, so I think makes sense to get basic I2S in the HAL separately.

[mtthw-meyer]

Yes, that seems like a good plan. I'll fill ot the I2S a bit more and macro the rest of the SAI2-4.

[richardeoin]

Great! There are a number of different pins that can be used for I2S, I think this is the full list:

pins! {
    SAI1:
        MCLK_A: [
            PE2<Alternate<AF6>>,
            PG7<Alternate<AF6>>
        ]
        SCK_A: [
            PE5<Alternate<AF6>>
        ]
        FS_A: [
            PE4<Alternate<AF6>>
        ]
        SD_A: [
            PB2<Alternate<AF6>>,
            PC1<Alternate<AF6>>,
            PD6<Alternate<AF6>>,
            PE6<Alternate<AF6>>
        ]
        MCLK_B: [
            PF7<Alternate<AF6>>
        ]
        SCK_B: [
            PF8<Alternate<AF6>>
        ]
        FS_B: [
            PF9<Alternate<AF6>>
        ]
        SD_B: [
            PE3<Alternate<AF6>>,
            PF6<Alternate<AF6>>
        ]
    SAI2:
        MCLK_A: [
            PE0<Alternate<AF10>>,
            PI4<Alternate<AF10>>
        ]
        SCK_A: [
            PD13<Alternate<AF10>>,
            PI5<Alternate<AF10>>
        ]
        FS_A: [
            PD12<Alternate<AF10>>,
            PI7<Alternate<AF10>>
        ]
        SD_A: [
            PD11<Alternate<AF10>>,
            PI6<Alternate<AF10>>
        ]
        MCLK_B: [
            PA1<Alternate<AF10>>,
            PE6<Alternate<AF10>>,
            PE14<Alternate<AF10>>,
            PH3<Alternate<AF10>>
        ]
        SCK_B: [
            PA2<Alternate<AF8>>,
            PE12<Alternate<AF10>>,
            PH2<Alternate<AF10>>
        ]
        FS_B: [
            PA12<Alternate<AF8>>,
            PC0<Alternate<AF8>>,
            PE13<Alternate<AF10>>,
            PG9<Alternate<AF10>>
        ]
        SD_B: [
            PA0<Alternate<AF10>>,
            PE11<Alternate<AF10>>,
            PF11<Alternate<AF10>>,
            PG10<Alternate<AF10>>
        ]
    SAI3:
        MCLK_A: [
            PD15<Alternate<AF6>>
        ]
        SCK_A: [
            PD0<Alternate<AF6>>
        ]
        FS_A: [
            PD4<Alternate<AF6>>
        ]
        SD_A: [
            PD1<Alternate<AF6>>
        ]
        MCLK_B: [
            PD14<Alternate<AF6>>
        ]
        SCK_B: [
            PD8<Alternate<AF6>>
        ]
        FS_B: [
            PD10<Alternate<AF6>>
        ]
        SD_B: [
            PD9<Alternate<AF6>>
        ]
    SAI4:
        MCLK_A: [
            PE2<Alternate<AF8>>
        ]
        SCK_A: [
            PE5<Alternate<AF8>>
        ]
        FS_A: [
            PE4<Alternate<AF8>>
        ]
        SD_A: [
            PB2<Alternate<AF8>>,
            PC1<Alternate<AF8>>,
            PD6<Alternate<AF8>>,
            PE6<Alternate<AF8>>
        ]
        MCLK_B: [
            PF7<Alternate<AF8>>
        ]
        SCK_B: [
            PF8<Alternate<AF8>>
        ]
        FS_B: [
            PF9<Alternate<AF8>>
        ]
        SD_B: [
            PE3<Alternate<AF8>>,
            PF6<Alternate<AF8>>
        ]
}

[mtthw-meyer]

Draft up at #99.

[mtthw-meyer]

Currently this is implementing the trait FullDuplex with a Word type of u32. Would i32 be more appropriate for sound data? I know the codec chip on the daisy board uses S24.