Skip to content

Fix opz_os_read.py getting stuck while reading - #2

Closed
neoqix wants to merge 3 commits into
mutlisensor:mainfrom
neoqix:main
Closed

neoqix wants to merge 3 commits into
mutlisensor:mainfrom
neoqix:main

Conversation

@neoqix

@neoqix neoqix commented Nov 6, 2026 •

Copy link
Copy Markdown
Contributor

On my machine, the script got stuck reading os.ldr around 802k. This fixed it and Pyserial recommends to manage read buffers this way.

What this changes

opz_os_read.py now reads files from the serial in smaller chunks depending on bytes in buffer.

Kind

  • New engine (see guides/submit-an-engine.md)
  • Engine change
  • Research (answers or corrects a question in research/OPEN_QUESTIONS.md)
  • Firmware mod proposal (design note and a DRAFT patch record; issue first)
  • Tools, simulator or core
  • Website or guides

Checklist

  • make -C sim test passes (with new or re-rendered golden hashes committed, and the reason in the commit)
  • python3 -m unittest discover -s tools/tests passes
  • npm --prefix core test passes (if core/ changed)
  • Nothing of teenage engineering's: no firmware, keys, decompiled code, extracted files or renders of their engines
  • Evidence labels on every factual claim about the OP-Z (research and docs)
  • Ported code is MIT, BSD, ISC or public domain, and credited

For a new engine

  • opz_build.py, opz_crashcheck.py --full and opz_cycles.py run clean (or: please run them for me, I have no Blackfin toolchain)
  • README with P1/P2, presets, CPU cost, memory slot and what to listen for
  • Row in sdk/docs/memory-slots.md; test plug id until a maintainer assigns the released one
  • Tested on an OP-Z? What you did and what you heard:

On my machine, the script got stuck reading os.ldr around 802k.  This fixed it and Pyserial recommends to manage read buffers this way.
@mutlisensor

Copy link
Copy Markdown
Owner

Thanks a lot for this, @neoqix, and for taking the time to track it down! 🙏

It's merged. Your commits went into the lab repository and came across to main here with the sync in 15ce12c, with you credited as co-author. read(in_waiting or 1) is the same pattern pyserial's own miniterm uses. The read even finishes a little sooner, because it no longer waits for the timeout on the last block. On top of it we added a comment in collect() and a test that checks it only asks for what's waiting.

We couldn't reproduce the stall itself, though. With timeout=0.2, pyserial's read(65536) returns whatever has arrived after 0.2 s. On our side both versions read all 828,136 bytes, on a real OP-Z and in a pty bench. So we'd love a bit more detail for the record:

  • What happened at ~802 KB: did it print short read: N bytes, then silence, or did it hang with no message?
  • Your OS and version, Python and pyserial versions, and whether the OP-Z was plugged in directly or through a hub.
  • Did a second run with the old code also stop, and has the new code worked every time since?

I'm closing this since the change is in main. GitHub will show it as "closed" rather than "merged" because the commits came in through the sync. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants