I finally found the problem, and as I was suspecting, it indeed was a stupid mistake from my part:
In the kernel modules, I was registering the interrupt for the rising edge, although it should have been the falling edge:
Code: Select all
request_threaded_irq(request_pin_irq, send_spi_message, NULL, IRQF_TRIGGER_RISING, "request", spi_dev);
The STM32 triggers the interrupt like this:
Code: Select all
digitalWrite(REQUEST_PIN, HIGH);
delay(1);
digitalWrite(REQUEST_PIN, LOW);
So, while the Raspberry Pi already started sending out data over SPI, the STM32 still had to wait 1ms, set the request pin low and start listening on the SPI.
Eventually, I decided to try sending longer strings, and that's when I noticed that the end of every message was received, and the amount of missing data at the start was influenced by the SPI baud rate (higher rate -> more data missing). I still don't know why I was seeing the 'H' at the start of the 'Hello!' message (I was receiving 'H!' for every 'Hello!' sent), but obviously, I don't intend on investigating this further. Now that I register the interrupt on the Pi on the falling edge, I seem to have reliable communication even at 16M baud rate, which I find phenomenal!
Once I had the base SPI communication going, I was able to build a DMA circular-buffered timer-triggered implementation in no time. I'm currently testing it and playing around a little.
I'd like to take this opportunity to thank everyone who was trying to help me in fixing the bug I was seeing, and generally all the great people developing the STM32duino stack and the HAL libraries! This really seems like a great platform to work with!