<whitequark[cis]>
we have a GPIO applet, which could serve such a purpose
<jn>
it's pretty new
<whitequark[cis]>
that being said, the "read flash memory while holding device in reset" use case is common enough that memory-25x should perhaps itself support it
<whitequark[cis]>
right now program-ice40-flash does almost exactly what you want
<hansihe[m]>
having that in memory-25x would be nice, but more generally I would love the ability to be able to assert pins together with any applet as well
<hansihe[m]>
I missed the gpio applet as I think I need to update my install, but having it in there sounds great I imagine
<whitequark[cis]>
the GPIO applet doesn't currently have a CLI, but that wouldn't be hard to add
<hansihe[m]>
to give some props, I hacked together a script where I instantiate several uart applets and use them to sniff several serial busses on my board simultaneously, it works so amazingly well and being able to get a trace of everything going on at once is incredibly nice. Being able to do stuff like that I started to really feel the power of the tool :)
<hansihe[m]>
in case you are interested in the UX for a relative newcomer
<whitequark[cis]>
hansihe[m]: very happy to hear that, and yeah, that's a part of the design goal
<whitequark[cis]>
when you say "several" do you mean "two"? (since doing more than two would be fairly tricky rn)
<whitequark[cis]>
re "- Uh oh, can't exit like I did before?" I think you need to do the exit sequence twice; this is one of the reasons multi is currently described as "experimental" in the help text
<whitequark[cis]>
re "- Auto baud rate detection did seem to work, I wish it printed out what it figured out though" -- I am pretty sure we print an info level message whenever a switch is detected, or at least there is code for it
<whitequark[cis]>
re "- I get receive errors even though it does seem to work generally?" -- receive errors are expected whenever autobaud triggers (since it triggers on receive errors)
galibert[m] has joined #glasgow
<galibert[m]>
The uart can receive, can it send too?
<galibert[m]>
With multi that should probably be two independent applets though
<whitequark[cis]>
re "- Had to look at locals() to figure out the name of the uart peripheral iface, no indication of the name" -- the expected use model involves using glasgow repl before going to glasgow script, and glasgow repl does print the variable name; not sure what to do about the script, maybe just put it into docs?
<whitequark[cis]>
galibert[m]: hm? the UART acts like a normal serial terminal, send and receive, within one applet
<whitequark[cis]>
re "- Looked at the source code, doesn't seem to be any way to do multiple applet with script through CLI yet" -- yes. this is another reason why multi is described as experimental
<hansihe[m]>
whitequark[cis]: yep, only used with 2 so far
<hansihe[m]>
not complaining about any of this stuff by the way, just noted down the friction points I had :)
<hansihe[m]>
I knew what I was going into when I tried experimental stuff
<whitequark[cis]>
re "- Thought: From looking at the code, run, repl and script are sorta 3 sides of the same coin. Could this instead be a single subcommand, maybe defaulting to behaviour of run with an optional --repl and script flag?" -- I think that's what it started out as, our argument parsing library doesn't work very well though if the commands are combined
<whitequark[cis]>
hansihe[m]: yeah I get that, I'm just offering context
<hansihe[m]>
whitequark[cis]: might have missed it, that would be mb
<whitequark[cis]>
re "- Thought: I know I am probably using the glasgow package in an unsupported way, but it would be really cool if there was a create_assembly function which you could pass a device and a set of CLI equivalent arguments, and it would be ready for you to use in your code" -- the idea is that you would have a Python interface that you can use to configure applets, and this Python interface would be semi-automatically wrapped in a
<whitequark[cis]>
CLI based on some static annotations rather than the current code-based model we use
<whitequark[cis]>
I'm not fond of the idea of manipulating CLI arguments as text in source code, though you could just do that with applet._parse_args or whatever I called that function
<whitequark[cis]>
note that the "Assembly" API (everything in glasgow.abstract and key things in glasgow.hardware / glasgow.simulation), while unstable, is something you can reasonably rely on, this is an outcome of 5 years of research and development and I don't expect it to change too much. most changes would probably just shuffling things around more so than fundamental major ones
<whitequark[cis]>
this means that your script that constructs two UARTInterfaces in a HardwareAssembly (I presume this is what you did?) is a part of the indended, if not fully supported yet, use model
<whitequark[cis]>
we only recently migrated to Assembly based API which was done to enable exactly this sort of easy scripting \
<hansihe[m]>
<whitequark[cis]> "re "- Thought: I know I am..." <- what I meant by that is that for me an ideal workflow would be to prototype something with the CLI initially, then as I make tools for myself as I continue reverse engineering whatever device then I want to throw that into a single python script which I can quickly run and version control
<hansihe[m]>
to minimize friction between the CLI and the python library interface having an option to call a function which creates the equivalent assembly in the script for the set of CLI arguments could be really convenient
<whitequark[cis]>
hansihe[m]: ah, I see. this runs into a philosophical question of, basically, "what interface is the primary one?"
<whitequark[cis]>
from my perspective, the primary interface of an applet is the Python API of its *Interface class, which allows the richest and most flexible possible interaction patterns. the CLI is the secondary interface, which exposes a small subset of the Python API
<whitequark[cis]>
hansihe[m]: this is basically all you need to instantiate an applet: one line per applet, and 3-4 lines of boilerplate