Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.39%. Comparing base (9999553) to head (63a6628).
⚠️ Report is 15 commits behind head on master.

@@           Coverage Diff           @@##           master   #18301   +/-   ##=======================================  Coverage   98.39%   98.39%           =======================================  Files         171      171             Lines       22290    22290           =======================================  Hits        21933    21933             Misses        357      357

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

These test programs would also be useful for covering the code paths that load programs into hardware --- i.e. still notexecuting them, but doing everything up to callingsm.active(1), and verifying the that thePROG_OFFSET_PIO0...PROG_OFFSET_PIO3 entries in the lists are set as expected.

These test programs would also be useful for covering the code paths that load programs into hardware --- i.e. still notexecuting them, but doing everything up to callingsm.active(1), and verifying the that thePROG_OFFSET_PIO0...PROG_OFFSET_PIO3 entries in the lists are set as expected.

Yes, definitely! Possible some more reasonable programs which don't depend on GPIO might be worth assembling and running in the test too, if we're running on a real rp2?

if we're running on a real rp2?

Wait, do we even have a unix target this test can be run against? i.e. with a substitute_rp2 module and all that.

Possible some more reasonable programs which don't depend on GPIO might be worth assembling and running in the test too

Agreed, and IMO the most important place for coverage there isn't the PIO opcodes themselves but everything else, the queues and DMA and IRQs. As a simple place to start with, though, a PIO program that just copies from its input buffer to its output buffer could be used to verify quite a lot --- validate correctness ofPIO.get,set. Another test would be the same program but accessing it with DMA to verify thattx_fifo andrx_fifo are correct. And then maybe one that fires an interrupt any time it gets input?

with a substitute _rp2 module

Is should be not too much work to create mock modules based on the_rp2 andrp2 stubs

• https://github.com/Josverl/micropython-stubs/tree/main/reference%2Fmicropython%2F_rp2
• https://github.com/Josverl/micropython-stubs/tree/main/reference%2Fmicropython%2Frp2

Is should be not too much work to create mock modules based on the_rp2 andrp2 stubs

If we replacedrp2.py with a stub, what are we even testing anymore? A mock for_rp2 would be pretty useful though --- I've also considered trying to pull in one of the existing PIO emulator programs that someone's written, to make it useful for testing the behavior of PIO code when it's used as part of some larger functionality. Though that would be alot more work than just making all of the functions print that they were called and/or minimally update program-visible state to let calling programs move on.

I think for the purposes of testing the assembler itself, it's sufficient forimport _rp2 to do nothing but just not to raise an ImportError. I haven't actually checked, but the assembler decorator looks like it'd run just fine on cpython even, and that's all that's in rp2.py.

Aside: when it comes to dynamic languages, I'm more of a scheme programmer who is still puzzling over all the special-cases in python's design, so forgive the naive question, but is there a standard mechanism to register a module other than loading it from a .py file? A module namespace is just a map from names to values; the firstimport foo loadsfoo.py, registers the resulting namespace somewhere and adds a reference in the local namespace, then subsequentimport foos just add a reference in the local namespace to that same module created on first import. If you modify the contents of one instance of the module, the others change too. So without loading it from an empty file, can I register a blank module with a given name (e.g._rp2 in this case) so that futureimport _rp2s reference it rather than trying to load_rp2.py?

Anyway, in the interests of not getting lost in the weeds, perhaps it's worth finalising a good set of tests that can run fine on the rp2 boards themselves, and then revisiting the question of whether we can make a subset of those tests run outside the rp2 port so they can be exercised by automated-ci as a follow-up?

I'll take a look at exercising more of the 'uploading to hardware' paths with the existing programs as you suggest,@AJMansfield, and maybe write some simple programs that can run on the hardware without needing external hardware on gpios too.

Agreed, and IMO the most important place for coverage there isn't the PIO opcodes themselves but everything else, the queues and DMA and IRQs. As a simple place to start with, though, a PIO program that just copies from its input buffer to its output buffer could be used to verify quite a lot --- validate correctness ofPIO.get,set. Another test would be the same program but accessing it with DMA to verify thattx_fifo andrx_fifo are correct. And then maybe one that fires an interrupt any time it gets input?

The other great thing about having these things in tests is that they're then clear demonstrations of what minimal DMA or minimal IRQ handling looks like for PIO. I have examples in my programs of all of these, but they're not so discoverable because they're surrounded by the rest of the program. (DMA from ADC is another one where I keep meaning to do a simple demo and post it somewhere easily searchable/discoverable. There are lots of quite complicated examples, but just to stream to a buffer using the new rp2.DMA is much easier than they would suggest.)