How fast

SPI is not a standard, so no document says how fast it may run. The clock is whatever the controller decides, and it can decide differently for every peripheral on the bus. What limits it is the hardware at each end.

The peripheral

Every datasheet prints a maximum clock. The Bosch BME280 sensor accepts up to 10 MHz, and so does the Maxim MAX7219 display driver. The Winbond W25Q128 flash chip accepts up to 50 MHz for its plain read instruction, 0x03. Its faster read instructions go up to 133 MHz.

Past its limit a peripheral does not refuse. It simply cannot read every bit in time, and some arrive wrong. Nothing on the wire says so.

The controller's pins

On an ESP32 it depends on which pins carry the signals. The pins wired straight to the SPI hardware, the IO_MUX pins, run up to 80 MHz. Any other pin goes through the GPIO matrix, which Espressif documents for signals up to 40 MHz. That figure holds only for half-duplex transfers. Talking and listening at once through the matrix is limited to about 26.6 MHz, in the best case. The ESP32-S3 datasheet gives 80 MHz for its SPI2 and SPI3 controllers.

What a sketch picks

If a sketch gives no speed, the library picks one: 1 MHz on the ESP32 Arduino core, 4 MHz on AVR boards. Both are under the sensor's 10 MHz, so a sketch that never asks for more never finds out how fast the part could go.

Against I2C

NXP's I2C specification, UM10204, defines 100 kbit/s, 400 kbit/s and, in Fast-mode Plus, 1 Mbit/s. An SPI clock of tens of megahertz is ordinary. I2C spends bits on an address and an acknowledge, and SPI spends none.

Common mistakes

• Using the biggest number in the datasheet. The W25Q128 has a limit per instruction, and the plain read stops at 50 MHz.
• Blaming the code for garbled bytes. If they get better when the clock goes down, the clock was the fault.
• Routing SPI through arbitrary pins and expecting 80 MHz. The matrix is documented for 40 MHz. Above that, use the pins the hardware owns.