ChanServ changed the topic of #glasgow to: glasgow debug tool · code https://github.com/GlasgowEmbedded/glasgow · forum https://glasgow.whitequark.org · logs https://freenode.irclog.whitequark.org/glasgow · production https://www.crowdsupply.com/1bitsquared/glasgow · no ETAs at the moment
<awygle> windows reboot to install update last night ate my notes >_>
<awygle> so glasgow applet subtargets are oMigen modules, but they're running under nmigen compat, yes?
<awygle> is there a way to use non-compat nmigen to write one, or is that crossing the streams in a way that will only lead to agony?
<whitequark> awygle: there are some applets that use nmigen
<whitequark> lemme see
<awygle> oh huh i did not notice that. hx711, jtag_openocd, and i2c_target looks like
<awygle> oh and m16c
<awygle> wait it's exactly the same? you just pass an Elaboratable instead of a Module to add_subtarget?
<whitequark> basically
<whitequark> nmigen.compat is designed to transparently integrate with normal nmigen code
<whitequark> and i'm pretty sure i succeeded
<awygle> wq, you gotta stop making software that's extremely easy to use and just does the right thing everywhere
<whitequark> you should be used to it by now :p
<awygle> i'll never guess that to be true, ever :p
<awygle> damn that was easy. i'm flabbergasted.
<whitequark> lol
<whitequark> look, i can't be arsed to debug obscure failures, so i simply write code that doesn't have them
<whitequark> the main problem is that this approach really doesn't scale
<awygle> indeed :/
<awygle> how do i claim a pin without making it an argument? or is that a no-no
<whitequark> the latter
<whitequark> currently the idea is that all pins are configurable from cLI
<whitequark> but the defaults mean you usually don't have to specify everything explicitly
<awygle> mm ok. how can i change which pin is used by default then? it looks like if default is True it'll grab the next free one....
<awygle> but what's the format for if you specify a default? "A0", "A1", "B0", "B1" referenced to ports, or ice40 pins?
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<awygle> oh ok i get it now. the port is specced on the CLI and if i grab AB then e.g. pin 12 is B4
<awygle> nvm
<whitequark> yep
<awygle> am i correctly understanding that in the async "interact" side of things you're writing to the interface you get from `demultiplexer.claim_interface`, and in the nmigen "gateware" side of things what you've written will show up in the FIFOs you get from the interface from `multiplexer.claim_interface`, and that's how all this ties together?
<awygle> (the interface presumably abstracting all of the FX2ness of it all)
<whitequark> yep
<whitequark> and yep
<awygle> the way you hit the "interact" endpoints is still through the "run" command, there's no "interact" command? or do those get hit through "run-repl"?
<whitequark> `glasgow run applet` hits the "interact" command
<awygle> what hits the `run` command?
<awygle> (by which i mean `async def run()`
<whitequark> the reason "run" and "interact" are different is for building a stack of applets one on top of another
<awygle> i see (well, sorta. i see enough lol)
<awygle> thanks
<whitequark> er, sorry, i was dealing with some bureaucracy
<whitequark> let me explain properly
<whitequark> when you make an applet that reuses another applet, you are supposed to use inheritance most of the time
<whitequark> this isn't actually an especially good pattern but i think it works to an extent
<whitequark> so in your build method you'd call the superclass' build and add any new stuff you have, like reset or mode pins on top of, say, plain spi
<whitequark> the run() method pretty much just instantiates the *Interface class appropriate for that applet and returns it (maybe also sets pull resistors)
<whitequark> and usually applets higher in the stack wrap the ones lower in the stack, so they'd also call the superclass method and use the return value to instantiate their own *Interface
<whitequark> the interact() method though is specific to that particular applet, and should not generally be reused
<awygle> ah, i see
<awygle> what is the "low-level interface" described by the help under `run-repl`?
<whitequark> oh!
<whitequark> so run-repl replaces the interact() method by a, well, REPL
<whitequark> and whatever is returned by run() is available as a local `iface`
<whitequark> since a bunch of applets used to have this functionality as a special case in interact() I decided to pull it out
<awygle> ahhh
<whitequark> very convenient when automating something quickly, or when building derived applets
<awygle> interesting!
<awygle> maybe i should try to get that up and running first....
futarisIRCcloud has joined #glasgow
midnight has quit [Ping timeout: 252 seconds]
midnight has joined #glasgow
bvernoux has joined #glasgow
pinoaffe has quit [Quit: killed]
pinoaffe has joined #glasgow
Stormwind_mobile has quit [Read error: Connection reset by peer]
bvernoux has quit [Quit: Leaving]
Stormwind_mobile has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 260 seconds]
Stormwind_mobile has joined #glasgow