<threeflour[m]>
Where am I in the queue with order number 198373?
jstein has joined #glasgow
tahnok[m] has joined #glasgow
<tahnok[m]>
\o/ got glasgow reading from a GPS module with glasgow run uart -V 3.3 --pin-tx 1 --pin-rx 0 -b 9600 pty and giving the pty to gpsmon
<tahnok[m]>
thought I was doing something wrong as I expected to see NMEA messages immediately, but there must be some start transmitting command that gpsmon knows
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<radii>
I've been experimenting with `glasgow run analyzer` and I've got some improvements / bugfixes to discuss; is discussion here OK, or should I open github issues / PRs, or something else?
<radii>
alternatively, is anybody actively working on analyzer?
<whitequark[cis]>
I was thinking of just removing the current analyzer applet
<radii>
the concept is pretty compelling to me, but agreed the current one is perhaps too minimalist to be useful
<whitequark[cis]>
yeah
<whitequark[cis]>
it's unusable
<radii>
my favorite behavior so far is how the 1ns timebase causes pulseview to just oom my machine for any nontrivial capture length
<whitequark[cis]>
I also don't trust e.g. pulseview with direct USB access so they'll have to implement some network protocol or sth
<whitequark[cis]>
ouch
<whitequark[cis]>
having 128G of allocatable memory on my laptop has caused me to miss that
redstarcomrade has quit [Read error: Connection reset by peer]
<radii>
so is the direction you're thinking of to have a "headless" analyzer applet for glasgow, and have end users operate it via pulseview's UI?
<whitequark[cis]>
yes, or via glasgow script, or just via CLI if it makes sense
<whitequark[cis]>
PV is not the end-all and be-all and its development is really slow
<radii>
that makes sense to me! I'll avoid investing anything substantial into the current analyzer then and I'll keep tabs on development here.
<whitequark[cis]>
you still can't make a logic trace from a logic trace with a decoder whivh is really annoying
<radii>
agreed on pv, yeah
<whitequark[cis]>
s/whivh/which/
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<whitequark[cis]>
radii: there are no ETAs at all on when the analyzer gets replaced
<radii>
understood, no pressure at all! I'm pleased as punch with how glasgow is shaping up and happy for anything I can do to support
<esden[m]>
(the "is at Mouser" statement is bit misleading, at this very moment the Glasgows are on the way to them... and they will have them in hand by the end of next week... UPS Ground takes about a week to be delivered to them, then they have to do whatever they do before shipping. But they were pretty consistently taking 2-3 working days between "on the dock" to "shipping stuff out")
<esden[m]>
So I would expect that you will get shipping confirmations in the first week of June.
<stary2001[m]>
excellent, thank you
<esden[m]>
No problem stary2001 (@_discord_120574439812235267:catircservices.org) 🙂
<galibert[m]>
Nah, 111784 is just one you had answered before
<galibert[m]>
Mine way higher than that
<galibert[m]>
Don’t have the number handy, doesn’t matter
<theorbtwo[m]>
I would love to see an analyser mode that works nicely with nglscopeclient, I think.
<bburky[m]>
For a more powerful software serial port protocol... in addition to CUSE discussed here previously... there's apparently a RFC 2217 Telnet Com Port Option thing? It seems to (poorly) support DTR and RTS. Poorly because you apparently can't reliably get good timing of DTR and RTS for bootloader reset supposedly. I mention it though, because esptool and pyserial apparently support it.
<bburky[m]>
victorhooi (@_discord_345327372494569474:catircservices.org) If you really want to use esptool today via glasgow uart, you should be able to use `--before no_reset` to skip DTS/DTR reset and manually put your esp device into bootloader mode first (probably have to tie GPIO0 to ground). It's probably easier Tigard for now though.
<bburky[m]>
I left some notes on the GitHub issue above.
<whitequark[cis]>
ouch, Telnet
<whitequark[cis]>
we could definitely add support for that
<bburky[m]>
not my favorite either. But pyserial can do the server bits for you, so if it's not too much code might be an ok additional option beside socket in uart?
<whitequark[cis]>
it's the best thing to a standard we have
<bburky[m]>
"closest thing to a standard" was indeed accurate though
<bburky[m]>
🙂
<whitequark[cis]>
I wonder if we should have that in the UART applet, or have a separate "rs232" one
<whitequark[cis]>
I'm leaning towards the latter
<bburky[m]>
not sure, yeah. if you ever added other rs232 protocols, you may want to organize them separately, sure. I assume you could resue code between them easily enough? autobaud would be nice for rs232 too, not just uart
<whitequark[cis]>
other rs232?
<bburky[m]>
I mean like CUSE or something someday, unsure if that's more tty or rs232
<whitequark[cis]>
I'm not so fond of CUSE for multiple reasons, including that it's Linux-specific
<whitequark[cis]>
RFC2217 seems like a way better option
<bburky[m]>
(there's also a completely insane option... it would be fun though: add a `glasow://` protocol to pyserial. If you inject classes under `serial.urlhandler` it will apparently load them from `serial_for_url()`. I am unsure if this was meant for external libraries to extend though, or for internal use only https://github.com/pyserial/pyserial/blob/v3.4/serial/__init__.py#L43 )
<bburky[m]>
oh, no I finally read the whole docstring. It is meant for extension, but you're not supposed to use `serial.urlhandler`, but the client app is supposed to register the class. Still very python specific, so not great
<whitequark[cis]>
what would it do?
<whitequark[cis]>
build and load a glasgow applet?
<whitequark[cis]>
that's actually not completely unreasonable, our interface is a bit too immature for external consumption though
<theorbtwo[m]>
I tend to think of rs232 as mostly the voltage level standard, which we don't (and can't) properly support. Rs232c, which most people think of identical, is a current-level variant. (I was involved with using an actual teletype a while ago, this sort of thing comes up.)
<bburky[m]>
glasgow doesn't currentlly work as a library so not yet, no. But you could have e.g. esptool run glasgow in-process
<josHua[m]>
careful now. my unit is on the way to me and I will soon begin hacking on it. and if I don't end up figuring out a better solution before then to get a handful of UARTs into random chunks of my system, my proposed solution is going to end up with Catherine making a pilgrimage to Waffle House
<theorbtwo[m]>
My fork has some support for fiddling around with random pins next to running a UART, but I didn't have to worry about interfacing to other bits of software, I just had fun adding extra control-\ commands.
<whitequark[cis]>
Waffle House?
<josHua[m]>
i.e., the place where one gets into a fistfight
<whitequark[cis]>
oh!!!
<whitequark[cis]>
man, now you're making it tempting
<whitequark[cis]>
re: glasgow working as a library: it does, you can use it quite easily yourself
<whitequark[cis]>
as long as you're willing to conscript some random Python object into working as an arguments namespace
<whitequark[cis]>
it's like six lines of code to instantiate, build, and run and basic applet
<whitequark[cis]>
that API is considered internal and unstable, and I will break it, but you can do it
<bburky[m]>
hmm, weird, but does sound usable. thanks. that's useful
<whitequark[cis]>
what is the weird part?
<whitequark[cis]>
it was always intended to be used as a framework
<whitequark[cis]>
it's just that the current API is so bad I am 100% confident it will change
<whitequark[cis]>
the way argparse is used is completely unholy
<bburky[m]>
a python api using command line args is what you're saying right? weird. but yeah, this makes sense today
<whitequark[cis]>
well, it makes sense of objects
<whitequark[cis]>
* well, it uses objects
<bburky[m]>
like, not actually executing glasgow as a separate process, but passing argeparse objects to it?
<whitequark[cis]>
those objects happen to need to have exactly the same attributes as what argparse would create
<whitequark[cis]>
but they don't need to come from argparse at all