Pico Computer 3 — MicroPython hardware test suite: results and findings

 Board: Pico Computer 3 v0.9 (RP2350B), MicroPython v1.29.0-preview,
 console on UART1 GP8/GP9 @115200 via CH340.
 Fitted: DS3231 RTC (battery), micro-SD, PSRAM. No RM2 WiFi, no audio,
 no HDMI, no USB peripherals.

 I put together a Python test suite (pctest.py) covering flash, SD, RTC,
 PSRAM, CPU and MicroPython internals, with PASS/FAIL and measured
 values. Final run: 23 PASS / 0 FAIL / 0 SKIP. A few findings seem worth
 sharing.

 1. STORAGE SPEED — SD and flash are opposites
                 write        read
   SD          489 KB/s     494 KB/s
   Flash        66 KB/s    1120 KB/s

 SD writes about 7x faster than internal flash, but reads about 2x
 slower. So it's worth choosing per workload: SD for write-heavy or bulk
 logging, flash for read-heavy. SD's near-symmetric figures suggest the
 SPI link is the limit rather than the card.

 The slow flash write path (~66 KB/s) has a practical side effect — see
 point 4.

 2. SD SOCKET — a card can sit in a "feels seated" position

 I lost a debugging cycle to this, so flagging it. The socket had a catch
 that lets a card rest partly inserted while making no contact. It does
 not feel obviously wrong. Symptoms:

   - /sd missing from os.listdir('/')
   - pcsd.mounted() and pcsd.start() both False
   - machine.SDCard() constructs OK, but ioctl(4,0) returns -5
     (block-count query unanswered)
   - vfs.mount() gives OSError(16) EBUSY
   - survives a soft reset and a casual reseat

 This reads like a driver or format problem but is purely mechanical.
 Push the card in further before suspecting software. Once seated
 properly it auto-mounted at boot with no other change.

 Two related traps:
   - ioctl(5,0) returns 512 even with no working card. That's the
     driver's default block size, NOT proof a card is present.
   - os.statvfs('/sd') does NOT raise when the SD is absent — it returns
     the FLASH stats, so it looks like a healthy 12MB card. Detect the
     card with os.listdir('/sd') in a try/except instead.

 3. PSRAM — effective bandwidth is dominated by cache residency

 This was the most interesting result. Writing a large buffer measured
 absurdly slow (~0.3 MiB/s), so I swept buffer size. Every row below does
 an IDENTICAL amount of work: 256 slice-assignments of 16 KiB = 4 MiB
 moved in total.

    buffer     time      effective
     16 KiB     21 ms   190.48 MiB/s
     64 KiB    683 ms     5.86
    128 KiB   1273 ms     3.14
    256 KiB   2420 ms     1.65
    512 KiB   4692 ms     0.85
   1024 KiB   9227 ms     0.43
   2048 KiB  18293 ms     0.22

 Constant work, but time scales with buffer size. My reading is that this
 is cache hit rate rather than memory bandwidth: a small buffer is
 rewritten in place and stays resident, a large one misses on essentially
 every write. Reads measured ~2.4 MiB/s on a 4 MiB buffer.

 Caveat: these are MicroPython-level numbers (bytearray/memoryview slice
 assignment), not raw hardware bandwidth, and I have not confirmed the
 cache mechanism directly — that's an inference from the shape of the
 data. Happy to be corrected if someone knows the RP2350 PSRAM path
 better.

 Practical takeaway either way: keep hot working sets small (tens of KiB).
 Streaming multi-MiB buffers through PSRAM is roughly 500x slower than
 working cache-resident, and will dominate runtime.

 Also: a 4 MiB bytearray allocates fine on a clean heap but raised
 MemoryError after earlier alloc/free cycles, so the heap fragments —
 allocate large buffers early.

 4. UPLOADING FILES — per-line paste delay is not enough

 Pasted uploads were silently corrupting: files valid on the PC arrived
 as SyntaxError on the board, with no error from the upload itself. The
 dropped characters were WITHIN single long lines (a 180-char line failed
 to parse), not at line boundaries.

 I had been using a 20 ms per-line delay — twice the 10 ms per-line that
 works fine in TeraTerm under MMBasic — and it still corrupted. The
 difference seems to be that MMBasic tokenises each line on receipt,
 whereas the MicroPython REPL echoes and parses per character and floods
 its RX buffer mid-line. Flash block-erase stalls (see the 66 KB/s write
 figure) make it worse.

 What fixed it: pacing bytes WITHIN the line (16-byte blocks, 4 ms
 apart), base64-encoding the file, prompt-syncing each chunk, and
 verifying length + checksum afterwards with a retry. Byte-exact since.

 If you're scripting uploads over serial to MicroPython, verify the file
 after transfer — autosave() paste gives no integrity guarantee.

 5. RTC

 DS3231 works well: reads, ticks, and agrees with the MicroPython system
 clock to within a second.

 It arrived reading exactly one month behind (2026-06-18 for an actual
 2026-07-18), plus about 6 minutes slow. The reading was internally
 self-consistent — yearday 169 and weekday both matched June 18 — so the
 month field is 1-based and the chip had simply been set wrong at some
 point. An exactly-one-month offset looks like a setter writing the month
 without a +1 adjustment somewhere, but I can't say where it came from,
 and it may just be this board's history. (lizby: I set the RTC when I got
 the board and may simply have entered the wrong month.)

 API note: ds3231.settime(Y, M, D, h, m, s) takes POSITIONAL ints; a
 tuple raises "TypeError: can't convert tuple to int". It updates the
 MicroPython system clock too, so no separate sync call is needed.

 Battery backup confirmed with a real power cycle: stamp written at
 12:06:10, board fully powered down, RTC read 12:30:22 on next boot with
 an uptime of only 127 s — so it tracked ~22 minutes unpowered.

 6. OTHER

   - CPU 252 MHz: ~284 kflop/s, ~864 kiop/s. These are interpreted
     MicroPython figures, not FPU peak.
   - ulab 6.12.1-2D-c is included. Roughly 3x faster per element than a
     list comprehension on the same work (~1.8 us vs ~6.1 us).
   - gc reclaims reliably; ~8 MiB free heap in PSRAM.
   - Multi-line blocks (try/for/def) pasted into the REPL get mangled by
     auto-indent — use a file.