notes on spi rates

README.md

@@ -5,3 +5,28 @@
 - otherwise, you have notes on what-the-point is in your `scratch` 
 - and consider linking to the ring-test page 
 - and discuss that at the embedded limit, we often run into interrupt-request-handling-time troubles before anything else... 
+
+## TODO
+
+- test the D51 for device-to-device uart 
+- likewise for RPI (five?) to device SPI link 
+
+---
+
+## Next
+
+- the SPI can work, I suspect
+    - probably needs that sweet sweet 250MHz-es 
+    - can crank up to 16-bit words in the FIFO, for 2x less starvation 
+        - can PIO do 32-bit words, perchance ? 
+    - fire the interrupt on transmit buffer not-full, rather than half-full ?
+        - actually no interrupt exists for this 
+    - can we do a proper echo test, then check for drops, etc, for max speed ? 
+- do the RP2040-to-RP2040 UART PIO test 
+- finish the thought, blog it up (1 day, max) 
+- take i.e. [notes](https://abyz.me.uk/rpi/pigpio/pigs.html), right ? 
+    - incl. the maybe-likely-change to use PIO spi-slave, not this bs 
+- i.e. go-notes/ref/rp2040 ? 
+    - https://cec-code-lab.aps.edu/robotics/resources/pico-c-api/index.html 
+    - https://github.com/raspberrypi/pico-examples/tree/master 
+    - https://www.circuitstate.com/tutorials/making-two-raspberry-pi-pico-boards-communicate-through-spi-using-c-cpp-sdk/ 
\ No newline at end of file

rpi_spi/2023-12-29_pi-spi-rates.md

@@ -87,22 +87,24 @@ I'm going a bit mad with this; I can get GPIO interrupts to fire *just on a fall
 
 There's another oddity in here... the RP2040 only uses SPI framing where the CS line is pulsed per frame (7-16 bits), so we need to handle it in software, though IDK exactly how to do this as a peripheral, though apparently [this lad](https://github.com/raspberrypi/pico-sdk/issues/88#issuecomment-1402204730) found [a workaround?](https://github.com/uwopus/pico-code/blob/3594e67c1ac34e5454eb4db8362b673bcc7c8862/opus_comms/opus_comms.c#L44-L46) which references 4.4.3.13 
 
----
-
-## Next
-
-- the SPI can work, I suspect
-    - probably needs that sweet sweet 250MHz-es 
-    - can crank up to 16-bit words in the FIFO, for 2x less starvation 
-        - can PIO do 32-bit words, perchance ? 
-    - fire the interrupt on transmit buffer not-full, rather than half-full ?
-        - actually no interrupt exists for this 
-    - can we do a proper echo test, then check for drops, etc, for max speed ? 
-- do the RP2040-to-RP2040 UART PIO test 
-- finish the thought, blog it up (1 day, max) 
-- take i.e. [notes](https://abyz.me.uk/rpi/pigpio/pigs.html), right ? 
-    - incl. the maybe-likely-change to use PIO spi-slave, not this bs 
-- i.e. go-notes/ref/rp2040 ? 
-    - https://cec-code-lab.aps.edu/robotics/resources/pico-c-api/index.html 
-    - https://github.com/raspberrypi/pico-examples/tree/master 
-    - https://www.circuitstate.com/tutorials/making-two-raspberry-pi-pico-boards-communicate-through-spi-using-c-cpp-sdk/ 
+## 2024 01 04
+
+Well, I got this recording histograms today, here's 1, 10, 11 and 15 MBit/s
+
+| Mbit/s | Histogram |
+| --- | --- | 
+| 1 | ![1mb](images/2024-01-04_spi-histo-1Mb.png) |
+| 10 | ![10mb](images/2024-01-04_spi-histo-10Mb.png) |
+| 11 | ![11mb](images/2024-01-04_spi-histo-11Mb.png) |
+| 15 | ![15mb](images/2024-01-04_spi-histo-15Mb.png) |
+
+They are nicely packed / consistent, and we can basically get up to 5Mbit/sec when we use 10Mbit underlying rate - which is rad, but... not the whole 10Mbit, is it?
+
+This is because of - once again - that inter-packet time, which we can see in 1 and 10Mbit traces here, where CH1 is chip select and CH2 is DO.
+
+![1m](images/2024-01-04_spi-traces-1Mb.png)
+![10m](images/2024-01-04_spi-traces-10Mb.png)
+
+We can see that the actual packet transmission (the solid blue chunk) is taking place ~ just over half of the time at 10Mbit, and we are otherwise in deadzone: CS hi, or CS lo but no transmission happening. I didn't observe this deadzone ever being any smaller than 10us, and it would sometimes grow to 40 or 50us, which would impose a real-bandwidth cap even as we increase underlying bitrates. This is why, in our 1Mbit histogram, our real rate is somewhere around 0.7Mbit, whereas even when we crank the bitrate to 10Mbit, our real rate only climbs to 5Mbit. This also means that this link (like many others) is going to reward large packets / frames. 
\ No newline at end of file
+
+There's also a significant dropoff in quality just above 10Mbit, we jump from three zeroes to one, and then up to 15Mbit only we are hitting full missus. I suspect that this is a hard interrupt handling time limit. 
\ No newline at end of file

rpi_spi/code/spi_peripheral_bare/spipi.cpp

@@ -25,7 +25,7 @@
 #define PIN_RX    12 
 #define PIN_TX    11 
 
-#define BITRATE   10000000
+#define BITRATE   11000000
 
 #define SPI_INST  spi1 
 #define SPI_HW spi_get_hw(SPI_INST)
@@ -48,7 +48,7 @@ volatile uint8_t txPtr = 0;
 volatile uint8_t txLen = 64;
 
 // we catch rising edges to delineate packet-end
-void spipi_gpio_irq_handler(uint gpio, uint32_t events){
+void __not_in_flash_func(spipi_gpio_irq_handler)(uint gpio, uint32_t events){
   if(gpio_get(PIN_CS)){
     txPtr = 0;
     rxPtr = 0;
@@ -56,7 +56,7 @@ void spipi_gpio_irq_handler(uint gpio, uint32_t events){
   }
 }
 
-void spipi_irq_handler(void){
+void __not_in_flash_func(spipi_irq_handler)(void){
   // gpio_put(PIN_DEBUG, !gpio_get_out_level(PIN_DEBUG));
   // both have up to 8 bytes to read / write per interrupt ? 
   // write bytes while writable