egg|laptop|egg_ has quit [Remote host closed the connection]
<d1b2>
<NorthernDom> Happy New Year. Xx 😘
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
bgianf has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel_ has joined #glasgow
bgianf has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
electronic_eel_ has quit [Ping timeout: 260 seconds]
electronic_eel has joined #glasgow
bsmt has quit [Excess Flood]
bsmt has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 272 seconds]
PyroPeter_ is now known as PyroPeter
egg|laptop|egg has quit [Remote host closed the connection]
nicoo has quit [Remote host closed the connection]
nicoo has joined #glasgow
m4ssi has joined #glasgow
m4ssi has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
_whitelogger has joined #glasgow
<uberushaximus>
happy mailing list reminder day
egg|laptop|egg_ has joined #glasgow
<tmbinc>
a.) is there a supported way to add (non-pad io) signals to the analyzer?
<tmbinc>
b.) trying applet_simulator_test as an alternative, but gtkwave is very unhappy with the VCD timestamps ("VCDLOAD | Time backtracking detected in VCD file!, [0] start time., [-11611056432742400] end time.")
<_whitenotifier>
[glasgow] electroniceel commented on issue #220: Qualification tests for revC2: pre INA233 - https://git.io/JL7wr
<whitequark>
a) not really but you can hack around it
<whitequark>
b) file a bug about it, i will look into it when i am less sick
<sorear>
since none of the revc case files are public i don't want to assume glasgowembedded/glasgow is the correct repository
<d1b2>
<Attie> ah, that's already resolved I believe - @timonsku / @esden en
<d1b2>
<Attie> I think it will be in the repo when it's ready... esden has updated the artwork, and I think we're just waiting on the render from timon now
<d1b2>
<Attie> (ty for spotting & reporting)
<whitequark>
yes, the cases aren't in the repo because several of us (myself included) try to avoid propagation of unfinished work
<whitequark>
a bunch of people were making revC2's from an incomplete branch and at that point i had some doubts in my decision to do the majority of development work in public
<whitequark>
i *think* those devices ended up insignificantly different from the merged state, but that wasn't a given
<FFY00>
you could have a dev branch
<FFY00>
or a stable branch and make that the default
<FFY00>
well, stable-ish
<whitequark>
FFY00: we do.
<whitequark>
the branch with unfinished work was clearly called "wip-revC2"
<FFY00>
and people are building from that?
<whitequark>
yup.
<FFY00>
.-.
<whitequark>
yup.
aquijoule_ has joined #glasgow
<russss>
makes you wonder whether github should have some way of attaching some kind of metadata and/or a big scary message to a branch. That could actually be handy for other things as well.
<whitequark>
now if the boards didn't say "glasgow" or "revC2" i would have no problems with it (it's their choice to build a potentially broken board)
<whitequark>
but so long as they do, i am inherently on the hook for supporting them, because that's how hardware works
<FFY00>
maybe you could remove revC2 them, put prototype or something like that
richbridger has quit [Ping timeout: 260 seconds]
<d1b2>
<Attie> revC2 was on a dev branch... people still built it
<whitequark>
russss: if i *really* wanted to show teeth, i would have trademarked the board's name. except... for a whole variety of reasons that's not really remotely realistic. but that's the usual solution to this problem.
<whitequark>
see: mozilla
<d1b2>
<Attie> (oops, my scroll back stalled)
<whitequark>
FFY00: yes, we'll have to do that going forward
<whitequark>
that or work in secret
<whitequark>
i'd really prefer the former
<russss>
work in another repo with a deceptively boring name
<FFY00>
working in secret has drawbacks, I think calling the board "Glasgow Prototype" is better
<whitequark>
meh
<FFY00>
when you decide to call it something you can copy the folder to `revC3`
<whitequark>
FFY00: remove both the name and revision, even
<russss>
agree with trademarks, I've gradually come to the conclusion that they are useful but they're also a huge pain
<FFY00>
sure
<FFY00>
that makes sense
<whitequark>
trademarks are the only defensible kind of IP
<d1b2>
<daveshah> Yeah, they're great until the registration happens to be with someone hostile
<whitequark>
yup
<whitequark>
and cost far too much to be practical for most OSHW
<whitequark>
so "defensible", yes, "useful"... mostly not
<russss>
yeah they kind of precipitate a whole governance infrastructure which is often overkill
<whitequark>
not for the kind of stuff we're doing here
<whitequark>
imo this should be solved as a cultural problem, not a legal problem, but also like... i started the project to poke interfaces, not fix OSHW culture
<FFY00>
you would also have to spend a bunch of money if you wanted to actually enforce something related to trademark
<FFY00>
so it doesn't make that much sense
<whitequark>
and enforcement is not optional
<whitequark>
see, this is the kind of stuff i originally planned to use the ATECC chip for, except that has enough overhead of all sorts (technical, social, it also kinda costs a lot) that it's not really a solution either
<FFY00>
using a security chip is not really great for people that build their own hardware
<FFY00>
which is kind of the point of oshw
<davidc__>
FFY00: you can use it to prove authenticity. As long as its not a hard-block, it doesn't stop home builders
<davidc__>
FFY00: (IE, it just proves "this is a real RevC2" for warranty and support purposes)
<whitequark>
yes. they could submit the unforgeable serial with some sort of [✔] this is built from actually supported gerbers
<whitequark>
and then if someone files a weird hardware issue, we can ask for that serial, and then we know who to blame, so to say
<FFY00>
yeah, but that means if I build a proper revC2 I won't get support
<FFY00>
hum, that makes sense
<agg>
would you need to interactively check the serial, to prevent them just submitting someone else's?
<whitequark>
yes, it would be a challenge-response thing
<davidc__>
FFY00: I don't think it means you "don't get support", it ust means that one takes a different path for support questions
<whitequark>
this is a massive amount of technical infrastructure that would be very hard to deploy e.g. behind GFW
<whitequark>
and it has significant social overhead as well
<agg>
also wouldn't actually stop people asking for support
<agg>
just might make it a bit quicker to tell them to get lost I guess
<whitequark>
yes, the benefits do not justify the cost
<whitequark>
not even remotely
<whitequark>
it was a stupid idea
<FFY00>
have you considered simply connecting one pin to vcc in prototypes
<whitequark>
we don't have like... spare pins
<whitequark>
i guess it could be a LED soft strap but that's still fairly significant overhead
<whitequark>
*LED hard strap
<whitequark>
the way they do it on ethernet phys
<whitequark>
silk is almost certainly the place to solve this problem, esden agrees since he opted for silk instead of atecc to prevent warranty fraud
<whitequark>
well, solve it technically, the ultimate solution is social
<sorear>
if the version space weren't so small I'd suggest doing an even/odd thing
<whitequark>
we are actually kinda doing the even/odd thing
<whitequark>
C0 is broken, C1 is fine, C2 has one bug, C3 will fix that bug
<electronic_eel>
nobody has complained yet about something caused by them building incomplete revs yet. even when we still not have the firmware for making revC2 fully work merged into master yet. so i'm not sure if it is an actual problem or will become one in the future
<sorear>
like, the "working copy" always has an even version, when you decide C3 is ready you copy C2 to C3, rename it while copying, and immediately bump the working copy to C4
<whitequark>
electronic_eel: knowing that it is a potential problem is a source of stress for me
<whitequark>
as you probably know, i try to fix problems before people complain, not after
<FFY00>
could we add a --manufacturer-id argument to `glasgow factory`?
<FFY00>
people that build their own glasgows would not have a manufacturer
<electronic_eel>
whitequark: i know. but i don't know if a move like going closed dev isn't a bit extreme.
<electronic_eel>
when people are skilled enough to build their own glasgow boards, they are most time intelligent enough to know that a wip-marked branch can have problems and know how to fix them themselves
<sorear>
I'm just twitchy about the loss of metadata when "revC2" could mean any version from an N month span of time
<FFY00>
I think the problem is identifying that in bug reports
<whitequark>
electronic_eel: like i mentioned, i think it would be enough to remove project name and version from silk
<whitequark>
they can add it back with a sharpie
<whitequark>
*that* is an excellent indicator of "wip"
<sorear>
printing a git hash on the silk is not realistic, but if we distinguished production versions from working versions (using odd/even or otherwise) we could have all production units unambiguously marked
<sorear>
i like the sharpie idea
<FFY00>
sorear, you could have git hash in the firmware
<whitequark>
sorear: git hash could be done i think, with ident gitattribute
<whitequark>
normally it won't work, but kicad ~always touches ~every file when saving
<sorear>
it's not just the printing that's an issue, now you have to read it
<whitequark>
ah, yes.
<whitequark>
FFY00: i don't think any of those will work. if it's skippable, people will just skip it, or carelessly provide incorrect info
<FFY00>
that is the point
<FFY00>
people will skip it
<FFY00>
it won't have any id
<FFY00>
manufacturers will explicitly set their id
<whitequark>
i guess. it would be kinda annoying to add as the configuration block is what, 64 bytes?
<whitequark>
but probably doable if someone puts their mind to it
<whitequark>
except there's lots of other firmware issues that would be much more useful to fix...
<electronic_eel>
so when i branch revC3 next week or so, the first thing is remove "Glasgow" and "revC2" from the top silk?
<whitequark>
we can make it "revC?"
<electronic_eel>
then when we declare revC3 finished, we add it back? that seems an easy thing
<whitequark>
and replace "Glasgow" with "Tynftbj"
<electronic_eel>
if it is too obviously wrong, people might just change it back
<whitequark>
hm.
<FFY00>
you can call it "NOT Glasgow"
<FFY00>
idk
<whitequark>
electronic_eel: ok yeah just replace it with something indicating that it's work in progress
<whitequark>
"WIPWIPW"
* whitequark
shrugs
<whitequark>
if it's too obviously missing people *also* might just change it back
<whitequark>
hence my suggestion of replacing it
<electronic_eel>
replacing it also keeps the text object, so it is easier to get it back to the proper position when we are finished
<whitequark>
yes, that's why I suggested rot13 at first
<whitequark>
same width
<d1b2>
<Attie> in my designs I tend to put a + at the end, until final, at which point it gets updated... e.g: revC2 -> revC2+ -> revC3
<whitequark>
it's a bit hard to notice
<whitequark>
if you don't know where to look
<d1b2>
<Attie> I think the revision sold take the change, but sure about the name
<d1b2>
<Attie> yeah, granted, it's a bit subtle
<mwk>
people tend to chop off random amount of suffix when mentioning part names
<mwk>
odd/even would work better
<whitequark>
good lesson for the next project: do not do revisions in... any of the ways i did them here
<whitequark>
ok i guess at least the number is monotonically incrementing.
<d1b2>
<Attie> heh.. it's always a hard one, especially when trying to set things out at the beginning
<whitequark>
i thought the FXMA-based board will be the only one!
<electronic_eel>
yes, it is a bit hard to envision how the project will progress and what the challenges will be
<electronic_eel>
so getting a rev scheme set out upfront isn't that easy
<d1b2>
<Attie> I quite like odd/even, and it fits / can be used going forward
<whitequark>
electronic_eel: arguably, if i used semver, the version would be less cute but more practical
<whitequark>
i don't remember whether i considered that or not. i might have
<whitequark>
i definitely picked the current rev\w\d scheme mostly because i liked it aesthetically
<whitequark>
... still do
<electronic_eel>
if we go to odd/even - revC3 will be a "dev" version until we are finished and then change it to revC4?
<sorear>
ignoring the silk issue for a moment, every glasgow prototype needs to have some information in the configuration that tells the firmware how to talk to the board
<electronic_eel>
or do we continue to call it revC2 till it is finished and then go to revC3?
<d1b2>
<Attie> I'd say, yes... revC4 on Gerber generation and merge into master
<sorear>
so "just leave it all blank" doesn't completely solve the problem
<electronic_eel>
sorear: if you have a prototype, the developer should know how to make the firmware behave that it works with their exact prototype
<whitequark>
sorear: nope. the work-in-progress boards do not need firmware because they aren't supposed to be manufactured
<d1b2>
<Attie> "odd" = "not quite right" ... sigh
<electronic_eel>
if you work with a protoype, you may also add bodge wires or something, the firmware must match that. so some git hash won't work
<whitequark>
yes
<whitequark>
if you do manufacture a prototype it is expected to be used for qualification/testing and then never again
<whitequark>
so you just program it with whatever is convenient
<electronic_eel>
also the firmware would get quite convoluted if we added all kinds of ifs for each prototype ever in existance
<whitequark>
this is like the whole point of the change, i would want to avoid ^ exactly this
<whitequark>
arguably, we should have made a bunch of what is currently revC2s as "revC?"s, found the bug, fixed it, and only then called it revC2 proper
<FFY00>
if you build a prototype board you would use the firmware on the repo that goes with that particular prototype board
<whitequark>
as usual life got in the way and that's basically fine, more of something to note for future work
<whitequark>
FFY00: that's effectively impossible though
<FFY00>
why?
<whitequark>
the firmware/software protocol is unstable, so you can't just patch firmware, flash it, then a year later run new software against it
<FFY00>
right
<whitequark>
you'd have to rebase your patch first and then replace the ihex file committed to the branch
<whitequark>
which is yes, technically doable, but it severely hampers usability and utility of such prototypes
<whitequark>
which is fine
<FFY00>
I guess the tldr there is don't build prototypes
<whitequark>
yes
<FFY00>
ultimately it's the people's decision
<electronic_eel>
put you head in the sand and wait for someone else finishes the work ;)
<whitequark>
because of the way glasgow's stack is structured, and because of the project's commitment to supporting old hardware, if we support prototypes once, we support them forever
<whitequark>
so "don't build prototypes" is exactly the message i want to sned
<Shiz>
sizeof("Glasgow") == sizeof("WIP ver") :p
<Shiz>
(well, maybe not depending on your font...)
<whitequark>
other projects don't do this and that's fine! this is exactly why i actively promote efforts like tnt's icePick even though it is kind of a glasgow like thing
<whitequark>
(by the way, what's up with icePick? haven't heard anything about it for a long time)
egg|laptop|egg_ has joined #glasgow
<tnt>
whitequark: I mentionned before, don't think it's commercially viable, so it's basically dead.
<whitequark>
oh...
<whitequark>
is it less viable than Tigard?
<whitequark>
I'm a bit surprised that's your conclusion
<tnt>
I wanted to only make one version, with all accessories (milled cased, leads, etc ...). And with the cost of dealing with CE, WEEE, plus having a margin enough to put the required work in it to maintain and support the software stack, I'd be looking at a retail cost of ~ 80-90 eur in that range. With glasgow just 50$ more, no-one in their right mind would buy that.
<sorear>
I guess I don't really understand how loose the hardware-software feedback loop can be
<whitequark>
tnt: I see
<whitequark>
sorear: for a while i tried the thing where new USB requests are added and existing ones preserve compatibility
<whitequark>
until it screwed over someone in this channel, where a subtle difference not accounted for by an added USB request broke functionality in a way that would have been very hard to debug if i didn't already know the symptoms
<electronic_eel>
tnt: glasgow doen't have CE or WEEE. part of it is esden being in the US, part of it is that he takes the risk for getting caught (when he sells from his German shop)
<tnt>
What's the revC2 bug btw, I've been looking at github issues and it couldn't immediately find it.
<whitequark>
sorear: that's when i switched to a hard API level match instead
<tnt>
electronic_eel: yeah ... unfortunately I have people locally that are looking for new and exciting way to screw me over, so I'm not trying that ..
<electronic_eel>
tnt: the pmbus alert address (necessary for the ina233) clashes with one of the dacs
<electronic_eel>
i'll create a "revC3 todo" issue soon
<sorear>
I mean if you have to declare versions official and permanently supported *before* doing any software support, that seems like it could lead to regret
<sorear>
idk
<sorear>
if the board doesn't work but doesn't work in a way that isn't clear until you've tried
<electronic_eel>
sorear: i think that is the whole point of the versioning discussion. what is the best way to communicate that some version is not supported and later when issues arise, quickly identify them
m4ssi has joined #glasgow
egg|laptop|egg_ has quit [Remote host closed the connection]
GNUmoon has quit [Remote host closed the connection]
<_whitenotifier>
[glasgow] electroniceel commented on issue #221: Qualification tests for revC2: post INA233 - https://git.io/JL7NO
<kmc>
is there a particular use case for the unpopulated through-hole pull-up/down resistor footprints?
<kmc>
is it just in case someone wanted a different drive strength than 10 kOhm?
egg|laptop|egg_ has joined #glasgow
<_whitenotifier>
[glasgow] electroniceel opened issue #255: Schematics & Layout TODO for revC3 - https://git.io/JL7A2
<electronic_eel>
kmc: yes, this is to allow stronger pull levels. for example when using it for i2c
<electronic_eel>
also you could desolder the resistor pack from the pcb and just use your own resistors. that would allow to use higher resistances than 10 k too
egg|laptop|egg__ has joined #glasgow
egg|laptop|egg has quit [Ping timeout: 246 seconds]
egg|laptop|egg_ has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
<_whitenotifier>
[glasgow] electroniceel opened issue #256: Decide on port pinout marking on the top silkscreen - https://git.io/JL5fK
<_whitenotifier>
[glasgow] electroniceel commented on issue #256: Decide on port pinout marking on the top silkscreen - https://git.io/JL5fi
egg|laptop|egg has joined #glasgow
egg|laptop|egg has quit [Remote host closed the connection]
egg|laptop|egg has joined #glasgow
m4ssi has quit [Read error: Connection reset by peer]
tomtastic has quit [Ping timeout: 264 seconds]
tomtastic has joined #glasgow
GNUmoon has joined #glasgow
<_whitenotifier>
[glasgow] esden commented on issue #256: Decide on port pinout marking on the top silkscreen - https://git.io/JL5Tw
<_whitenotifier>
[glasgow] whitequark commented on issue #256: Decide on port pinout marking on the top silkscreen - https://git.io/JL5IT
<_whitenotifier>
[glasgow] electroniceel commented on issue #256: Decide on port pinout marking on the top silkscreen - https://git.io/JL5IO
<_whitenotifier>
[glasgow] electroniceel closed issue #256: Decide on port pinout marking on the top silkscreen - https://git.io/JL5fK
egg|laptop|egg has quit [Remote host closed the connection]
<_whitenotifier>
[glasgow] electroniceel commented on issue #221: Qualification tests for revC2: post INA233 - https://git.io/JL5IR
egg|laptop|egg has joined #glasgow
<d1b2>
<mnapolitano> :hello: I saw the conversation above about revC? above and wanted to just comment from the perspective of someone who was going to build a glasgow starting ~3 mo ago to now, and didn't read the discord/irc until about now. I saw that the revC2 branch was WIP and it was also probably the production branch for the upcoming crowd sourcing run. I well understood that WIP-revC2 was probably broken / use as own risk, so in that regard it worked very well
<d1b2>
on convincing me to build off of master/revC1. I also think that anyone who is willing enough to go that deep off of master is well into at own risk / minimal support territory, and anyone who is selling it as a final version C* is being deceptive and really shitty. I thought having a silkscreen of the git-hash is super elegant but also hard to do, and a either the WIPWIPWIPWIP or git branch silkscreen (or DEVELOP, whatever) is just further getting the
<d1b2>
point across, but if someone is already being a bad actor re: C? versions that might not stop them. One thing I did want to mention though is that once I saw revC2 gerbers were pushed to master, I assumed they were "official" versions, so I did order boards based off of that. I think that's safe (and if C2 ends up being defective because of the issues above that's sorta how things go with life), but my expectation (in the sense of what I would think the
<d1b2>
versioning works, not what I would feel entitled to) would be that they would be the same as any other C2 board because of the whole master branch thing, and a fix would be a revC2a or C2+ etc. Just outside perspective thoughts, please don't take this to be anything other then that. Thank you all for your hard work and making a great tool!
<whitequark>
none of the people i saw building from wip-revC2 are bad actors by any stretch of imagination
<whitequark>
some of them are my friends! it's just that the complexities of glasgow support are not really obvious even to people familiar with OSHW
<whitequark>
i am expressly disregarding malicious behavior here, since, now that we've ditched the ATECC idea, there is nothing we can really do about that. evil people gonna evil
<whitequark>
as for C2, there are some minor bugs but they have a workaround & that workaround is likely going to stay in the firmware forever
<whitequark>
(at one point i thought about asking all revC2 owners to do minor rework, but now i think i won't do it)
<d1b2>
<mnapolitano> right, I didn't mean to imply that. I just meant that to me the branch title alone is a big warning sign that here be dragons, and if you want to be safe master is the best/only place. Maybe that's just me knowing too much about git software conventions though. I also think that any of the solutions above would probably work well, and help make it really really clear reducing the likelihood of issues.
egg|laptop|egg_ has joined #glasgow
<d1b2>
<TiltMeSenpai> I think the situation is actually kind of the opposite. revC2 isn't the final production run, but it is a relatively fixed point in time, so while it has issues, it has known issues. When you're talking about a master/mainline/dev branch or whatever, that's where new active commits are generally going, so if someone builds a Glasgow from "master" and has a problem, there's the fun task of tracking down which "master" it was built from. That
<d1b2>
being said, I would imagine that whatever revisions the major production runs (e.g. CrowdSupply) are cut from would be the most supported hardware revisions.
egg|laptop|egg has quit [Ping timeout: 256 seconds]
egg|laptop|egg__ has quit [Ping timeout: 264 seconds]