diff --git a/README.md b/README.md
index d17620c68b8ff560da872c22fd20ac10f9ae6b2f..bca73d0ae0e80ff3f8c2eb1414680ebd4235cdd6 100644
--- a/README.md
+++ b/README.md
@@ -4,4 +4,29 @@
- see even i.e. transfer of some tens-of-megabytes onto an SD card (copying a gcode file) - we observe only ~ 20mb/sec of advertized 80mb/sec or so
- 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...
\ No newline at end of file
+- 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
diff --git a/rpi_spi/2023-12-29_pi-spi-rates.md b/rpi_spi/2023-12-29_pi-spi-rates.md
index 78300c7d5b4609cf567c514e35c0880e57eab339..a2757d3af583b3ea4632292315d8a4d362883b76 100644
--- a/rpi_spi/2023-12-29_pi-spi-rates.md
+++ b/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/
\ No newline at end of file
+## 2024 01 04
+
+Well, I got this recording histograms today, here's 1, 10, 11 and 15 MBit/s
+
+| Mbit/s | Histogram |
+| --- | --- |
+| 1 |  |
+| 10 |  |
+| 11 |  |
+| 15 |  |
+
+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.
+
+
+
+
+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.
+
+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
diff --git a/rpi_spi/code/spi_peripheral_bare/spipi.cpp b/rpi_spi/code/spi_peripheral_bare/spipi.cpp
index 163758dabb775635a82df6faba0f7cddc1f8e1f2..3d56b44df860cc6a5164f8a75a56a9428d3cb406 100644
--- a/rpi_spi/code/spi_peripheral_bare/spipi.cpp
+++ b/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
diff --git a/rpi_spi/images/2024-01-04_spi-traces-10Mb.png b/rpi_spi/images/2024-01-04_spi-traces-10Mb.png
new file mode 100644
index 0000000000000000000000000000000000000000..de8a8bf4641b79364bd51775dc27e77c5ab25e09
Binary files /dev/null and b/rpi_spi/images/2024-01-04_spi-traces-10Mb.png differ
diff --git a/rpi_spi/images/2024-01-04_spi-traces-1Mb.png b/rpi_spi/images/2024-01-04_spi-traces-1Mb.png
new file mode 100644
index 0000000000000000000000000000000000000000..6d0a549942975cc57e22210dbd8ea872bdc1ac44
Binary files /dev/null and b/rpi_spi/images/2024-01-04_spi-traces-1Mb.png differ