Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.43%. Comparing base (c8838b5) to head (d9a0fdd).
Report is 6 commits behind head on master.

@@           Coverage Diff           @@
##           master   #15624   +/-   ##
=======================================
  Coverage   98.43%   98.43%           
=======================================
  Files         163      163           
  Lines       21295    21295           
=======================================
  Hits        20961    20961           
  Misses        334      334           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

One thing I'm curious about is whether semihosting is necessary for this to work well, vs -serial stdio? Do we need to implement semihosting on other qemu ports for this approach to work there?

I tried hard to get the semihosting serial stuff working, but I just couldn't work out a way to get qemu-system-arm to redirect the semihosting serial to an independent /dev/pts/X device, and so it wouldn't work properly with run-tests.py (nor mpremote). So in the end I implemented UART RX for all supported boards on this port, and that works will with redirection to /dev/pts/X.

But I left the semihosting code there (see mphalport.c) in case it's useful in the future. After all, it is a board-agnostic way to do serial IO.

That said, semihosting is still needed for the implementation of exit(), which is used by machine.reset() to cleanly close the emulator (if the user wants to do this, eg at the REPL).

For qemu-riscv: I didn't look into that yet. Maybe semihosting will work there, or maybe it also needs a UART for proper redirection to /dev/pts/X.

@dpgeorge Makes sense, thanks. I had misunderstood that the REPL is over serial in this PR not semihosting.

The only suggestion I'd make is to please put some information in the qemu-arm README about how to use the REPL, how to run tests, etc

Now done.

I had a bit of free time today to try this out for RISC-V, so feel free to take a look at the last two commits in https://github.com/agatti/micropython/tree/qemu-console-interface-rv32.

Running REPL and tests work, however I have some failures I still have to look at (can't look at those until tomorrow):

736 tests performed (22589 individual testcases)
732 tests passed
134 tests skipped: ...
4 tests failed: framebuf_polygon int_big_div int_big_lshift int_big_mul

If you want to take a look at those failures you can use the testdebug makefile target, connect gdb to TCP port 1234, and then take it from there. Maybe the ..debug makefile targets could be added to the qemu-arm port too?

I had a bit of free time today to try this out for RISC-V,

Actually... my plan after this PR was to merge both qemu-arm and qemu-riscv into a single port, say qemu. They have a lot overlapping, and the semihosting stuff is factored out to shared/runtime/semihosting_<arch>.[ch]. So I think it would work to merge them, although I haven't tried that yet.

After all, the esp32 and rp2 ports support MCUs with different architectures.

That makes sense. Technically semihosting implementations can also be unified, as RISC-V follows Arm on that front: https://github.com/riscv-non-isa/riscv-semihosting/blob/f74a3f47bfaaaf9dfb614a452c3fe4635deee140/src/intro.adoc?plain=1#L19-L21. With some minor changes to the current code, that can handle Aarch32, Aarch64, RV32, and RV64 in a single implementation.