Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 01:23 22 Jul 2026 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : Claude Code and PicoCom3 MicroPython

Author Message
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3810
Posted: 03:55pm 18 Jul 2026
Copy link to clipboard 
Print this post

I've gotten my Claude Code subscription to work interactively with the PicoCom3 in PowerShell over Com4.

Regarding the hardware, I have no RM2, audio, keyboard, mouse, or monitor, but do have PSRAM, microSD card, and RTC battery. Access is via the USB-C connector.

I asked Claude Code to exercise the available hardware. This is its conclusion:

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.


I can share pctest.py or the uploader if anyone wants them.

Note on setup. I got Claude Code in the browser to walk me through getting Claude Code in Powershell working (Pro, Opus 4.8--$20/month subscription). After it was talking to the PicoCom3 I hit shift+tab until it got into autoApprove mode, so it was no longer asking me about every interaction. Then I gave it the prompt, and it went through dozens if not hundreds of interactions, with me inserting a few "/btw" notes as it went along. I know next to nothing about Python, but what a sweet setup. Thank you Peter.

~
Edited 2026-07-19 02:02 by lizby
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3810
Posted: 07:14pm 18 Jul 2026
Copy link to clipboard 
Print this post

Well, I didn't expect to get back today. After a little bit of setup to prepare and provide the files, at 1:20 I asked Claude to replicate my PicoDB project.

By 3:39 it had done it to the extent of running my 56 test queries and comparing successfully to the results from running those tests on the MMBasic version.

 Against the MMBasic original

 ┌──────────────────────┬───────┬───────┐
 │                      │ lines │ code  │
 ├──────────────────────┼───────┼───────┤
 │ d8a2.bas             │ 2,826 │ 2,068 │
 ├──────────────────────┼───────┼───────┤
 │ library.bas + db.bas │ 2,837 │ 2,099 │
 ├──────────────────────┼───────┼───────┤
 │ Python runtime       │ 2,450 │ 1,649 │
 └──────────────────────┴───────┴───────┘
Exclusive of comments, 1,649 lines in 2 hours and 19 minutes. I thought I was doing very will to build MMBasic PicoDB interactively with Gemini in about 5 very full weeks. Gemini provided the code, I uploaded to to the PicoMite, passed back the  results, and repeated day after day. Claude started with much more complete documentation and a results file to build to, but 1,649 lines of working code in that amount of time is spectacular by my standards.

Claude made hundreds, perhaps thousands of iterations. I dropped in a few more "/btw" notes. All of this within (as far a I could tell) a single token-block of time with never a pause.

Here's a comparison of the test run times MMBasic vs micropython:

