GlasgowEmbedded / glasgow

Scots Army Knife for electronics
BSD Zero Clause License
1.88k stars 164 forks source link

Migrate away from deprecated `Pads`/`get_pads` mechanism #599

Open whitequark opened 5 days ago

whitequark commented 5 days ago

The two mechanisms are similar conceptually and mainly differ syntactically. The following command can illustrate the changes required:

$ git diff 38730032..e9571705 -- glasgow/applet/interface/jtag_probe/__init__.py

List of applets that still need migration:

q3k commented 4 days ago

Like this? (#602) My Amaranth is very rusty and I don't have how to actually test this. Is there an easy way to make sure an Amaranth/Python change is an RTL no-op?

whitequark commented 4 days ago

Is there an easy way to make sure an Amaranth/Python change is an RTL no-op?

No, but the changes are simple enough I expect to catch most issues during review, even if it's tedious.

Improvements to the general applet infrastructure will continue at a decent pace for the next half year or so, and I expect I'll have to sit down and manually test every single applet at the end of it, hopefully while also adding some better tests. It's going to be painful but what can you do?..

whitequark commented 4 days ago

Also I don't even know where my HX711 board is, much less have a load cell on hand...

q3k commented 4 days ago

Any tips on sequencing updates across multiple modules, eg. with UART(pads/ports) being used by multiple applets?

Is there a temporary/transitional mechanism that I could use to first update the applets (or libraries?) and then the other side?

whitequark commented 4 days ago

I'd suggest leaving updating the libraries (UART and I2C in particular) to some later point, they're kind of a pain and I'm going to rewrite UART at least soon, anyway.

For the rest, unfortunately we don't have real applet composability so the answer is suffering. Making things composable is on my TODO list but it goes after this.