<d1b2>
<Strauss> Is Glassgow a universal debugger? A beefed up BMP?
<whitequark>
yes and no
<whitequark>
glasgow would never really have a gdbserver right on the device, so it won't be as zero-configuration as BMP
<whitequark>
but, conversely, its use of an FPGA to do protocol conversion means it can support a lot more different protocols, and (perhaps counterintuitively) it is easier to develop new ones
<whitequark>
right now there's no SWD or ARM JTAG support at all
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTweV
Stormwind_mobile has quit [Ping timeout: 260 seconds]
<_whitenotifier-f>
[glasgow] attie commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTwI4
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTwqa
<_whitenotifier-f>
[glasgow] attie commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTwmO
<d1b2>
<Lofty> Well I ended up joining the 1b2 Discord
<whitequark>
o/
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTwmS
<hell__>
I wonder if your own messages from the bridge get highlighted on irc
<gruetzkopf>
yup
<_whitenotifier-f>
[glasgow] attie synchronize pull request #215: Update SPI signal terms to COPI / CIPO - https://git.io/JTU4c
<d1b2>
<Attie> I've never managed to stick with IRC unfortunately... and I lost my name a while back
<whitequark>
that's why we have the bridge
<d1b2>
<Attie> yay!
<whitequark>
i recognize that IRC isn't as broadly liked as it was before (and frankly isn't that good, at least if we aren't talking IRCv3 which we probably don't)
<whitequark>
i'd really prefer a matrix bridge though so i can actually tab-complete the names of people on discord
<d1b2>
<Attie> i gave it a good few goes over the years, but oh well
<tnt>
Not sure if matrix would bring tab completion for discord. There is not really per-room membership on discord, if you're on the server you're automatically in all the public channels.
<d1b2>
<Attie> seems like matrix.org becomes the middle-node, with bridges into other networks...? the IRC bridge is stable, but discord is currently beta
<d1b2>
<Attie> @tnt the IRC bridge certainly seems to make a user per real-user from either side
<DX-MON>
To be fair, being able to tab-complete IRC users from discord is itself, to me, a compelling reason to go matrix bridge
<d1b2>
<Attie> might be worth a trial somewhere else, to see if its up to the task yet
<DX-MON>
but tnt does make a good point with how many users there are on Discord which.. would certainly expand out the user list here by a lot
<whitequark>
ohhhh
<whitequark>
well that's yet another way in which discord sucks :/
<whitequark>
i never quite realized that
<whitequark>
maybe we can make a badge or something like that that could be applied to people on discord side to bridge them to IRC transparently?
<whitequark>
iirc discord supports this functionality
<DX-MON>
it'd be interesting if matrix could read the notification status of a channel, for a user, and use that to determine if the user should be bridged
<whitequark>
hell, even a bot command would work
<DX-MON>
and yeah, badges/@-groups
<d1b2>
<Attie> I wondered if the "has interacted with channel" may be the trigger - makes the initial contact a little more difficult, but after that, it'll work
<whitequark>
i'm ok with occasional users not being "puppeted" (in matrix terms) even
<DX-MON>
what'd be most interesting to me is, how does it handle "User already exists in channel for reals, and in Discord"
<whitequark>
it's really when i have to type Attie's name (e.g.) every single time that becomes annoying
<whitequark>
DX-MON: usually these bridges apply a suffix. with matrix-irc it'd be whitequark and whitequark[m]
<DX-MON>
aye, honestly same from the Discord side especially when you're not quite sure if you're accidentallly pinging the individual or are
<DX-MON>
ah, that works
<DX-MON>
ohlook.. Discord just crashed for me "Illegal instruction (core dumped)"...
<whitequark>
i'm registering on matrix.org and the captcha says "Select all images with *bridges*"
<whitequark>
very topical
<DX-MON>
ahaha, indeed
whitequark[m] has joined #glasgow
<whitequark[m]>
hi from matrix
<d1b2>
<Attie> o/
<DX-MON>
oh, that works very nicely
<whitequark[m]>
it's really a very smooth experience. you just join #freenode_#glasgow:matrix.org and that's it
<d1b2>
<Attie> though your whitequark[m] doesn't seem to be in the user list...
<DX-MON>
just have to talk Esden into joining matrix to the Discord server XD
<whitequark[m]>
Attie: I'm only bridged to IRC
<DX-MON>
Attie, I bet that's fixed with their Discord-side integration..
<whitequark[m]>
Discord bridging is actually what I'm asking for, here, instead of the d1b2 bot
<d1b2>
<Attie> ahh yes, fair
attiegrande[m] has joined #glasgow
attiegrande[m] has left #glasgow [#glasgow]
<_whitenotifier-f>
[glasgow] electroniceel opened issue #219: Firmware support for INA233 on revC2 - https://git.io/JTw0t
<_whitenotifier-f>
[glasgow] electroniceel assigned issue #219: Firmware support for INA233 on revC2 - https://git.io/JTw0t
<_whitenotifier-f>
[glasgow] electroniceel opened issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JTw0C
<_whitenotifier-f>
[glasgow] electroniceel opened issue #221: Qualification tests for revC2: post INA233 - https://git.io/JTw0R
<whitequark>
hey, does anyone want to pair with me reviewing revC2 changes?
<whitequark>
i need to finally merge that PR but i feel like i've been running on 5% of mental capacity for the last two months, so it would help if i didn't have to do it alone
<electronic_eel>
I'm just going through the changes and fill the list of tests to do on the hardware samples
<electronic_eel>
so I could work with you
<whitequark>
sounds good, when do you have time?
<electronic_eel>
now would work, or tomorrow evening
<whitequark>
cool, i'll go eat something and start
<electronic_eel>
re merging: there are always people building a glasgow themselves and they probably take the current head version. so we may want to postpone that a bit until we have tested the revC2 samples
<d1b2>
<Attie> I'd be happy to give my thoughts too, but I'm a bit new to the group so happy to defer to others
<whitequark>
ack
<whitequark>
Attie: your (or anyone else's) review is most welcome
<electronic_eel>
Attie: yes, your help is appreciated
<DX-MON>
fresh eyes tend to find things the tired ones haven't noticed because they see the project too much
<whitequark>
I was mostly asking because I really need to pair with someone in particular to get through it myself
<d1b2>
<Attie> ok! I'll take a look, can't do now though, hopefully early next week
<whitequark>
not because I want only one more person to look
<d1b2>
<Attie> yeah, understood
<whitequark>
it's kind of grimly ironic that programmers practice peer review in a lot more healthy and useful way than academics who invented it
* Lofty
wishes they knew enough electronics to help
<DX-MON>
hah, indeed wq
<DX-MON>
(and even then we're kinda terrible at it!)
<whitequark>
it depends on the project, but yeah, easy to fall into similar traps
<electronic_eel>
Lofty: your help is also appreciated. asking questions about a detail you don't underrstand sometimes helps re-thinking it and uncovering some issue
<whitequark>
^ agreed
<electronic_eel>
what makes schematic reviews harder than code review is that you don't have a useful diff
<d1b2>
<Attie> though I do diff PDFs with good effect!
<Lofty>
(huh, the bot pings me on Discord if I get a mention on IRC)
<whitequark>
the advisor for my group in uni said something along the lines of "i am very slow, so please explain everything to me" as a way to stimulate that approach
<whitequark>
electronic_eel: there are schematic diffs
<d1b2>
<Attie> happy to share a script if you'd like - highlight changed sections, assuming not too much has changed
<whitequark>
hold on, i subscribed to a service which does this a long time ago... they introduced kicad support at my request (among many other people of course) but i never quite used it
<electronic_eel>
the basic structure has'nt changed, but some stuff was moved around to make more space for new additions and so on
<Lofty>
On the other hand I'd feel bad if you guys had to give me a crash course on electronics just so I could make sense of things
<Lofty>
But I can rubber-duck a bit at least
<whitequark>
i'm frankly not good at electronics either, which is why I collaborate with much more skilled people like awygle, marcan and electronic_eel
<hell__>
then I have no idea about electronics
bvernoux has joined #glasgow
bvernoux1 has joined #glasgow
bvernoux is now known as Guest95201
bvernoux1 has quit [Read error: Connection reset by peer]
Guest95201 has quit [Ping timeout: 256 seconds]
bvernoux has joined #glasgow
<whitequark>
electronic_eel: okay, i'm back
<whitequark>
let's dig out the service i was thinking of
<electronic_eel>
ah, layout diffs. shouldn't we do schematic review first?
<electronic_eel>
then compare cadlab with the pdf attie posted
<whitequark>
oh yeah, i was just going through commits in order
<whitequark>
to see what the cadlab UI offers
<whitequark>
hmmm
<whitequark>
so the schematic diff seems to work best interactively
<whitequark>
electronic_eel: idk how strongly i'll recommend it. it's a bit rough at edges but it sure beats looking at diffs of pdfs without being able to go through single commits
<whitequark>
worth checking out and i'll use it for revC2 but i'm not sure if it'll become a daily driver for me
<electronic_eel>
I'm just registering there
<electronic_eel>
do I need to setup glasgow again or can I just re-use the project you created there?
<electronic_eel>
atx: the reason is that the port headers should just have stuff on them that is protected, so that you can for example short it without causing issues
<whitequark>
(i will add anyone else who wants it as well)
<d1b2>
<atx> Right, good point
<electronic_eel>
atx: there will be a dedicated addon connector in revD. there will be 5v, 3v3, i2c and some other nice stuff on it
<whitequark>
we effectively decide to NC the remaining two pins on the shrouded connectors, right?
<whitequark>
since i can't imagine anything we *can* put on them following our decisions
<electronic_eel>
yes, nc. but you could use them for example to solder wires to testpoint or something similar, but on your own risk of course
<whitequark>
i kinda wish we had some nice way to put an ID chip there but i don't really see how
<electronic_eel>
we will put a nice id solution in revD and maybe backport that to revC3 or similar
<whitequark>
yeah but that won't work over a ribbon cable
<electronic_eel>
two ribbon cables?
<whitequark>
:/
<whitequark>
the only thing i can come up with is "parasitic power i2c" but it embodies everything i don't like
<electronic_eel>
if you really want to use ribbon cables often, you could make a stub-addon going to a bigger ribbon cable connector
<whitequark>
"1-wire EEPROM" is *almost* it
<whitequark>
we just don't have any way to drive that from the FX2
<whitequark>
think DS28E05
<whitequark>
aanyway
<electronic_eel>
whitequark: were you able to diff the wip-revC2 branch to master on cadlab? I get "We couldn't process your request"
<electronic_eel>
hmm, is there something where you can hover over a particular change in the graphic and get the commit that did it?
<electronic_eel>
that would be useful
<whitequark>
not that i know
<whitequark>
i normally review in the other direction
<whitequark>
i.e. go through commits, oldest to newest
<whitequark>
since i not only care about *what* changed but also *why* it changed
<electronic_eel>
yeah, but often there is some back and forth for the same block and if there are enough changes it is more economical to just look at the last version
<electronic_eel>
or maybe get a blame with all changes that touched a region you draw with the mouse?
<whitequark>
yeah, i get what you mean
<whitequark>
it's just i don't even use that workflow with text
<whitequark>
if there's back-and-forth i'm interested why!
<whitequark>
assuming it's not just someone's wip changes which should be squashed
<whitequark>
(though it's true that squashing changes is hard to impossible with ECAD files)
<electronic_eel>
this is a wip-branch, so I guess there is some back-and-forth that was not squashed
<whitequark>
right
<whitequark>
i actually try to distinguish between wip-branches (these are just any branches that are not long-term, like revC0 and such) and wip-commits
<whitequark>
but, again, i can't really ask others to do that with ECAD files
<electronic_eel>
yeah, with source code that is reasonable, but not with ecad files. at least not with the kind of kicad<->git integration we have now
Th3Fanbus is now known as hell__
<whitequark>
wow there are a *massive* amount of revC2 commits
<whitequark>
i'm *still scrolling*
<electronic_eel>
hehe, still set on wanting to review each and every of them?
<whitequark>
well, how else?
<electronic_eel>
look just at the diff between revC1 and revC2? and if something is unclear, search for the checkin that implemented it?
<whitequark>
mhm
<whitequark>
i guess a lot of the changes are very nicely described by esden in the commit msg
<whitequark>
like i don't have to drill into "revC2: Updated a bunch of the footprints to the upstream versions. This change seems like a big diff but it only really changes SOIC-8 and MSOP-8. They mostly bring roundrect changes and increase pad length for better fileting."
<whitequark>
i'm sure it's fine
<whitequark>
so that simplifies review a lot
<whitequark>
you know, i kinda wish we could have a micro-B assembly variant
<whitequark>
but i know that's likely unviable
<electronic_eel>
I know you really prefer micro b...
<whitequark>
yes, and the more C there is in my life, the more i prefer it
<whitequark>
the last time i had a device that didn't work with native c but worked through c-µb adapter was *yesterday*
<electronic_eel>
now while i have to stock up a bit on c cables, i much prefer the mechanical side of c
<whitequark>
the mechanics is fine
<whitequark>
it's not *perfect* (there's the problem where you have "transmissible" connector failure) but it's okay
<whitequark>
the firmware aspect of it sucks far more than i have ever anticipated
<electronic_eel>
the whole "which devices charges which" is just messed up
<whitequark>
why would a 2.0 only device not enumerate through a C-C cable? i have no fucking clue and no way to debug it
<whitequark>
i even have the device schematic, i don't think it has a PD controller
<whitequark>
well... what passes for schematic in mediatek, anyway. with censored pin names
<electronic_eel>
does it have the correct resistors on the cc lines?
<smeding>
USB-C kinda feels to me like someone showed the USB-IF that joke about having to rotate an usb connector 3 times and they set out to build an entire specification around making that joke impossible
<whitequark>
smeding: i mean, arguably that's how usb should have worked from the start
<whitequark>
it genuinely sucks that you have to flip USB connectors
<whitequark>
now of course you can get reversible A and µB just fine
<whitequark>
but I suspect the reliability of those cables is bad
<smeding>
idk, i've never been that bothered by it, but it's entirely possible that that is just me
<whitequark>
anyway, the PD spec predates type-C
<whitequark>
(the version of PD that worked with A/B is an abomination which has thankfully never been used in the real world, but that's the timeline)
<smeding>
oh, huh
<whitequark>
electronic_eel: i... can't know, because the resistor values are also censored
<electronic_eel>
measure them?
<whitequark>
don't have the device at the moment
<whitequark>
but yeah i might next time
<whitequark>
what i was complaining about is that PD analyzers are unnecessarily expensive to make
<whitequark>
with how shitty PD is in practice, it would have been good to at least be able to figure out *why* things break
<russss>
if you wanted to be evil with USB-C I guess you could make a device where you had to invert the connector several times before it would work
<electronic_eel>
I guess if you work with usb a lot, you should buy/make some adapters that break out each pin, allow to power from a lab psu and so on
<whitequark>
but no, you need a special device only chromeos people made, which is not even easy to manufacture
<whitequark>
this won't help
<whitequark>
you have to have a PD analyzer and the levels on that pin are so low that you can't even use a glasgow to do it
<whitequark>
you *have* to use a special device whose only purpose is to be a PD analyzer
<whitequark>
because it needs a PD AFE
<whitequark>
to put it bluntly i consider everyone who signed off on every version of PD incompetent
<whitequark>
it is hands down the worst part of USB
<electronic_eel>
i'd just begin with a barebones breakout that would allow you to easily get at each connector and hang a scope between two devices talking to each other
<whitequark>
check the box engineering and a total lack of systems thinking
<whitequark>
electronic_eel: that's not very useful
<whitequark>
i need a 4b5b decoder, a fucking *descrambler*, and a logic analyzer to actually make sense of it
<whitequark>
yes, they use a scrambler for a glorified UART
<whitequark>
because PD 1 used to do BFSK over Vbus and they didn't remove that part for some reason
<electronic_eel>
ask azonenberg, he'll add a pd decoder to scopehal
<whitequark>
there's one in pulseview
<whitequark>
the problem is that you can't simply continuously capture PD messages with something like a rigol
<whitequark>
i'm well aware that i could do that, or use some comparators and a knife to make a tee cable, or something
<whitequark>
my point is that i *should not have to do this*
<electronic_eel>
ah, ok, so you need a phy to be able to connect a streaming la or glasgow
<whitequark>
yes
<whitequark>
effectively a PHY made from discretes
<whitequark>
you can get integrated PD microcontrollers but they're a nightmare in their own regard
<electronic_eel>
you don't want that for a debugger, they have bugs on their own and you will get confused where the bug is from
<whitequark>
precisely
<gruetzkopf>
i've done the "Attiny as comparator because i had one and not a comparator" thing to capture PD
<whitequark>
gruetzkopf: i've used HX8K differential inputs
<whitequark>
for the exact same task
<gruetzkopf>
nice.
<whitequark>
cursed.
<gruetzkopf>
that often overlaps in my line of business
<whitequark>
indeed
<whitequark>
anyway, i even own some commercial PD analyzers
<whitequark>
which are useless
<gruetzkopf>
^
<whitequark>
well, they are okayiiiiiish maybe for debugging phone charging problems
<whitequark>
but not VDM negotiation problems
<gruetzkopf>
(i really need a synthesis workflow for relay logic)
<electronic_eel>
i think for use in glasgow usb c is ok, as it is just a very basic 2.0 device without any pd and so on
<whitequark>
yes, which is why i was not opposed to that change
<electronic_eel>
so very little probability for something to go wron
<electronic_eel>
g
<whitequark>
for revE we will sadly have to actually use PD and i do *not* look forward to it
<gruetzkopf>
i'm thinking of implementing PD
<gruetzkopf>
not because i really want to, but because i may need it
<whitequark>
if there was a rust library for PD i would run it on the fx3
<whitequark>
it would need the cursed discrete PHY but i'm not sure if that's any worse than existing PD solutions
<gruetzkopf>
are there any non-terrible ones?
<gruetzkopf>
(i could kinda really use azonenbergs "why does this not exist" product
<whitequark>
existing? not sure. i suggest not using anything from TI.
<gruetzkopf>
GigE <-> USB-C with bidirectional power
<whitequark>
oh
<whitequark>
ohhh *that*
<whitequark>
don't think revE can quite use it because half of the network stack runs on FPGA and half on FX3
<gruetzkopf>
yeah, but if i really make that quite a lot of it (PD stack) should be recycle-able
<whitequark>
oh!
<electronic_eel>
I think we can postpone power design to when we actually do revE dev, should get revC out of the door now
<whitequark>
yeah i agree, i got distracted complaining about typeC
<whitequark>
hm, cadlab shows a lot of spurious diff
<electronic_eel>
you mean like all the diodes?
<electronic_eel>
i think the symbol was changed a little by a kicad upgrade or similar
<whitequark>
no, the commit that changed the USB connectors has diffs related to like half the board
<whitequark>
*connector
<electronic_eel>
ah, you are comparing at checkin level
<d1b2>
<Attie> i'm not familiar enough with KiCAD yet to know what this really means... but I feel it should be fixed. Click OK seems to be harmless, but it still makes me nervous.
<whitequark>
Attie: sounds like your kicad libraries are out of date
<whitequark>
or maybe our schematic
<d1b2>
<Attie> i can't comment on the former, but re latter - clicking okay results in some changes in-repo
<electronic_eel>
Attie: what kicad version do you have?
<d1b2>
<Attie> v5.1.0
<electronic_eel>
hmm, that is... like ancient
<d1b2>
<Attie> ... i'll update and see if it persists
<electronic_eel>
check if you distro packages the libs separately, if yes, make sure to update them too
<d1b2>
<Attie> will do
<whitequark>
electronic_eel: can you explain how CDS0D323 works in this context?
<whitequark>
oh wait it's just a TVS
<d1b2>
<Attie> hm, i've installed 5.1.7 (latest for download, I'm on windows), and now it's doing the same thing, but for J1 / the USB C connector instead
<Lofty>
gruetzkopf: (i really need a synthesis workflow for relay logic) <--- this was probably a joke, but it's more feasible than you think
<d1b2>
<Attie> didn't expect that to be tied to the version (and thought I had a more recent version installed!)
<d1b2>
<Attie> i'll investigate more later
<gruetzkopf>
i know it's fairly feasible
<gruetzkopf>
i even have (two types!) of FF relays ;)
<Lofty>
Feasible as in "A day's work with Yosys"
<d1b2>
<Attie> i'm heading off - happy reviewing
<Lofty>
Take care Attie
<d1b2>
<Attie> :)
<whitequark>
electronic_eel: okay, i see how the protection mechanism with INA233 works now
<whitequark>
i remember not liking it at first, that was wrong. it's a good mechanism
<electronic_eel>
yeah, it is just a tvs, but one that allows up to 36V
<whitequark>
though it's funny that we have FPGA *and* diode logic on the same board
<whitequark>
that's spanning like what, 40 years?
<electronic_eel>
oh, you mean the shutoff thing via the ina233
<electronic_eel>
diode logic never gets old
<whitequark>
yes
<whitequark>
h
<whitequark>
*hm, question: why can't D14 be connected after the resistor?
<whitequark>
the EN input of TPS73101 is high-impedance, right?
<whitequark>
so the resistor between FX2 out and EN input can just as well serve as LED current limiter
<electronic_eel>
but then the led would lower the voltage on the en input
<whitequark>
oh, of course
<whitequark>
i can't come up with any other network that would do what i want, so FX2 controlled it is
<electronic_eel>
there are these multifunction logic gates, lvc58 and similar. I guess one could build what we want out of these. I tried it at first, but it became too complicated for me to understand it instantly, then I switched back to good old diode logic
<whitequark>
electronic_eel: ok strictly speaking
<electronic_eel>
we wouldn't save any parts with the logic gate, just make it more complicated. that isn't worth it
<whitequark>
the Vf of the LED is strictly higher than the threshold of EN input
<whitequark>
so we *could* move the LED after the resistor
<whitequark>
but it feels a bit gross
<whitequark>
and, perhaps more importantly, the FX2 still has to light the red ERR LED, which is the one the operator will actually notice
<electronic_eel>
the Vf of the diode is dependant on model and temperature, makes it harder to rebuild with other parts
<Lofty>
I do actually understand the LVC58
<whitequark>
so beyond removing two footprints it is not doing much for us
<whitequark>
in terms of user experience during FX2 fault
<Lofty>
So I guess that's something I could help with, if anybody cares.
<whitequark>
electronic_eel: yes, that dependence is why it feels a bit gross to me
<whitequark>
it seems more valuable to allow swapping out different LEDs here trivially than to do this hack
<whitequark>
especially since, yet again, the FX2 will need to actually alert the user anyways
<whitequark>
(one might call me paranoid since i've never seen or heard of an FX2 failure on Glasgow in the wild...)
<electronic_eel>
Lofty: I would have gotten it to work with a multifunction gate too, I use them quite often for other stuff. but here I thought we didn't gain anything by using it. So no need to go into that direction
<Lofty>
Fair. The '99 is also quite handy.
<electronic_eel>
the 57, 58, 99 are all in my components box, I like little logic
<whitequark>
i should check these out
<whitequark>
first time i hear about lvc58
bvernoux has quit [Quit: Leaving]
<whitequark>
uh, what's the actual p/n? it's ungoogleable
<Lofty>
74LVC58
<Lofty>
Sorry, 74LVC1G58
<electronic_eel>
oh, right, my bad
<whitequark>
whoa this is sweet
<whitequark>
someone should make them a synthesis target
* whitequark
looks at Lofty
<electronic_eel>
don't remember which one of these multifunction things it actually was that I was trying to use here
<electronic_eel>
if we really wanted funky things here, we should use a greenpak
<whitequark>
uhhhhhh
<whitequark>
as someone who worked on the FOSS greenpak toolchain, i think that would be a disservice to everyone self-assembling boards
<whitequark>
also the GP4/GP5 packages are a PITA
<electronic_eel>
yeah, not the right tool for self assembling
<Lofty>
I found it was better to use the LVC1G99s though
<electronic_eel>
that was building a picorv32 out of little logic?
<Lofty>
Yes.
<Lofty>
SERV is obviously better for this, but it needs a register file
<Lofty>
And finding a chip that can act as one is... Ugh.
<electronic_eel>
I guess routing that will be fun. you wanted to learn about electronics? a nice project to improve you skills in emi handling and debugging...
<Lofty>
Without a register file it'd be going nowhere fast.
<whitequark>
yeah i'm probably not going to use cadlab beyond revC2
<whitequark>
it's very slow and the way it does navigation strips context from changes
<whitequark>
the graphical diffs have so many false positives as to be almost unusable
<Lofty>
Ouch
<whitequark>
i'm sure the developers are doing their best but... well
<electronic_eel>
I like the idea, but they'd need to really speed it up and they'd need to add the stuff about blame i posted above to make it usable for me
<whitequark>
yeah
<whitequark>
the slowness of the renderer is making it very very hard to use for me, i could probably live with the rest if it was snappy
<whitequark>
but if it's so slow i feel like checking twitter, it's really unproductive
<Lofty>
^^;
<whitequark>
ha, same diode logic trick for the reset
<whitequark>
wait. *different* diode logic trick
<electronic_eel>
you allow me no greenpaks, so i had to resort to diodes ;)
<whitequark>
do we really have two similar but subtly different diode BOM lines? someone's going to get really frustrated after swapping them
<whitequark>
electronic_eel: hey, i grew to like the diode logic stuff. it's appropriate and it seems like it would work well, why not
<electronic_eel>
yes, unfortunately two different double-diodes
<whitequark>
same for your analog mux idea
<whitequark>
i almost wonder if 4 single-diodes would be better
<whitequark>
it's probably not worth doing another revision...
<whitequark>
though wouldn't it make esden happier too?
<electronic_eel>
I think I asked esden sometime about this
<whitequark>
oh yeah, what'd he say?
<electronic_eel>
double diodes have the advantage that you can't place them in the wrong direction
<electronic_eel>
don't remember what he said
<electronic_eel>
but we ended up with the double diodes
<whitequark>
ah, so it's basically screwup prone vs more screwup prone design
<whitequark>
ok
<uovo>
did someone say egg
<whitequark>
by chance are there diode packages in something like SOT23-5?
<electronic_eel>
i wasn't sure if that analogy works in english too
<electronic_eel>
but seems to
<whitequark>
electronic_eel: have you seen my q about diodes?
<whitequark>
we went a bit offtopic after that
<electronic_eel>
oh, yes, sorry
<whitequark>
hm, TSSOP-8 EEPROMs mean you can't use one glasgow to in-circuit program another
<whitequark>
which is totally useless anyway
<whitequark>
on the other hand it means you can't use a SOIC-8 clip to connect a glasgow's IO port to its internal I2C bus, which will hang it once you try to do anything
<whitequark>
it's fun how many of seemingly minor changes have fascinating consequences
<electronic_eel>
you always have the testpoints for accessing the internal i2c
<whitequark>
of course
<whitequark>
you can also just boot FX2 with fx2tool
<whitequark>
hence "totally useless". the only condition there can be that makes a device unbootable via FX2 is if you corrupted the FX2 boot header
<whitequark>
well... header+firmware
<whitequark>
but we have RESCUE for that
<whitequark>
have i mentioned i really like FX2's design yet?
<hell__>
I don't think so but I kind of expected it
<electronic_eel>
re diodes: i just checked mouser, there are some diodes in 6 pin packages we could use for both positions, for example BAT54TW. but they are more exotic than the double ones
<whitequark>
mhm
<electronic_eel>
don't know if it is worth it
<whitequark>
how much more exotic? like, might it actually cause issues?
<whitequark>
this alone is not worth doing revC3 of course, but we might note it for the future
<electronic_eel>
they are essentially just made by diodes inc. and mcc
<whitequark>
and i assume BAT54 compatibles are made by just about everyone
<electronic_eel>
should probably not become an issue, but on the other hand you don't want to risk that for just a diode
<electronic_eel>
bat54 is one of the most common ones, you have tons of vendors for these, western and chinese
<whitequark>
yeah no, let's not do the change i suggested
<whitequark>
oh god i figured out why cadlab diffs are so bad
<whitequark>
every time you change a power rail (except GND) it seems to highlight *everything* connected to it
<whitequark>
wait, i'm wrong
<whitequark>
ohhhh
<whitequark>
it's even worse
<whitequark>
it's because of the way kicad implements sheets
<electronic_eel>
could it be the kicad net numbering?
<whitequark>
half the time it saves io_buffer.sch with the A-side refdes, half the time with B-side refdes
<whitequark>
i don't know what cursed code is responsible for this within kicad, but i recall it being a problem since i started using it
<electronic_eel>
ah, yeah, it depends on which "version" you open
<whitequark>
i hope they fix it in eeschema rewrite?
<electronic_eel>
hopefully
<whitequark>
oh neat, you no longer have to plug USB cable while shorting RECOVER
<electronic_eel>
you just press reset
<whitequark>
yep
<electronic_eel>
i mean release
<whitequark>
press release to release press release
<electronic_eel>
esden will do once revC2 is working
<whitequark>
this will make borderline impossible to desolder the type-C connector
<whitequark>
i guess that's fine
<whitequark>
(well, "borderline impossible" if your SMT rework skill is mediocre, which i think adequately describes most people)
<electronic_eel>
hmm, I'm not sure why esden added this fill
<whitequark>
"to anchor USB-C connector better"
<whitequark>
i'm not entirely sure if it would do that
<electronic_eel>
it is on all layers
<whitequark>
i don't know wtf you have to do to tear out an USB-C connector with PTH anchors
<whitequark>
you'll probably break the board first
<electronic_eel>
i think a small pad on all layers would be enough to give a good physical retention
<whitequark>
that's what was there before..
<whitequark>
commit 25c3a51a
<whitequark>
revC2: Added copper fills to anchor the USB-C connector better. Added copper flood fills on all PCB layers to make a more positive anchor of the shield tab through holes to the PCB layers. Also enabled solder paste aperture openings for the shield pads. Tested on other projects I know that paste in hole works for these connectors.
<whitequark>
i'm not sure how relevant is ease of rework of type-C connector. it is probably the part that will break first, but... reworking it is hard enough i'm not sure if many people will attempt it themselves
<electronic_eel>
the paste thing is good. but i don't know how the anchoring is supposed to work
<whitequark>
i don't see why the anchoring would work either
<whitequark>
and i don't think it is necessary
<whitequark>
PTH USB connectors are already affixed extremely strongly
<electronic_eel>
you probably can snipp off the rest of the broken connector with pliers and unsolder each tht tab on its own, then resolder the new connector
<whitequark>
that is true
<whitequark>
imo we should ditch the flood on future revisions
<electronic_eel>
we should ask esden about the background
<whitequark>
yes, that first
<electronic_eel>
we could add dimension drawings showing the position of the mounting holes. they are currently not referenced there.
<whitequark>
that sounds very nice
<whitequark>
i did very little glasgow-related mechanical design
<whitequark>
the reset button is such a long boi
<whitequark>
oh i see, it has like a bunch of steps
<electronic_eel>
there are several revisions
<electronic_eel>
*variants
<electronic_eel>
esden wrote somewhere in irc which one he was gonna use, don't remember it offhand
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2 [+0/-0/±1] https://git.io/JTw1i
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel 5368ae6 - revC2: add dimension drawings for the mounting holes
<electronic_eel>
whitequark: it is getting a bit late for me here, so i think i head to bed now. if you have some more questions, just post them here and i'll read the scrollback tomorrow
cr1901_modern has joined #glasgow
<cr1901_modern>
whitequark: (Repost) I'm guessing you know this already/are choosing not to go down this route, just _just in case_: It should be possible to programmatically install libusbk drivers using libwdi directly (which Zadig uses internally). >>
<cr1901_modern>
This would avoid the need for a GUI. I don't have any insight on how to do this beyond "it exists" though.
<whitequark>
electronic_eel: nope, i'm done with the review
<whitequark>
cr1901_modern: we don't currently require using a GUI
<whitequark>
instead, libusb.dll is used together with winusb descriptors
<whitequark>
making it unnecessary to generate inf files
<d1b2>
<edbordin> I never got the motivation to follow through and implement it, but a cli version of zadig would definitely be useful for ftdi chips where you can't force it to winusb out of the box
<whitequark>
i'm not sure if libusbK fixes that though
<whitequark>
can you choose a non-default configuration with it at runtime?
<whitequark>
iirc, libusbK uses KMDF?
<cr1901_modern>
I don't know, I haven't tried :P. Does libusbK also have better bulk performance? I remember a while back you were disappointed w/ WinUSB peak perf compared to linux libusb
<whitequark>
the bulk peak perf is largely a consequence of not being able to set a non-default configuration
<whitequark>
libusbK.sys disadvantages when compared to libusb0.sys:
<whitequark>
Does not support multiple configurations.
<whitequark>
ok so libusbK has the same issues as winusb
<whitequark>
for the same reason too, it's KMDF-based indeed