<purdeaandrei[m]>
Oh, I read somewhere (I think a github comment) that amaranth doesn't support the pull-ups 'yet', and I assumed that comment was correct. Sorry for the confusion.
<purdeaandrei[m]>
Yeah, we can discuss. Although I definitely need to do some learning before implementing anything final-looking. I need to understand how the bits and pieces fit together.
<purdeaandrei[m]>
For instance I don't know what the word 'target' means here. Are you referring to the gateware by any chance?
<purdeaandrei[m]>
what would the advantages of a toplevel command be? Could I perhaps write a script that sequentially uploads different generated designs to the FPGA for self-test without user interaction?
<purdeaandrei[m]>
Or am I limited to 1 FPGA programming cycle per glasgow invocation?
<purdeaandrei[m]>
I suppose I should know the answers to these questions, so I need to take some time to learn the codebase better.
<whitequark[m]>
I'm very happy to explain
<whitequark[m]>
right now though I'm going through some personal events (positive for once) so it'll happen later
<_whitenotifier-3>
[glasgow] purdeaandrei opened pull request #652: Optimize code size (and speed) by using bit access instructions when accessing IO* registers - https://github.com/GlasgowEmbedded/glasgow/pull/652
<whitequark[m]>
you could and this is one of the advantages. the others is that you aren't limited to the platform files used for the applets, and can add your own resources, etc. you also don't have to fit into the CLI framework of applets, which is a little inconvenient there
<_whitenotifier-3>
[libfx2] purdeaandrei opened pull request #17: Make it look for 'sdcc-sdcc' and 'sdcc-sdas8051' executables too - https://github.com/whitequark/libfx2/pull/17
<_whitenotifier-3>
[libfx2] purdeaandrei closed pull request #17: Make it look for 'sdcc-sdcc' and 'sdcc-sdas8051' executables too - https://github.com/whitequark/libfx2/pull/17