Per-test comparison, PC3 flash, both RP2350

 38 faster · 4 about equal · 11 slower

 MMBasic total : 237.6 s
 Python  total :  33.2 s
 overall       : 7.2x faster

 Excluding test 56 (MMBasic's pathological 123 s, corrupted by leaked state): 114.3 s vs 31.8 s — still 3.6×.

 Index build (4.5 s) excluded from both, since MMBasic's startup index build wasn't timed either.

 Where Python wins big — the indexed compound queries

 ┌─────────────────────────────────────┬────────────┬──────────┬──────┐
 │                test                 │  MMBasic   │  Python  │      │
 ├─────────────────────────────────────┼────────────┼──────────┼──────┤
 │ 5 (Abilene|Fresno)&CA               │ 10,694 ms  │ 66 ms    │ 162× │
 ├─────────────────────────────────────┼────────────┼──────────┼──────┤
 │ 25 verify delete                    │ 4,856 ms   │ 46 ms    │ 106× │
 ├─────────────────────────────────────┼────────────┼──────────┼──────┤
 │ 56 city~%City                       │ 123,263 ms │ 1,336 ms │ 92×  │
 ├─────────────────────────────────────┼────────────┼──────────┼──────┤
 │ 2 Abilene & state=TX                │ 4,994 ms   │ 69 ms    │ 72×  │
 ├─────────────────────────────────────┼────────────┼──────────┼──────┤
 │ 27 verify undelete                  │ 4,853 ms   │ 73 ms    │ 67×  │
 ├─────────────────────────────────────┼────────────┼──────────┼──────┤
 │ 30 city~%Los% & occupation=Engineer │ 6,997 ms   │ 289 ms   │ 24×  │
 └─────────────────────────────────────┴────────────┴──────────┴──────┘

 These are exactly the cases where MMBasic fell back to scanning and my planner uses an index.

Next test: 65,000 records on SD card.
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS
 
zeitfest
Guru

Joined: 31/07/2019
Location: Australia
Posts: 691
Posted: 01:48am 19 Jul 2026
Copy link to clipboard 
Print this post

Nifty !!

  Quote  I put together a Python test suite (pctest.py) covering flash, SD, RTC,
PSRAM, CPU and MicroPython internals, with PASS/FAIL and measured
values.


That would be useful for many others, it would be good to post it.
BTW who owns code generated by Claude - are there issues with that ?
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 11636
Posted: 06:24am 19 Jul 2026
Copy link to clipboard 
Print this post

Any code generated by an AI under instruction from a user is owned by the user.

For paid AI coding tools (Copilot, ChatGPT Plus, Claude Pro, etc.), the industry‑standard rule is:

The user owns the output.

This is because:

You provided the instructions.

The AI generated original code in response.

Paid AI services explicitly grant you rights to use the output commercially.

Microsoft, OpenAI, Google, Anthropic — all follow this model.
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3810
Posted: 12:49pm 19 Jul 2026
Copy link to clipboard 
Print this post

Zip file contains pctest.py, which tests selected hardware on the PicoCom3, mp_bridge.py, which handles interaction between the (Win11 laptop) PC and the PicoCom3 on (in my case) COM4, and CLAUDE.md, which contains instructions for claude code including general (regarding the hardware and python) and some specific to the task of building PicoDB in micropython to run on this board.

pctest.zip
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS
 
scruss
Senior Member

Joined: 20/09/2021
Location: Canada
Posts: 105
Posted: 05:17pm 19 Jul 2026
Copy link to clipboard 
Print this post

Couple of observations based on previous MicroPython use:

SD Card: the official sd card library - sdcard (MIM install link: sdcard | mim) - is a little slow, but works. There have been numerous attempts to refactor this for speed, but so far none have been portable or reliable enough. Automount polling hasn't been a thing as detection of card presence isn't always possible on all hardware.

Serial transfer: mpremote, MicroPython's own REPL/management tool, needs no EOL or character delays. For pasting code, the REPL expects you to be in Paste mode (Ctrl-E, then Ctrl-D to finish or Ctrl-C to cancel paste) or you may lose characters or lock up the board.
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3810
Posted: 06:06pm 19 Jul 2026
Copy link to clipboard 
Print this post

Thanks for the comments regarding SD card and serial transfer. In this case, Claude determined what would work empirically--with multiple block size tests for the SD card, and inter-line and eventually inter-character delays in serial transmission. Some of it I watched, but I never intervened (and didn't know enough to be helpful in any case).

If investigations by others determine better ways, they can be folded back into the CLAUDE.md file.

For me, the important thing was that after laying the foundation and giving the prompt, I did almost nothing, including pay attention to what was happening.
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3810
Posted: 01:38am 21 Jul 2026
Copy link to clipboard 
Print this post

So Claude Code (Opus 4.8) built the 64,000 record database, iterated the batch test run with 56 queries, fixed some problems including garbage collection that only showed up after query # 53, and ultimately provided code which ran all the queries. I connected a 7" hdmi screen so I could see Claude working--not quite as useful as telnet with MMBasic, but good for viewing Claude at work.

I only had a few interactions as I mostly did other things for the past two days. The 2 linked files are 13.7 and 2.8 megabytes on the SD card. Indices are on the flash drive. Queries on indexed fields which just hit the main file are quick--1-2 seconds. Results which include fields from the two linked files and which require maybe hundreds of random access reads on the two files may take 10 minutes.

The whole 56-query test run took 87 minutes.

My 2-month interactive journey with Gemini to initially build PicoDB and PicoRR in MMBasic proved that the prediction that I read in January was true -- 2026 would be the year when coders who knew what they wanted could use AI "all day, every day".

But "agentic" AI, where you tell AI to do a long task and leave it to run on its own interactively with connected hardware (or with multiple facilities on your PC and on the internet) is a different matter. I don't have enough tasks to keep subscription Claude Code busy. And for a long task, it's Claude that is busy "all day", not me.

I suspect I could tell Claude Code to implement Windows 3.1 on this hardware in C and it could do it, since I think the PicoCom3 is pretty close in capacity to an early Pentium. Of course, with the SD card, the storage available is far beyond what a 90's desktop would have.
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS
 
PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 2001
Posted: 08:04am 21 Jul 2026
Copy link to clipboard 
Print this post

  Quote  CPU 252 MHz: ~284 kflop/s, ~864 kiop/s. These are interpreted
    MicroPython figures, not FPU peak.


Isn't this super-impressive or am I misinterpreting?
 
JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 4352
Posted: 08:49am 21 Jul 2026
Copy link to clipboard 
Print this post

Thanks for the write-up.

John
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 3810
Posted: 02:59pm 21 Jul 2026
Copy link to clipboard 
Print this post

I asked Claude to translate the often used bench.bas to python and run on the PicoCom3. I ran the MMBasic version on a different PicoCom3 running at 315000kHz instead of the micropython 252000kHz. Here are the results:
 BM1     BM2     BM3     BM4     BM5     BM6     BM7     BM8
0.0015  0.0027  0.0170  0.0156  0.0231  0.0323  0.0472  0.0239 PicoCom3 Micropython 252000KHz
0.0016  0.0219  0.0352  0.0320  0.0492  0.1374  0.1104  0.0458 PicoCom3 MMBasic     315000KHz


Claude's summary:
  Quote  So the comparison is even more lopsided than the raw numbers suggest:  MicroPython gives up 25% of its clock to hold a clean hdmi display, and still wins every benchmark. The bytecode VM's efficiency more than covers the handicap.


Here is the last in the long thread here (with micropython on PicoCom3 added after CMM2):

               BM1     BM2    BM3      BM4     BM5     BM6     BM7     BM8
ABC 800 single   0.9     1.8    6.0      5.9     6.3    11.6    19.6     2.9
ABC 800 double   1.2     2.2    10.0    10.6    11.0    17.8    26.4    14.4
IBM PC           1.5     5.2    12.1    12.6    13.6    23.5    37.4     3.5
Apple III        1.7     7.2    13.5    14.5    16.0    27.0    42.5     7.5
VIC-20           1.4     8.3    15.5    17.1    18.3    27.2    42.7     9.9
ZX81 "fastmode"  4.5     6.9    16.4    15.8    18.6    49.7    68.5    22.9

Maximite         0.016   0.144   0.196   0.205   0.354   0.512   0.721   0.310
Maximite w. #s   0.016   0.131   0.193   0.194   0.245   0.393   0.582   0.241
Maximite w/o #s  0.016   0.111   0.173   0.173   0.192   0.336   0.525   0.220
MicroMite 40MHz  0.028   0.18    0.285   0.289   0.644   0.892   1.346   0.376
MicroMite 48MHz  0.023   0.15    0.237   0.24    0.536   0.744   1.121   0.313
MM+ MX470 120MHz 0.013   0.082   0.135   0.135   0.265   0.380   0.597   0.174
MMX 198MHz       0.006   0.045   0.07    0.08    0.141   0.201   0.287   0.126
Picromite ZeroW  0.014   0.058   0.093   0.102   0.184   0.298   0.354   0.127
Armmite H7       0.003   0.023   0.038   0.042   0.067   0.098   0.146   0.065
ArmMite F4       0.011   0.079   0.14    0.149   0.249   0.354   0.528   0.257
MMBASIC DOS      0.0002  0.0017  0.0028  0.0028  0.0073  0.0092  0.0117  0.0058
CMM2             0.00176 0.0118  0.01903 0.01728 0.03611 0.05062 0.07582 0.02851
PicoCom3 python  0.0015  0.0027  0.0170  0.0156  0.0231  0.0323  0.0472  0.0239
PicoMite         0.0166  0.1096  0.1800  0.1840  0.3325  0.4715  0.6688  0.3193
PicoMite V50800  0.0132  0.0969  0.1636  0.1641  0.2866  0.4051  0.5821  0.2824  126MHz
PicoMite V50800  0.0046  0.0338  0.0571  0.0574  0.0998  0.1410  0.2030  0.0974  378MHz
Linux            0.0000  0.0020  0.0040  0.0040  0.0080  0.0130  0.0190  0.0070

Other Recent Basics
ByPic MX170 40M  0.001   0.010   0.023   0.020   0.027   0.041   0.080   0.043
BBC_V Pi Zero    0.0001  0.0007  0.0016  0.0014  0.0015  0.0030  0.0030  0.0036

C-Language
Arduino UNO      0.010   0.010   0.058   0.043   0.043   0.043   0.045   0.284
Arduino DUE      0.003   0.003   0.006   0.007   0.007   0.007   0.106   0.014
ESP32S           0.00007 0.00007 0.00030 0.00011 0.00016 0.00016 0.00016 0.02413


So micropython on the PicoCom3 is faster than the CMM2 in every one of these particular benchmarks.

bench.bas and bench.py in zip file.

~

bench.zip
Edited 2026-07-22 01:01 by lizby
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on FOTS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 11636
Posted: 03:06pm 21 Jul 2026
Copy link to clipboard 
Print this post

You can run python at 315MHz

screen(hdmi.RGB640,315)

  Quote  MicroPython gives up 25% of its clock to hold a clean hdmi display, a


This is b.....ks. HDMI is all on the second core same as MMbasic
 
Print this page


To reply to this topic, you need to log in.

The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2026