<victorhooi[m]>
also - I saw there's a `glasgow safe` command - out of curiosity, if I just plug in the glasgow to usb-c, and connect it to a device under test - it won't do anything right? as in, it won't send any voltage down vcc until I explicitly do something - e.g. run an applet, right?
<victorhooi[m]>
I did manage to get a uart to the device 🙂 - however, after I quit the uart applet - the device is still powered on and running - I assume that's by design, right?
<victorhooi[m]>
if I want to shutdown the device (i.e. glasgow to stop powering it) - is running glasgow safe the proper way to do that?
<victorhooi[m]>
sorry for the barrage of questions - I'm definitely a newbie to a lot of this stuff - so I'm probably seeing your docs from a newbie's perspective
<victorhooi[m]>
* is there a beginner's overview somewhere of the glasgow hardware, and what all the parts/buttons do or mean?
<victorhooi[m]>
* applet, right? Or does it persist anything from previous startup?
<esden[m]>
S stands for Sense. This is the ADC input that allows you to monitor the target voltage. V stands for Voltage, and that can supply power to your target. G stands for Ground/GND. The pins you want to use are marked with numbers.
<esden[m]>
The two pins marked with a dot, are unused and not connected to anything.
<victorhooi[m]>
but not sure if that's a bit...obvious to target market for glasgow's
<esden[m]>
This short video you refer to took Joe weeks to make...
<esden[m]>
you can use glasgow voltage to query the voltages I think
<esden[m]>
and set the voltage limits which can be enforced if you have sense connected
<esden[m]>
also there is a follow function that allows the glasgow to follow the voltage it is sensing using the sense pin
cr1901 has quit [Quit: Leaving]
<esden[m]>
There is always more documentation that would be nice to have...
<esden[m]>
good documentation takes a lot of effort though, and I do not have the time to work on that even if I wanted to... unless I just stop fulfilling the campaign... and I am not sure this is actually what people want
<esden[m]>
others in the project did some fantastic work in my opinion to write good documentation, there is some very detailed and in depth hardware description of the revC3 that is coming down the pike: https://github.com/GlasgowEmbedded/glasgow/pull/544
<victorhooi[m]>
you mentioned a short video by Joe - which one is that?
<victorhooi[m]>
oh neat - that PR looks pretty useful - I can skim through that
<esden[m]>
humm I was assuming this is where the link went. I was wrong. I guess what I am thinking of are the workshop support videos he made. I would have to look for that.
<esden[m]>
Simple image supported "how to hook up uart" page might be useful as you mention. But unfortunately I don't have time to put that together. 😦
<victorhooi[m]>
yeah - I put together a UART dummies guide or something
<victorhooi[m]>
* - I might put together
<victorhooi[m]>
the device being powered on after you quite say, the uart applet - that's intentional right? And running `glasgow safe` afterwards to shut down the device - that's the right thing to do? (just dont' want to be doing the wrong thing, or putting the wrong thing in a video, aha)
<victorhooi[m]>
I did manage to get uart applet to create a pty device, so that I can use it with `esptool` to flash some firmeware to the device - however, for some reason, `esptool` doesn't seem to like the pty device from glasgow - weird
<victorhooi[m]>
so I'm guessing it's something wrong with how I'm using glasgow
sigstoat[m] has joined #glasgow
<sigstoat[m]>
an esp programmer is going to want to control some of the other lines on the serial port, which i don't think the glasgow uart applet supports. (not sure if they even can be supported through a pty)
<victorhooi[m]>
ah - what do you mean by other lines?
<sigstoat[m]>
based on that first stack trace, i believe it wants to manipulate the DTR and RTS lines.
<victorhooi[m]>
that's not a phsyical pin, is it?
<victorhooi[m]>
as in - I do have a little jumper shunt going across one of the GPIO pins to GND - which is meant to put the ESP8266 into bootloader mode
<victorhooi[m]>
(so that esptool.py can run)
<sigstoat[m]>
they are on a real rs232 port.
<sigstoat[m]>
the ftdi driver used for the chip in the tigard probably implements support for controlling them regardless of what's hooked up on the other end. so the esptool is happy, regardless of whether or not the esp actually reboots after the programming
<victorhooi[m]>
I'm still not clear on the whole UART vs RS232 thing...ahah - may need to google that - I thought one of them was the physical standad, and the other the protocol - but I may have that mixed up
<victorhooi[m]>
but either way - is this a physical limitation of the glasgow here - or something that could be added to the uart applet?
fibmod has quit [Ping timeout: 255 seconds]
fibmod has joined #glasgow
<sigstoat[m]>
i'm just another user, but i don't see why it couldn't be added to the applet.
gsuberland has quit [Remote host closed the connection]
gsuberland has joined #glasgow
<Wanda[cis]>
glasgow safe will disable all output drivers and voltage regulators, yes
<Wanda[cis]>
though if you have a revC3 you can just hit the reset button on the glasgow instead
<Wanda[cis]>
which will do the same thing, except it's hardwired (so will work even if firmware somehow malfunctions) and also resets the FX2
trh has quit [Quit: weg]
trh has joined #glasgow
<sorear>
if it works the same way as reconfiguration, it won't immediately tristate the outputs, vio will gradually fall over ~10ms during which output lows stay low, output highs track vio, until the threshold for the level shifters is reached
<Wanda[cis]>
it cuts power to the board
<whitequark[cis]>
<sorear> "if it works the same way as..." <- that's not true; please do not speculate like this.
<whitequark[cis]>
re: esptool, esptool should probably just be reimplemented as an applet
<whitequark[cis]>
the tricks it's doing with DTR/RTS aren't going to work; whether or not you even can do that with a pty, any extension to the pty interface implicitly screws over Windows users
<sorear>
I don't know how to honor that request without just stopping my contributions here entirely
<whitequark[cis]>
who knows. but we have a few bootloader support tools there, and i doubt esp32 is that much more complex to suppott
<whitequark[cis]>
the stubs may get annoying to manage
<victorhooi[m]>
both of those work with the tigard - are they using some of the tricks whitequark (@_discord_182174208896401419:catircservices.org) and sigstoat (@_discord_748665150114103306:catircservices.org) mentioned
<victorhooi[m]>
but you think if we did those tricks - it wouldn't work cross-platform, or might cause other issues?
<whitequark[cis]>
tigard is pretty much just a USB to full sized UART converter
<whitequark[cis]>
Glasgow is not
<whitequark[cis]>
it's a different class of device
<whitequark[cis]>
tigard doesn't use a pty; it is a real tty on the hardware level
<victorhooi[m]>
got it - fair enough - it does seem ike glasgow can definitely do a lot more - I'm still trying to understand it
<victorhooi[m]>
ahh
<victorhooi[m]>
so that's why it doesn't have the same issue then - because it's a real tty?
<whitequark[cis]>
it may be in principle possible to emulate a tty using CUSE on Linux only but the whole thing is beyond nightmarish because ttys were a mistake
<whitequark[cis]>
so I don't think anyone's in a rush to do that
<victorhooi[m]>
why are they a mistake?
<whitequark[cis]>
yes, tigard is simply a real tty, no tricks needed
<whitequark[cis]>
because they're extremely complex and very poorly specified
<whitequark[cis]>
nobody really understands the tty layer of Linux except for maybe Alan Cox
<victorhooi[m]>
got it - I'm going to do some more googling I guss to understand ptys and ttys
<victorhooi[m]>
lol - I just know them from using them - but never bothered to learn/understand this stuff
<victorhooi[m]>
also - while I'm lucky enough to have you here 🙂
<victorhooi[m]>
I noticed that glasgow reported something about frame errors when using UART - just curious how I see what those errors are?
<victorhooi[m]>
or what they might mean?
<victorhooi[m]>
and it seems to core dump when I quit UART as well - not sure if I"m doing that wrong (I tried to use ctrl + \ q to quit)
<whitequark[cis]>
"frame error" indicates the UART input has been low for more than a symbol time, which isn't allowed by the protocol
<whitequark[cis]>
ctrl+\ is only an escape character in tty mode; in every other mode it has the default meaning for your OS, which in this case is to forcibly terminate the application with a core dump
<whitequark[cis]>
unless it prompts you to do ctrl+\ don't do it
<whitequark[cis]>
(we have an open issue for improving both of these things)
<victorhooi[m]>
ah whoops ok
<victorhooi[m]>
what's the correct way to quit the UART PTY then?
<whitequark[cis]>
ctrl+c
<victorhooi[m]>
I really wanted to do a quick beginner's video, showing say, how to flash tasmota/esphome using glasgow
<victorhooi[m]>
or how to read some i2c sensors, and send it to influxdb (per the crowdsupply use-cases) etc.
<victorhooi[m]>
hmm ok - got it
<victorhooi[m]>
* got it (RE: ctrl c)
<victorhooi[m]>
I'll bear that in mind then
<whitequark[cis]>
if you need to use esptool it might not be quite as easy
<victorhooi[m]>
is there any way to get both STDIN/OUT on a UART, as well as creating a pty?
<victorhooi[m]>
or is it one or the other, with glasgow?
<whitequark[cis]>
not out of box, but it's easy enough to modify it to be that way
<whitequark[cis]>
or you could use `glasgow script`
GNUmoon2 has quit [Ping timeout: 260 seconds]
jstein has joined #glasgow
<victorhooi[m]>
do you mean modify the actual uart applet? Or is there some way an end-user can do it?
<whitequark[cis]>
i mean an end-user can modify the checkout freely
<whitequark[cis]>
glasgow isn't meant to ship as a black box you don't look into
<victorhooi[m]>
who would you use `glasgow script` to do it? I did look at the help. but I'm still confusd about run vs script - all I saw was that `script` lets you run a python file?
<whitequark[cis]>
yes. you would grab the contents of the def interact function from the uart applet and modify ti
<whitequark[cis]>
s//`/, s//`/, s/ti/it/
<victorhooi[m]>
hmm ok - I can look at the source for the uart applet
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
theorbtwo[m] has joined #glasgow
<theorbtwo[m]>
Oh, now I understand the hub75 applet telling me it can only be used in script mode.
<theorbtwo[m]>
In my (limited) experience, frame errors are generally either autobaud has not yet caught up, or the device isn't actually there (is mid reboot, doesn't have power, ...)
fibmod has quit [Ping timeout: 264 seconds]
<theorbtwo[m]>
(or wrong baud rate set, but I've almost always used autobaud with Glasgow, except when I know the rate from previous bits and want to see the first few chars down the line.)
fibmod has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
fibmod has quit [Ping timeout: 264 seconds]
fibmod has joined #glasgow
<whitequark[cis]>
<theorbtwo[m]> "In my (limited) experience..." <- yes