After the I²C test, showing problems with GigaDevice running at 400 kHz, and MegaHunt at either speed, this time I am running an SPI test.
In this test, I have hooked up an MFRC522 and a CLRC663 PDC (RFID/NFC reader). Using this reader I will scan an ISO 14443 A tag (PICC), specifically an NTAG213.
In this test, I will use the blocking API, like I did with the I²C test. The chip select logic will be software controlled.
The microcontroller will be clocked at 72 MHz, clocked from an external 8 MHz crystal, and the SPI bus will be clocked at 9 MHz. ( 72 / 8 )

I don’t own that many SPI devices, and for this test, I am excluding one-directional devices such as displays. So, when considering SPI devices
that require bi-directional operation, I come down to these RFID/NFC readers. Another option would be SD cards and Flash chips, however, I do
not have drivers for those readily available at the moment.

Either way, all SPI devices around are Mode 0. So I won’t be running any tests on the other SPI modes at this point. I could have a look at
them with a logic analyser, but, like I stated in my I²C test post, at this point, my tests are focussed on whether they can successfully
communicate with the peripherals I present to them. My expectation is they will all work, as SPI feels like it should be simpler to
implement as I²C as all pins are single direction push-pull, as opposed to the bi-directional open drain pins for I²C.

Like last time, the microcontrollers tested are

• APM32F103 (ApexMic)
• APM32F103 (Geehy)
• CH32F103
• CS32F103
• FCM32F103
• GD32F103
• HK32F103
• MH32F103
• STM32F103xB

As stated above, we are communicating with

• MFRC522
• CLRC663

While I wasn’t expecting anything to report on this test, there is. The MegaHunt MH32F103 runs into issues. While it was able to read the Device ID from both PDCs, it fails communicating with a PICC. Using the other microcontrollers, all PDCs read the PICC.