next...

rp2040_uart/2024-03_rp2040-uart.md

@@ -73,6 +73,68 @@ OK, I have this up and running: I am streaming at a fixed BAUD, then counting th
 
 So, I'm not convinced that I haven't fuxd anything here... it seems wild that we would have such a bottleneck to performance, and there are a few red flags here; namely that we have a lower bound of 11us between transmits, which would also explain our increasing error rate when we surpass 1 Mbit/sec (as the byte-wise period there is 10us or so). 
 
+At this point, I'm tempted to return to my old SAMD51 friend, who I know can do things ~ of this nature, fully ISR-d out, with no Flash-Code-Confusion, etc. But I'm also convinced that something is totally broken with the code that I'm operating with at the moment.
+
+To start, there is this oddity in all of earle's code:
+
+```cpp
+int SerialPIO::read() {
+    // THE MUTEX ????? 
+    CoreMutex m(&_mutex);
+    if (!_running || !m || (_rx == NOPIN)) {
+        return -1;
+    }
+    if (_writer != _reader) {
+        auto ret = _queue[_reader];
+        asm volatile("" ::: "memory"); // Ensure the value is read before advancing
+        auto next_reader = (_reader + 1) % _fifoSize;
+        asm volatile("" ::: "memory"); // Ensure the reader value is only written once, correctly
+        _reader = next_reader;
+        return ret;
+    }
+    return -1;
+}
+```
+
+Esp. the `CoreMutex` instantation, but also just that it's pretty bloated. Also the TX line is blocking, unless the PIO put_blocking doesn't actually block until the tx FIFO is clear, 
+
+```cpp
+size_t SerialPIO::write(uint8_t c) {
+    CoreMutex m(&_mutex);
+    if (!_running || !m || (_tx == NOPIN)) {
+        return 0;
+    }
+
+    uint32_t val = c;
+    if (_parity == UART_PARITY_NONE) {
+        val |= 7 << _bits; // Set 2 stop bits, the HW will only transmit the required number
+    } else if (_parity == UART_PARITY_EVEN) {
+        val |= ::_parity(_bits, c) << _bits;
+        val |= 7 << (_bits + 1);
+    } else {
+        val |= (1 ^ ::_parity(_bits, c)) << _bits;
+        val |= 7 << (_bits + 1);
+    }
+    val <<= 1;  // Start bit = low
+
+    pio_sm_put_blocking(_txPIO, _txSM, _txInverted ? ~val : val);
+
+    return 1;
+}
+```
+
+Well - this [only blocks if the FIFO is full](https://cec-code-lab.aps.edu/robotics/resources/pico-c-api/group__hardware__pio.html), but the mutex aught to be adding some pretty bogus time.
+
+In summary - I think it's other peoples' not-bespoke code hell again, and I want out of it. Abandoning this means falling back to the D51, which *I know* can do this, but it would mean that circuit building would get a lot more difficult, and basically the whole lab is on RP2040's. 
+
+So, we should go a little more hardo at this.
+
+### UART TX/RX with Modified Earle Code 
+
+I'll try it my copy-pasta'ing the earle code, to see if I can remove some of the layers-of-abstraction cruft. 
+
+
+
 ---
 
 ### Not in Flash

rp2040_uart/code/uart_pio_earle_tx_rx/uart_pio_earle_tx_rx.ino

@@ -78,8 +78,6 @@ void loop(void){
     uint32_t txInterval = txTime - lastTx;
     lastTx = txTime;
     intervalEstimate = (float)txInterval * 0.01F + intervalEstimate * 0.99F;
-    // while(serial.availableForWrite()){
-    // }
   }
 
   // ...