redstarcomrade has quit [Read error: Connection reset by peer]
<whitequark[cis]>
okay, let's make a poll
<whitequark[cis]>
people who are on weird platforms: how do you feel about glasgow software gaining a mandatory dependency on Rust?
<owoday[m]1>
whoa... I just realized it doesnt depend on rust
<whitequark[cis]>
not at the moment!
<owoday[m]1>
It has a mandatory python dependency though right?
<whitequark[cis]>
it's entirely written in python, with one major native dependency (libusb1)
<whitequark[cis]>
i chose python years ago even though i don't like the language all that much because python is very accessible. everyone can write at least a little python1
<whitequark[cis]>
s/python1/python!/
<whitequark[cis]>
if i had my way i'd have picked ocaml
<owoday[m]1>
is it a verbal poll or voting
<whitequark[cis]>
we don't do voting here, i have the final say on what goes into the framework (a few people are code owners of specific applets and have a final say there)
<whitequark[cis]>
so i just want to understand the impact it would have on users
<whitequark[cis]>
it is basically decided that there will be at least an optional dependency on a PyO3 based native package, the question is whether i can make it mandatory or not
<owoday[m]1>
My take is that a python dependency is more controversial than rust, since rustup is pretty clean. Also, the projects leniency on python interpreter is pretty forgiving, Ill let other people talk :3
<whitequark[cis]>
i mean... python is less "a dependency" and more "literally makes the entire thing tick"
<whitequark[cis]>
i'm not going to rewrite it in rust or anything, i'm just considering adding a binary library that requires rustc to build
<whitequark[cis]>
and people have opinions about rustc. does rustup even work on freebsd?
<jn>
i personally don't like rustup and use a distro-managed rust toolchain only
<tpw_rules>
i think rustc and python is pretty okay on nix
<whitequark[cis]>
i think nix is gonna be ~fine because i will upload wheels for manylinux systems, of which nix is one
<whitequark[cis]>
actually no it won't, it doesn't have glibc in the right location
<whitequark[cis]>
ok, so you'll have to build a derivation for that dependency probably
<tpw_rules>
yes but we are used to that anyway and already do it for e.g. yosys
<tpw_rules>
(yes i know there is the wasm build)
<tpw_rules>
i think but cannot promise anything that rust is okay on the BSDs these days, the m1n1 people are doing it now
<whitequark[cis]>
right
<whitequark[cis]>
okay, nix: not an issue
<tpw_rules>
thank you for asking
<whitequark[cis]>
you're welcome ^^ i do not like quote-unquote ramming rust down people's throats
<whitequark[cis]>
actually there was some python package i don't recall that silently and unconditionally added a rust dependency and told everyone questioning this when it broke their builds to basically fuck off
<whitequark[cis]>
you're welcome! and yeah, this is the very first applet that allows other software to use the glasgow device
<whitequark[cis]>
you can also use it over network if you run glasgow run probe-rs ... tcp::1234
<wiebel[m]>
And just at the point I was considering a more direct device for flashing via swd, as the gdb way is kinda overkill for flashing.
<wiebel[m]>
Thx for putting the required probe-rs command in the output of the applet. I'm not yet comfortable with the documentation.
<whitequark[cis]>
the required probe-rs command is actually not something you can come up with on your own, it is partly dynamically generated
<whitequark[cis]>
but making it really easy to use is a nice side effect
<whitequark[cis]>
the 1:0 part will change if you use the probe-rs applet as a second applet in a multi-applet bundle
<whitequark[cis]>
as a result, probe-rs can be completely independent from the glasgow toolkit (after you load the bitstream of course)
<whitequark[cis]>
btw, you can run SWD at speeds as high as 48 MHz
<wiebel[m]>
So of the 20b7:9db1:C3-20240821T182236Z the 20b7:9db1 is PID and VID, C3 the board revision, 20240821T182236Z is that the maufacture timestamp?
<whitequark[cis]>
C3-20240821T182236Z as a whole is the device serial number
<whitequark[cis]>
and yes, it's based on a manufacture timestamp
<wiebel[m]>
whitequark[cis]: Yeah I read this one. Thats awesome. The swd-openocd/gdb was not exactly fast.
<whitequark[cis]>
it barely even worked due to some issues, which i suspect were in openocd but i haven't proven it
<whitequark[cis]>
the new applet is so fast, i have to use offset sampling to shift when the data is being captured, because at the time of the posedge, the buffer grabs the previous cycle's data due to propagation delay
<whitequark[cis]>
in theory we could run it at speeds as fast as 80 MHz, but this results in some timing closure issues that i'm not quite sure how to tackle yet
<whitequark[cis]>
I've proven that it can work but it isn't reliable enough for general use
<whitequark[cis]>
that's faster than any of J-Link's probes
<wiebel[m]>
I've stumbled upon https://github.com/probe-rs/rusty-probe so yeah 48 MHz is perfect, just right to prevent me from buying another piece of hardware. ;)
<Attie[m]>
<whitequark[cis]> "Attie: do you have a need for..." <- no, but I really, _really_ want to play with it... (call me weird)
<Attie[m]>
[I'm also itching to have a go with the SWD applet, thank you / well done!]
<whitequark[cis]>
me too! i wanted to play with it since i first heard about 802.3cg
<Attie[m]>
how are you finding it?
<Attie[m]>
"just Ethernet"? any issues around the node role negotiation? and I think gigabit "requires" some more special cable / connectors, but I've not looked into it in enough detail
<whitequark[cis]>
this is 10BASE-T1S
zyp[m] has joined #glasgow
<zyp[m]>
I have some projects that'd benefit from SPE, but the connector situation is a problem
<whitequark[cis]>
the connector on the kit i have is just a screw terminal, lol
<zyp[m]>
there's a bunch of competing standards for SPE connectors, and they're all some combination of bad, expensive or unobtanium
<whitequark[cis]>
which i'm fine with... also could always run it over one of the RJs
<Attie[m]>
T1S/L looks great as a step up / alternative for CAN (for some of my recent projects)
<zyp[m]>
I'd e.g. be interested in running gigabit SPE over LC-CU connectors to save front panel space, but LC-CU is unobtanium
<whitequark[cis]>
Attie[m]: yeah this is what I wanted them for... want to collab? an MCU running smoltcp plus power+data over T1S as a drop-in "i want this to be networked" PCB you can solder into a projecy
<whitequark[cis]>
* yeah this is what I wanted them for... want to collab? an MCU running smoltcp plus power+data over T1S as a drop-in "i want this to be networked" PCB you can solder into a project
<whitequark[cis]>
(this is what smoltcp was created for)
FFY00_ has joined #glasgow
<Attie[m]>
oooohh
<Attie[m]>
i'm not in the right headspace to do this now, but yeah, let's talk later!?
FFY00 has quit [Ping timeout: 276 seconds]
<whitequark[cis]>
sure!
<jn>
is there a mix of "glasgow repl" and "glasgow multi", i.e. a quick way to start a REPL with multiple applets?
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<jn>
(or, to ask differently: what does it currently take to get roughly that result?)
<whitequark[cis]>
there isn't and that's part of why multi is considered experimental
<whitequark[cis]>
the problem is that each applet can have their own REPL
<whitequark[cis]>
the REPL functionality should probably be re-implemented so that applets talk to a "REPL server" which provides them with console input (or even Python code to run)
<whitequark[cis]>
it's unfortunately not trivial to build
<whitequark[cis]>
jn: for now I would suggest using `HardwareAssembly` to build whatever you'd like in a normal Python REPL and then use that
<jn>
noted; i'll try that at some point
<jn>
(my concrete problem right now is that i need jtag-pinout/probe plus a signal that should be high. there are plenty of ways to solve this, i haven't fully thought it through)
<whitequark[cis]>
so, the GPIO applet is very special right now in that you can freely add it to multi (eg as a third applet)
<whitequark[cis]>
let me add a mode where it just holds some signals at startup
<jn>
that would be useful!
<gruetzkopf>
there are fun can+t1s combo phys
<whitequark[cis]>
oooh, which?
redstarcomrade has quit [Read error: Connection reset by peer]
<gruetzkopf>
nvm they seem to be so unobtainium i can't even find the references anymore
<whitequark[cis]>
jn: okay, i have delivered
<whitequark[cis]>
glasgow run gpio -V A=3.3 A1=0 A2=H A3
<whitequark[cis]>
sets A1 to drive strong low, A2 to drive weak high, and samples A3