Thank you. Thanks for the great review!

As a next step (after #43 is merged) I wanted to solve #41 - because that is a bad bug. The ULP only implements some conditions for the JUMPS instructions and the other "supported" conditions are implemented by the binutils-esp32ulp assembler, by emitting 2 instructions that emulate the desired condition, using those conditions actually supported by the ULP. I would suggest this is fixed before 1.0.

Other than that I had intended to go through the currently skipped tests in the 02_compat_rtc_tests.sh script to see if I can get them all to pass.

OK, currently all tickets in 1.0 milestone are closed, but I'll add this one for the skipped tests mentioned above.

Great. I will take on the skipped tests. Let's see how deep the rabbit hole will be.

oi ... did it close due to the merge? I did not intend to have this closed yet.
There are still a number of things to fix. 3 more issues fixed already - will send PR tomorrow likely.
And potentially still a few more things.
2 test scripts left to get to pass (out of the 5 we skipped so far)

Actually looking over the open issue list, I was wondering if a few small things could still be nice before version 1

Maybe these 2?

1. document minimum required (micro)python version #48 (I tested on 1.11 and 1.16 so I think the min version is 1.11 and versions thereafter will work)
2. The README says "There might be some stuff missing, some bugs and other symptoms of alpha software". With v1.0, maybe we can drop the reference to "alpha" and maybe we can clarify what is missing? (I only know of: assembler macro support, #including other .S files)

I was also wondering about:

1. make imports less ugly #39
2. add useful examples #12

For the first - any idea what the module could be called that takes over what esp32_ulp.__main__ does, and which esp32_ulp.__main__ then should call? It's not doing "assembly" and not "linking", but something that wraps those operations into a working application. esp32_ulp.app? esp32_ulp.build? Or maybe the functions should move into esp32_ulp.__init__, so that it can be imported as just esp32_ulp and other code (and also esp32_ulp.__main__) could then call a method like do_assemble or build or run with a filename?

For the second, technically some of the ulp code we're assembling with the compat test scripts are actually working examples. Should we simply document this and call that enough, or maybe just create our own simple blink example using the RTC_* methods now supported (I think I could appropriate some code I have actually running somewhere)?

But maybe these 2 last ones are just about "perfection" and they're not really that important for the v1.0 milestone. Happy to hear thoughts.

1. I didn't run the code on an esp32 since quite a while. But I know that doing this often has revealed additional todo, because some problems only showed on the esp32. Did you run the latest code from master on esp32?

Yeah, #48 should be done before 1.0.

2. Sure. Due to your recent work, guess we also can declare beta now.

3. See make imports less ugly #39.

4. Yeah, maybe move your suggestion to add useful examples #12, sounds good.

Thanks for that. I have now:

1. Re-tested everything (unit tests and compat tests) on the ESP32 directly, with MicroPython versions v1.10, v1.11, v1.12 and v1.17
2. Updated the README regarding beta quality level
3. Made imports less ugly as per your suggestion in make imports less ugly #39
4. Added a blink example to blink an LED with the ULP (to cover add useful examples #12)

Should I create 1 PR per improvement above (in that case, could I ask you to merge the currently open PR #53 , so I can create PRs against that latest code), or should I simply push those "last minute changes" to the same open PR?

I've merged it. You can put stuff into a single PR, but try to keep the commits clean (as you usually do).