<_whitenotifier-f>
[GlasgowEmbedded/glasgow] attie 5fb1638 - manual: use/repl-script: add details about the REPL and Script interfaces, along with examples
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] attie 3f802df - manual: develop: add the beginnings of a style guide
<_whitenotifier-f>
[glasgow] whitequark closed pull request #446: manual: use/repl-script: add details about the REPL and Script interfaces, along with examples - https://github.com/GlasgowEmbedded/glasgow/pull/446
Lord_Nightmare has quit [Remote host closed the connection]
<_whitenotifier-f>
[glasgow] whitequark opened pull request #450: Fix JESD3 lexer to ensure checksum computes correctly no matter which newlines are used - https://github.com/GlasgowEmbedded/glasgow/pull/450
<_whitenotifier-f>
[glasgow] whitequark synchronize pull request #450: Fix JESD3 lexer to ensure checksum computes correctly no matter which newlines are used - https://github.com/GlasgowEmbedded/glasgow/pull/450
<_whitenotifier-f>
[glasgow] whitequark closed pull request #450: Fix JESD3 lexer to ensure checksum computes correctly no matter which newlines are used - https://github.com/GlasgowEmbedded/glasgow/pull/450
duderonomy has quit [Remote host closed the connection]
<_whitenotifier-f>
[glasgow] whitequark assigned issue #406: Add a flag to `glasgow factory` which indicates that the device has been modified from the original design - https://github.com/GlasgowEmbedded/glasgow/issues/406
<Attie[m]>
okay, starting with #406... I'd probably like to see a tag in version output too?
<Attie[m]>
like Linux's "dirty" thing
<whitequark[cis]>
that's close to how I did it, one sec, I'll show
<Attie[m]>
hmm... version doesn't currently poke at hardware, so that's non-ideal. the list output / serial number would be sensible though
<Attie[m]>
sure
<whitequark[cis]>
oh, you meant --version? no, that's just for the software stack
<Attie[m]>
yeah, exactly
<Attie[m]>
i revised my thinking - in the output of glasgow -vv we currently show "found" devices... but there's no indication of which devices was selected / actually sued
<Attie[m]>
*used
<Attie[m]>
so I'd propose adding that as a line, with this tag on any reported serial numbers(?)
<esden[m]>
* modifications to the existing case in the next batch are possible too. Increasing/decreasing margins. (constraining the PCB more in the case might be part of the way to mitigate the issue)
<esden[m]>
* As far as I can tell all the Early bird Glasgows that we sent to Mouser were shipped. The odd thing is that they say they fulfilled two Glasgows that were not "early bird" in exchange of not shipping two "early bird" which is odd. 🤷♂️ I don't have granular enough insight into what is going on to know exactly why and how that happened.
<esden[m]>
I think that is pretty much all I have to report this week.
<Attie[m]>
thanks Catherine - i'll take a look after the meeting / perhaps tomorrow
<esden[m]>
Ahh yes, diff pair thing... it is on my todo list and I will look into it.
<whitequark[cis]>
esden: maybe the not shipped early birds were undeliverable?
<whitequark[cis]>
weird
<Attie[m]>
re early bird vs non-eb... could this be Russia (?)
<esden[m]>
I think this is more likely folks that ordered an early bird and a non early bird glasgow ... that said it is very odd as the tracking info says that it was a pre order glasgow that was shipped, not even part of the campaign itself.
<esden[m]>
🤷♂️
<Attie[m]>
huh
<whitequark[cis]>
weird
<Attie[m]>
it's not in your control though, so best we can do is speculate...
<esden[m]>
(To be fair the fact that Mouser shipped things as quickly as they did exceeded my expectations... They are usually not that pulled together. The fact that there is some slippage like the above is more what I expect from them. :P)
<whitequark[cis]>
> The UART applet also keeps track of some statistics for us:
<whitequark[cis]>
this is just incorrect; the statistics is kept by the applet framework, you just happen to get a raw underlying FIFO interface with the UART applet
<whitequark[cis]>
(this is actually probably wrong and you shouldn't be getting that, this is a deficiency in how applet registers are handled)
<whitequark[cis]>
my main point of general feedback for the entire use/ tree is that the voice in which it's written is different from the rest of the manual
<whitequark[cis]>
my more specific feedback for use/repl-script is that it's written a bit like an operations log, without introducing any of the underlying principles (e.g. applet lifecycle phases--build/run/interact--and where in the lifecycle is repl/script plugged in and why)
<whitequark[cis]>
it also mixes general statements about the interface with statements that are very specific not just to the applet but to the specific setup that's being described
<whitequark[cis]>
the script mode and the repl mode are actually not exactly the same; the applet is allowed to override the REPL mode with whatever it likes (right now that's just "REPL with more predefined locals", but it could in principle be anything--unclear whether we want to keep that), whereas the script mode gets exactly those 3 locals
<whitequark[cis]>
I feel like this section would benefit from being split into "high level description of script/REPL mode" and "examples of using script/REPL mode", probably after a short theory section (maybe in an earlier doc) about applet lifecycle
<Attie[m]>
re checkboxes: thanks, i was planning to do just that... and bring the other items into the first message
<whitequark[cis]>
this isn't something I would expect of you; the theory I'm mentioning isn't really documented anywhere
<whitequark[cis]>
so it's understandable that a number of things would end up mixed together
<Attie[m]>
re stats: i thought I'd misspoken there, thanks for clarifying
<whitequark[cis]>
the UART applet is an early one so it does a number of Crimes, and the baud rate stuff for example is something you just Cannot query via iface right now
<whitequark[cis]>
which is quite cursed actually
<Attie[m]>
re voice: not at all surprised... i'll see what i can do to fit in
<whitequark[cis]>
really it should wrap the underlying FIFO into an UARTInterface like every other applet, provide read/write/flush, not silently drop data, etc
<whitequark[cis]>
and of course let you modify the baud rate at least via the iface
<whitequark[cis]>
switching baud rate is actually pretty common for bootloader type tasks, ESP32 does that
<whitequark[cis]>
(and you end up with some real cursed baud rates if you use the wrong crystal...)
<whitequark[cis]>
I haven't had the bandwidth to improve use/ tree and it provides real and tangible benefit to our users today, so I've been happy to merge it
<whitequark[cis]>
but it's something I'm looking to work on more directly in near term
<Attie[m]>
thanks
<whitequark[cis]>
oh, also, I never refer to just "Glasgow" (that's a city I guess)
<whitequark[cis]>
I've always used "Glasgow software", "Glasgow device", etc
carnevale999[m] has joined #glasgow
<carnevale999[m]>
Is there any up-to-date bom file that we can use to order the device in JLCPCB considering there are no stores currently selling the device and crowdsupply orders taking more than 6 months ....
<Attie[m]>
re "Glasgow" - ahh, thanks... I was wondering about that while writing it
<esden[m]>
I mean, there is the sync connector pin thing, but the solution for that is to cut them with flush cutters
<whitequark[cis]>
okay, I'm done fiddling with #457
<Attie[m]>
ty
<whitequark[cis]>
@esden might be interested too
<Attie[m]>
I think #312 is looking better now... i might have missed some items
<whitequark[cis]>
looks good
<whitequark[cis]>
what are common problems?
<Attie[m]>
fair question... i wrote it because I was kind of expecting things to come out of the woodwork... but... they havent?!
<Attie[m]>
(well done)
<esden[m]>
jwise0 (@_discord_256468461818085377:catircservices.org) the issue that Catherine experienced, was definitely not the sync connector or any solder joint. It was some kind of conductive debree probably caught between the case and the pcb, plus misalignment ofthe case. I don't think it is reasonable to put 3mm acrylic between the case and the pcb ... making it a THICC sandwich to mitigate that 😄
<Attie[m]>
we're +200 units in people's hands, and it's been surprisingly quiet here
<whitequark[cis]>
Attie: kind of funny, that... put so much work into making the device reliable only for no one to notice it
<whitequark[cis]>
(except for people who shipped hardware before. they will notice all right)
<Attie[m]>
honestly, I don't think I've had a single peep out of most of the people who bought from me
<jwise0[m]>
ahhhh. the idea is that you would line the bottom of the board with the vinyl to keep aluminum swarf or something left over from manufacture from wandering around and contacting the bottom
<Attie[m]>
it's been quite plesant to see a couple pop up again recently with a C3 in the photo
<whitequark[cis]>
Attie[m]: I've had this with Amaranth too, I think multiple people have shipped ASICs using it without so much as talking to me
<whitequark[cis]>
the curse of making software that works too well >.>
<Attie[m]>
amazing... pats you on the head (not being condescending at all)
esden[cis] has joined #glasgow
<esden[cis]>
Catherine: making things reliable is an unforgiving work... you will never hear from anyone if things "just work" :D
<whitequark[cis]>
no, some understand. but it's only those who went through it themselves. or something like it.
<whitequark[cis]>
years ago, Maya took one look at Glasgow and described it as being "designed properly", which is just about the highest praise you could get
<whitequark[cis]>
I sure heard that.
<esden[m]>
jwise0 (@_discord_256468461818085377:catircservices.org) yeah essentially what I want is another thicker layer on top of the anodization, just in case
<Attie[m]>
😀
<esden[m]>
and 1mil is definitely thicker! 😄
<jwise0[m]>
well, presumably this is on the board, not on the ano?
<Attie[m]>
between
<esden[m]>
the gasket will just sit in the case
<esden[m]>
between the board and the case
<Attie[m]>
i think i'm going to close out the meeting, unless anyone want's to add / i can bring it back on topic
<Attie[m]>
CS & gasgets update, #406, #312
<Attie[m]>
lots of other good PRs this week, but nothing that needs discussing?
<whitequark[cis]>
sgtm
<esden[m]>
jwise0 (@_discord_256468461818085377:catircservices.org) I will make a mockup out of paper and make some photos. It will be easier to show than explain. 🙂
<whitequark[cis]>
maybe have a list of PRs merged this week?
<whitequark[cis]>
that would be nice to look back through
<Attie[m]>
sure, will do!
duskwuff[m] has joined #glasgow
<duskwuff[m]>
maybe something more along the lines of a vinyl sticker?
<jwise0[m]>
I think I understand. I was thinking adhesive vinyl, stuck to the bottom of the board. if you are worried about swarf wandering around from manufacturing, it can still trap itself and short pads underneath the gasket. I have used approximately this, with my annoying terrible homebrew vinyl cutter, but if you used a Silhouette or other continuous feed vinyl cutter you could do this basically in mass production for very very very little
<esden[m]>
duskwuff (@_discord_237471182566195201:catircservices.org) I thought about it, but gluing something like that into the case is tricky...
<esden[m]>
it is better if it just is dropped in the case and sits flat
<jwise0[m]>
I guess if the concern is swarf shorting vs. chassis though a gasket would adequately address that
<esden[m]>
That is my hope
<esden[m]>
From studying the KiCad files and the case contact areas. The most likely contact I found is the trace on the very right side of the PCB. It is SDA, and it is very close to the edge of the case. If that is what caused the short, then a thin plastic material between board and the case edge would have helped.
<esden[m]>
I really wish we had a way to find out what caused the issue in the first place. 😦
<esden[m]>
The test pads for SCL/SDA are too far away from anything on the case to be the source of the issue. Even including the maximum extents of the alignment tolerance.
<whitequark[cis]>
yeah. all I can say with confidence is that I did observe it, and had another person observe it
<whitequark[cis]>
and it was quite consistent and independent of firmware loaded
<esden[cis]>
Yeah, makes sense. This is why I am taking it seriously.