<tpw_rules>
ok last question, the new version says it wants the firmware updated. i thought all the early birds had the very latest? or is my version still a little old and that would be a downgrade. it's commit e9a9801 from 2023-09-20
<Attie[m]>
if you're running old software, that would probably downgrade your firmware
<Attie[m]>
it should say the firmware version in dmesg
<Attie[m]>
(or the product string - e.g: Product: Glasgow Interface Explorer (git 63287e31))
<tpw_rules>
hm, it is the same
<tpw_rules>
(very smart move)
<tpw_rules>
is there some sort of cache for the message "found revC3 device with API level 1"?
<tpw_rules>
(power cycling does not make that come back)
<tpw_rules>
((so nixpkgs does have the correct version as of now))
<emaste[m]>
esden (@_discord_269693955338141697:catircservices.org) thanks so much for including the allen wrench, I'm sure I have the right size one around *somewhere* but it meant I got to put it in the case right away (once my cat let me open the box) rather than hunt for it. Without one I probably would have lost the screws by the time I found the right allen wrench 🙂
<tpw_rules>
i would have expected a progress bar and a significant amount of time taken. in any case the git hash in the USB product string did not change.
<tpw_rules>
okay, is the API level a property stored in EEPROM somehow?
<whitequark[cis]>
it's hardcoded in the firmware
<whitequark[cis]>
API level is incremented each time there's an incompatible change in the USB API
<tpw_rules>
i accidentally used my new glasgow with an old version of the software tool from april and it said "I: g.device.hardware: found revC3 device with API level 2 (supported API level is 1)" the first time i used it. then it didn't do that with any subsequent commands
<whitequark[cis]>
yes
<whitequark[cis]>
it uploaded the firmware with API level 1 to RAM
<tpw_rules>
then i realized my mistake and used the new software tool and it said "I: g.device.hardware: found revC3 device with API level 1 (supported API level is 2)\nW: g.device.hardware: please run `glasgow flash` to update firmware of device C3-20230730T150252Z"
<tpw_rules>
okay
<whitequark[cis]>
without modifying the EEPROM
<whitequark[cis]>
yes, that too updated it in RAM
<tpw_rules>
so that explains it. when i saw that please run glasgow flash message it updated it in RAM
<whitequark[cis]>
we do need to document that, hm
<tpw_rules>
but it was already updated in EEPROM so the flash command didn't need to do anything
<tpw_rules>
it would be nice if the `list` command could show RAM and ROM versions and the API level?
<whitequark[cis]>
why
<whitequark[cis]>
like, there is no particular reason to care about it
<tpw_rules>
i guess that's the next step of inquiry i went down when it said i should flash it and failed
<tpw_rules>
but now that i realize there are different RAM and ROM versions then that matters less. will it only warn about flashing if the API level is different?
<whitequark[cis]>
yes
<tpw_rules>
but otherwise every time i use it it will load whichever version the software tool has into RAM?
<tpw_rules>
or again only if the API level is different?
<whitequark[cis]>
only if the API level is different
<whitequark[cis]>
the idea is that it doesn't touch the device if it seems like it would work (because that clears the device state entirely)
<whitequark[cis]>
but if it knows for sure it won't, it overwrites the firmware in RAM and continues
<tpw_rules>
it feels like it would be clearer to just stop and ask the user to flash
<whitequark[cis]>
if you flash you still get the old firmware in RAM
<whitequark[cis]>
so it's flash and reset or re-plug
<whitequark[cis]>
to achieve... exactly what would be achieved by just reloading the firmware
<tpw_rules>
i see. then maybe change the message to explain that it's doing something and how to stop that message
<whitequark[cis]>
er
<tpw_rules>
maybe only the new tool version has the changed message
<whitequark[cis]>
yeah it makes sense to say "; reloading firmware" or something
<whitequark[cis]>
the new tool version?
<tpw_rules>
the new software tool suggested to run glasgow flash to update the firmware due to the API mismatch. not sure if that was because 1 < 2 or because you added that suggestion in the new version
<tpw_rules>
something like "supported firmware has been uploaded to RAM; please run `glasgow flash` to write supported firmware to EEPROM of device C3-20230730T150252Z"
<whitequark[cis]>
the suggestion was added in the new version due to someone requesting it
<tpw_rules>
and issue that warning in all cases where the API level is incorrect and/or the firmware needs to be uploaded into RAM. (can the tool find a device if it has "no" firmware?)
<whitequark[cis]>
yes
<whitequark[cis]>
in that case it silently uploads the current firmware to it
<whitequark[cis]>
it takes 1-2s
<tpw_rules>
ok i think i've got a handle on all that now, thanks for the explanation
<esden[m]>
.uep (@_discord_456711311133376552:catircservices.org) congrats! 😄 I hope it serves you well! 🙂
brolin has quit [Ping timeout: 258 seconds]
<uep[m]>
only got the shipping notification a day or two ago.. rather unexpectedly quick, for australian expectations
<whitequark[cis]>
esden: do you think you can finish the revC3 branch?
<esden[m]>
Ohh wow that is very fast indeed!
<esden[m]>
I hope I can find some time for it this weekend.
<jscarsbrook[m]>
I've got a SD NAND flash (part: MKDV1GIL-AS) that I'd like to interface with Glasgow over SPI. Is there already an applet for interfacing with SD cards? Just checking before I go off and write my own 🙂
<chuckmcm[m]>
I may extend this to QSPI so I can test my peripheral with it.
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<jscarsbrook[m]>
Awesome. I'll see if I can make something for reading and writing SD cards based on that.
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
bvernoux has joined #glasgow
Eli2_ has joined #glasgow
Eli2 has quit [Remote host closed the connection]
Eli2| has joined #glasgow
Eli2_ has quit [Remote host closed the connection]
ar-jan has joined #glasgow
<lle_bout[m]>
After running `sudo dnf install yosys-devel nextpnr icestorm` on Fedora 38 then I was able to run `GLASGOW_TOOLCHAIN=system glasgow build --rev C3 uart` without issue so that's good!
<whitequark[cis]>
<lle_bout[m]> "After running `sudo dnf install..." <- any issues using the builtin toolchain?
brolin has joined #glasgow
<tpw_rules>
the uart applet is already awesome with one minor nit: newline rationalization
<whitequark[cis]>
elaborate?
<tpw_rules>
trying to read data from a device which uses \r as the line ending so the tty mode just prints the lines all on top of each other. piped through tr to fix that
<whitequark[cis]>
ah yes
<whitequark[cis]>
we could add an option for that for sure
<whitequark[cis]>
something like --newline=cr-to-crlf maybe?
<whitequark[cis]>
I want it to be very clear in what sort of transformation is performed (and be available in all modes, pty included)
theorbtwo[m] has joined #glasgow
<theorbtwo[m]>
...but defaulting it to on would break binary transfer.
<whitequark[cis]>
yep
<whitequark[cis]>
the default should be no transformation
<whitequark[cis]>
I really don't like it when tools mess with my data
<whitequark[cis]>
(case in point: XON/XOFF, if we ever get those, will be off by default)
<SnoopJ>
probably the behaviors that `io.TextIOWrapper` provides (via `newline`) are the ones that make sense
<whitequark[cis]>
that doesn't really make sense for glasgow
<SnoopJ>
mm
<whitequark[cis]>
TextIOWrapper has a readline function
<whitequark[cis]>
glasgow takes bytes from one side and stuffs them on the other
<SnoopJ>
So I don't mean *using* TextIOWrapper, I mean the possible modes of operation of the option (with the probable exception of the 'universal newlines' behavior)
<SnoopJ>
probably cr-to-crlf is the one most people would want though
<whitequark[cis]>
cr-to-lf is what i'm thinking
<tpw_rules>
i manage to keep breaking the analyzer applet with a FIFO overrun. even turning on pulldowns sometimes my device glitches enough. is there a way to set a threshold? like only capture at 1MHz?
<tpw_rules>
wouldn't people want crlf-to-cr?
<whitequark[cis]>
tpw_rules: nope!
<tpw_rules>
to-lf*
<whitequark[cis]>
the analyzer applet is pretty broken
<whitequark[cis]>
just like much of glasgow's software stack 🙃
<whitequark[cis]>
the hardware is solid and the HDL is getting there, but the software stack has really suffered from neglect in the intervening years
<tpw_rules>
i see
<whitequark[cis]>
a lot of very good work was done by Wanda to keep it at least up to date
<whitequark[cis]>
but considerably more work will need to be done before we are at a sustainable place (currently we just are not)
<tpw_rules>
does that imply you're not in a position for serious contributions yet?
notgull has quit [Ping timeout: 260 seconds]
<whitequark[cis]>
define serious contributions
<theorbtwo[m]>
I think my preference would be any-to-crlf. cr or lf input produces a crlf output. Keep track of a flag for what the previous input byte was. If it was a cr, and a lf is input, produce nothing.
<whitequark[cis]>
there is serious work ongoing (ex: Wanda's refactorings) but e.g. drive-by "drop this applet and run" contributions will not be sustainable if they happen en masse
<whitequark[cis]>
we will simply be overwhelmed with work that will never be completed
<whitequark[cis]>
it will take, at a minimum, several months before we are set up for anything like that
<tpw_rules>
i guess i'm not really sure what i meant by serious there. but still like patching for better newlines or a synchronous analyzer mode
<tpw_rules>
which FIFO is that overrun talking about ftr?
notgull has joined #glasgow
<whitequark[cis]>
patching for better newlines: completely OK, though it's actually a more complex problem than it seems
<whitequark[cis]>
like crlf-to-lf means that the remote side sending a single cr would appear to hang forever
<whitequark[cis]>
so cr-to-lf and lf-to-cr is the only modes that can be trivially supported
<whitequark[cis]>
alternatively: we define "device newline" and "host newline" then translate back and forth via an intermediate "newline" concept that is not a character
<whitequark[cis]>
i'm partial to that one
<SnoopJ>
seems like good impedance-matching to most use cases
<whitequark[cis]>
--device-nl=cr | --device-nl=lf | --device-nl=crlf, and you can also say --device-nl=cr,lf meaning both cr and lf are recognized but it's normalized to cr from the other side
<SnoopJ>
(at the cost of the abstraction in the middle, but maybe that's already a thing?)
<whitequark[cis]>
it is not
<whitequark[cis]>
unsure if it should be in software or hardware. hardware seems appealing, actually
<SnoopJ>
translation goes brrr
<whitequark[cis]>
so the character is transformed back and forth from an octet to a sum type of NEWLINE | CHAR of char
<whitequark[cis]>
pardon my french
<theorbtwo[m]>
Come to think of it, the abstraction in the middle can also be helpful for a bunch of other things. A flag bit says if this is a char or another "thing", and then you have 255 "other things" to play with for "newline", "break", "change of baud rate", and other strange things.
<SnoopJ>
yea, seems like it would have plenty of other uses which is why I wasn't sure if it was already on the table :)
<whitequark[cis]>
now you've reinvented 8b10b :p
<whitequark[cis]>
well, sorta.
<theorbtwo[m]>
...but now we are talking about something that is less of a self-contained patch to an applet, and more ... yeah, that.
<SnoopJ>
heheh
<whitequark[cis]>
and i really want it to be done via streams (which don't exist yet)
brolin has quit [Ping timeout: 260 seconds]
brolin has joined #glasgow
supersat[m] has quit [Quit: Idle timeout reached: 172800s]
brolin has quit [Ping timeout: 240 seconds]
feuerrot has quit [Read error: Connection reset by peer]
feuerrot has joined #glasgow
brolin has joined #glasgow
feuerrot has quit [Read error: Connection reset by peer]
feuerrot has joined #glasgow
brolin has quit [Ping timeout: 252 seconds]
bvernoux has quit [Quit: Leaving]
feuerrot has quit [Ping timeout: 255 seconds]
feuerrot has joined #glasgow
spaimacarpatilor has quit [Quit: Idle timeout reached: 172800s]
<lle_bout[m]>
Not at all!
<lle_bout[m]>
Since using the system one was mentioned in the docs and that it was said to be more efficient then I attempted it
<lle_bout[m]>
That's pretty much all I can do for now (no glasgow yet..) 🥲
<lle_bout[m]>
hmm maybe I can try contribute bash completion stuff, never worked with that before tho, but I just noticed it's not there
<lle_bout[m]>
at least in my setup
js[m] has quit [Quit: Idle timeout reached: 172800s]
icb[m] has joined #glasgow
<icb[m]>
It's here, and it's beautiful 🥲 The UPS driver was nice enough to put the box in a bag, since it's pouring rain here today
feuerrot has quit [Read error: Connection reset by peer]
feuerrot_ has joined #glasgow
brolin has quit [Ping timeout: 258 seconds]
brolin has joined #glasgow
hardkrash[m] has joined #glasgow
<hardkrash[m]>
For more newline conversion shenanigans I have had to interface with devices that required \r on input and responded with \n on output, so settings for input and output are also in a mix.
pie_ has quit []
pie_ has joined #glasgow
brolin has quit [Ping timeout: 255 seconds]
brolin has joined #glasgow
ar-jan has quit [Ping timeout: 272 seconds]
<whitequark[cis]>
that would be --device-nl=cr,lf
feuerrot_ has quit [Ping timeout: 272 seconds]
feuerrot has joined #glasgow
agg has quit [Ping timeout: 272 seconds]
agg has joined #glasgow
brolin has quit [Ping timeout: 255 seconds]
brolin has joined #glasgow
isabelburgos[m] has quit [Quit: Idle timeout reached: 172800s]