Should the Spi new function take ownership of the spi pins?

[JoNil]

It feels a bit weird that they are left hanging

let _spi_sclk = pins.gpio6.into_mode::<FunctionSpi>();
let _spi_mosi = pins.gpio7.into_mode::<FunctionSpi>();
let _spi_miso = pins.gpio4.into_mode::<FunctionSpi>();
let mut spi = Spi::<_, _, 8>::new(pac.SPI0).init(
    &mut pac.RESETS,
    SYS_HZ.Hz(),
    16_000_000u32.Hz(),
    &MODE_0,
);

Compare to i2c:

let sda_pin = pins.gpio18.into_mode::<FunctionI2C>();
let scl_pin = pins.gpio19.into_mode::<FunctionI2C>();

let mut i2c = I2C::i2c1(
    peripherals.I2C1,
    sda_pin,
    scl_pin,
    400.kHz(),
    &mut peripherals.RESETS,
    125_000_000.Hz(),
);

If this is desired i can implement it!

[9names]

Yeah, it probably should - though we need to handle the case where the user doesn't want mosi (for a read-only device) or miso (for a write-only device). Also, thanks for the reminder that I should update the i2c doc example to use into_mode(), since it's even cleaner when you do

let mut i2c = I2C::i2c1(
    peripherals.I2C1,
    pins.gpio18.into_mode(),
    pins.gpio19.into_mode(),
    400.kHz(),
    &mut peripherals.RESETS,
    125_000_000.Hz(),

I wanted the main example to do things explicitly but for the doc example being concise is more important.

[chmanie]

The stm32f1xx-hal provides NoMosi and NoMiso filler types which I find quite handy: https://docs.rs/stm32f1xx-hal/0.7.0/stm32f1xx_hal/spi/struct.NoMosi.html

Would that be something you'd like to see here as well?

[jannic]

This has been solved a while ago, Spi now takes ownership of the pins:

let sclk = pins.gpio2.into_function::<FunctionSpi>();
let mosi = pins.gpio3.into_function::<FunctionSpi>();

let spi_device = peripherals.SPI0;
let spi_pin_layout = (mosi, sclk);

let spi = Spi::<_, _, _, 8>::new(spi_device, spi_pin_layout)
    .init(&mut peripherals.RESETS, 125_000_000u32.Hz(), 16_000_000u32.Hz(), MODE_0);