SPI pins are no longer optional

[bugadani]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs API guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

Since we already have DummyPin (now NoPin), let's replace the remaining uses of Option with it.

cc #1318
Closes #2006

[Dominaezzz]

Not a blocker for this PR (This problem already exists with or without this PR anyway) but I thought it's worth mentioning that using NoPin for peripheral input is interesting since you have to choose between 0 or 1 internally. 0 makes sense for some signals and 1 makes sense for others.
I'm not sure how best to express this, maybe a big match table I guess.

Perhaps it's best to wait until someone complains that a driver doesn't work right when using NoPin. 😂

[bugadani]

I guess we should direct users to prefer Level if they can - but NoPin (or something else) needs to implement both PeripheralInput and PeripheralOutput because some peripheral signals need both (e.g. half-duplex SPI data).

I think I would like to avoid a big table but the idea of mapping InputSignal to Level is a good worst case fallback. Do you happen to have an example peripheral/signal in mind? Or did I hit a jackpot with QSPI failures? :D :D

[Dominaezzz]

I guess we should direct users to prefer Level if they can

Yeah that's probably best.

Or did I hit a jackpot with QSPI failures? :D :D

😂

but NoPin (or something else) needs to implement both PeripheralInput and PeripheralOutput because some peripheral signals need both (e.g. half-duplex SPI data).

Ahhh, I had completely missed this. Fair enough

Do you happen to have an example peripheral/signal in mind?

SPI slave CS pin should probably have a default of 0, otherwise the peripheral is useless.
SD/MMC card detect pin should probably be 1 so the hardware doesn't complain about the card being missing.
SD/MMC write protect pin should probably be 0 since by default cards should be read/write.
LCD_CAM ctrl signals should be 1 by default otherwise the peripheral won't work. (A bit awkward if the user enables signal inversion in the peripheral but that's out of scope for this I think)
Same story I2S camera mode ctrl signals.

I can't think of more ATM but these are what I have in mind.

[bugadani]

SPI slave CS pin should probably have a default of 0, otherwise the peripheral is useless.
SD/MMC card detect pin should probably be 1 so the hardware doesn't complain about the card being missing.
SD/MMC write protect pin should probably be 0 since by default cards should be read/write.
LCD_CAM ctrl signals should be 1 by default otherwise the peripheral won't work. (A bit awkward if the user enables signal inversion in the peripheral but that's out of scope for this I think)
Same story I2S camera mode ctrl signals.

Thanks. If any of these is bidirectional, that's a blocker and I don't see a good way around it that doesn't suck in some way.

[Dominaezzz]

They're all input only.

[MabezDev]

Thanks!

[JurajSadel]

Thanks!