Support QSPI for Wiznet W6300

[KingCol13]

Closes #4662 - builds on @lhalf's work.

This is quite messy but I'm making an early draft PR for visibility and potential feedback on the design. There's some parts that should be split out into other PRs.

Design

• Add QspiDevice and QspiBus traits in the style of embedded_hal_async.
  • The difference with the regular Spi* traits is the WriteSingleLine operation and no Transfer or TransferInPlace.
  • These should probably be upstreamed to embedded_hal_async if they make sense.
  • This is my first time writing a QSPI driver so I'm not sure whether QSPI is standardised enough for a trait to exist - after a quick search it looked like most QSPI operates like this though.
• Add a QSPI PIO program for embassy-rp, implementing QspiBus.
• Add a WiznetSpiBus trait to embassy-net-wiznet - this has a blanket implementation for embedded_hal_async::spi::SpiDevice for backwards compatibility.
  • This has the downside of allowing users to pass QSPI interfaces to chips that don't support QSPI.

Current problems

• QSPI PIO program
  • Likely to break at low frequencies since the operations can interrupt each other - I'm fairly certain I can fix this with interrupts.
  • Changing the program for each operation is quite slow - I think I can fix this by combining the programs into a single program and using exec_jmp - onewire.rs has an example of using exec_jmp.

Performance

I get these results with a TCP benchmark (which spends 40% of its time in smoltcp, mostly doing copies and calculating checksums):

SPI mode:

SPI Frequency (MHz)	down (KB/s)	up (KB/s)	updown (KB/s)
15	905	1224	498

invalid chip version >15MHz SPI.

In QSPI mode:

QSPI Frequency (MHz)	down (KB/s)	up (KB/s)	updown (KB/s)
25	1310	1736	875
15	1257	1622	809

Maybe a better benchmark could use raw sockets and UDP to avoid a lot of the smoltcp overhead. Looking at flamegraphs I think I can get about 15% more performance from combining into one PIO program.

[KingCol13]

I've fixed the interruption problem with an interrupt but the performance has been badly degraded - I will try to use dummy DMA transfers to synchronise, as is done in the regular SPI PIO program.