TiltMeSenpai_ has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
TiltMeSenpai has joined #glasgow
ali_as has quit [Quit: Bye!]
tomtastic has joined #glasgow
<whitequark>
yeah, we really need to bump python version
_whitelogger has joined #glasgow
bvernoux has quit [Ping timeout: 250 seconds]
gregdavill has quit [Remote host closed the connection]
gregdavill has joined #glasgow
_whitelogger has joined #glasgow
_whitelogger has joined #glasgow
bvernoux1 has quit [Quit: Leaving]
_whitelogger has joined #glasgow
analprolapse has quit [Ping timeout: 256 seconds]
_florent_ has quit [Ping timeout: 256 seconds]
yuriks has quit [Ping timeout: 256 seconds]
daveshah has quit [Ping timeout: 272 seconds]
_florent_ has joined #glasgow
daveshah has joined #glasgow
yuriks has joined #glasgow
analprolapse has joined #glasgow
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #glasgow
futarisIRCcloud has joined #glasgow
<samlittlewood>
is there a polite way for an applet to power cycle the DUT? I am trying to read/write a device that requires entering prog mode within a time limit after powerup (few ms)
<samlittlewood>
currently, I am just stashing the port_spec, and using lower.device.set_voltage()
ali_as has joined #glasgow
<electronic_eel>
samlittlewood: afaik there is no separate enable/disable for the Viobufs of the ports. You just set the voltage to 0 to disable and any other voltage to enable.
<electronic_eel>
so I don't think you have to be more "polite" to power cycle
gregdavill has quit [Ping timeout: 246 seconds]
_whitelogger has quit [Remote host closed the connection]
_whitelogger_ has joined #glasgow
niklas has joined #glasgow
<niklas>
hey!
<niklas>
I would like to do a glasgow revC1 spinoff that is more suitable for JLCSMT assembly
JanHenrik has joined #glasgow
<niklas>
may I asked what the ATECC508A is currently used for?
<tnt>
nothing
<niklas>
so I may just not assemble it?
<tnt>
yup.
<tnt>
the idea was originally to provide a crypto check for board manufacturer (so they can check if it's a board they manufactured or not) for returns/support/counterfeit checks ... but it was deemed more trouble than it's worth.
<electronic_eel>
not just the manufacturer, but more for buyes who want to find out who the real manufacturer of their glasgow was, like esden or some chinese clone company
<electronic_eel>
*buyers
<tnt>
yeah, that's what I meant by counterfeit check but I admit my sentence structure was not optimal.
<niklas>
okay but for what purpose?
<electronic_eel>
there are now clones of the icebreaker out on aliexpress that have the same logo and everything like the original
<niklas>
wouldn't be the best thing to happen for this project to being able to buy a glasgow off aliexpress for 20 bucks?
<tnt>
niklas: if you have an issue with the board you need to know who to contact for support.
<electronic_eel>
and a complex and dense board like glasgow could have manufacturing defects when not properly tested
<tnt>
one manufacturer isn't going to provide replacement for a board he didn't make for instance.
<tnt>
the goal was not to _prevent_ anyone for making it, like it would have worked even without the chip even mounted, this was just a traceability thing.
<electronic_eel>
niklas: does JLCSMT now do BGA?
<niklas>
no, but that can be easily added afterwards
<electronic_eel>
how do you want to get a stencil in if the board is already populated?
<niklas>
having the glasgow fully assembled except for the cypress and fpga would already be great progress
<niklas>
you can easily do BGA on ENIG without addition of solder paste
<niklas>
and the QFN can simply be tinned with a soldering iron
<niklas>
a pre-assembled JLCSMT glasgow would reduce assembly time from 45min to ~5min
<tnt>
Damn you guys are fast ... it would take me way more than 45min :p
<electronic_eel>
are the rest of the parts available at JLCSMT? IIRC they have a limited set of parts you can use
<niklas>
yup, I would have to completely redesign it
<niklas>
also make it cheaper
<niklas>
but I'm quite good at that :D
<niklas>
currently looking for a replacement of PCA6408
<tnt>
(not having the manufacturer replacing random part with "equivalent" is actually why manufacturer traceability is useful here ... each part has been specifically tested and some supposed equivalent sometime don't behave)
<niklas>
well it's not random if I do a github fork^^
<niklas>
like come on, this isn't like a proper product
<electronic_eel>
when you look for replacement parts, look out for i2c address clashes
<niklas>
yup, I also really don't want to "replace" parts but rather find compatible variants
<niklas>
like the TCA6408, I may just assume for now that it is a drop-in replacement for the PCA6408
<tnt>
samlittlewood: btw, if you shutdown VIO that resets the PCA6408 which controls the pull ups/downs.
<electronic_eel>
I think these are compatible, but IIRC there sometimes are subtle differences between PCA and TCA parts
<electronic_eel>
niklas: did you post a short video of your glasgow on twitter?
<niklas>
yes
<electronic_eel>
the phosphor of the user leds looked different - which colors have you used?
<electronic_eel>
niklas: do you see a chance to keep the same distance of the port headers on your pcb than on the original?
<niklas>
sure
<niklas>
in fact, I'm almost done and didn't change most footprints
<electronic_eel>
ah, ok
<electronic_eel>
several people reported problems with the level shifter footprints
<niklas>
yeah
<niklas>
they're SOT23 now
<electronic_eel>
esden did work on improved ones, but I think they aren't pushed yet
<niklas>
but yeah we also head trouble with those, required tons of flux
<electronic_eel>
how did you fit sot-23-6 in there while keeping the port spacing?
<niklas>
well there is tons of space
<niklas>
it will even fit the decoupling on the top
<niklas>
I want it single sided assembly only
<electronic_eel>
I found Glasgow to be rather densely populated - or did you go to 6 layers?
<niklas>
no
<niklas>
but it's not at all densely populated :D
<niklas>
like, look at it. There is tons of empty surface
<niklas>
even now I wouldn't consider it densely populated :D
ExeciN has quit [Quit: so long king Bowser]
niklas has quit [Ping timeout: 240 seconds]
JanHenrik has quit [Ping timeout: 240 seconds]
<gruetzkopf>
iirc TCA vs PCA was a decisision made after annoying bugs with the former
<whitequark>
I think it was a different TCA
<whitequark>
but it needs to be checked carefully
21WAAB2YW has joined #glasgow
32NAAFPWN has joined #glasgow
<21WAAB2YW>
whitequark: I'm available now
21WAAB2YW has quit [Client Quit]
niklas has joined #glasgow
<niklas>
ah, I dont know howto irc
<niklas>
so first of all, sorry for the unproductive twitter conco. I was on my phone + I interpreted your initial messages as if you would't want contribution at all, which disencouraged me about the work I just did
JanHenrik has joined #glasgow
<niklas>
so let me recap, your point: You would totally like to see people adopting glasgow hw to be better / cheaper / easier, but you're worried about changes that might create problems with support since they behave different to the current "verified" hardware and you don't want to patch existong code because of that, or even worse, have this unwanted legacy for future development
<whitequark>
niklas: yes, exactly
<whitequark>
I would be very happy to see the changes to make revC1 cheaper upstream, but as long as they're coordinated to avoid such issues, it is entirely your own choice whether you'll put in effort to do so
<whitequark>
provided your boards are functionally equivalent I'm also perfectly fine with you calling them "Glasgow", supporting them upstream, promoting them and so on
<niklas>
my point: I love glasgow, but it was a pain to order and assembly, plus very expensive for what it is. I'm worried about breaking it because of this. I want more glasgows for myself and friends (eg. the colorlight HUB75 bubble) but for a price of max $50, which isn't possible with digikey & hand assembly. The way to fix this would have been a total of 3h work, of which I already spent 2.5h and made all changes
<niklas>
neccessary to assemble glasgow at jlcsmt, expect for only the fpga, cypress, adc and dac. Since I would like to spent as little time as possible with this (and more with actually using it) I didn't change anything I'm not 100% sure it will just work, and also changed no I2C addresses etc. so it's 100% software compatible.
<whitequark>
$50 was my original price target
<whitequark>
revA was maybe close to that, but it didn't really work
<whitequark>
revC works well but we did not focus quite as much on the cost
<niklas>
The thing is, I would totally love to contribute to upstream, but it takes time. And just as you, I really don't want to spent time I don't want to spent. For example, I totally like spending time on finding suitable replacement parts. But on the other hand, my pcb now has USB type C, and I would really like to keep it that way. I do not like to discuss with people on the internet, why type C is the superior
<niklas>
connector or not...
<whitequark>
regarding changes: any change you make that keeps the same value and type of component (for passives) or same die (for semiconductors) are fine. USB type C is also fine, in fact I was originally planning to go for type-C but it was changed to type-B for various reasons.
<whitequark>
I am only really worried about mechanical changes that may affect addon boards, and changes to semiconductos that may result in a not exact functional replacement being used
<niklas>
I hope you get my point. Tbh all this fuzz was already beyond what I wanted, and if I knew beforehand I would have to justify me like that I wouldn't have touched this project in the first place...
<whitequark>
if I have to support other people doing whatever changes they want to the boards and distributing them under the same name I would rather just abandon the project entirely and never work on OSHW again
<niklas>
For now, I will order 20 pcs assembled pcbs with something like "Glasgow-inspired Debugger" on it since I can't guarranty that it will work, nor that someone might get hands on it that want to contribute to upstream using it. I will release everythin and might even do a pull request, and if you're happy with it, feel free to adopt as many changes as you want to upstream
<whitequark>
thank you, that sounds great.
<niklas>
Ideally, at some point there would be a gerber_revC2_jlcsmt.zip in your upstream repo, but that is up to you
<niklas>
My personal thought on that: I think noone expects you to support random hardware, and we are all more than happy for what you created already. I can see why you are afraid of this, but I think there is something very different between Xscreensaver and a sophisticated fpga-based embedded debugger. People who managed to order and assemble pcbs for glasgow, know how OSHW works and probably this discurse is by far the "
<niklas>
worst" you will ever get into regarding glasgow
<niklas>
Even worse so, the risk of a reported issue because of badly soldered DFN logic gates it much higher than bad timing because of a properly soldered, machine assembled SOT23-6 gate that can't keep up timing at 80°C
<whitequark>
I think replacing DFN with SOT23-6 is something we really should have upstream
<whitequark>
back when we decided on DFN I was under impression SOT23-6 won't fit there
<whitequark>
niklas: (also, please see PM)
<niklas>
There is also SC-70
<electronic_eel>
yes, sc-70 is still nice to assemble, but not that big
<niklas>
but I like SOT23-6 more since the space is there, pluse it makes placing vias underneath more easy
<whitequark>
Glasgow should be as accessible as it can be, as long as its reliability in face of misuse isn't compromised
<niklas>
it's still DFN, but bigger spacing
<whitequark>
oooh nice
<whitequark>
I think esden will be happy to see any DFM improvemnets either
<niklas>
otoh, glasgow is huge and most space unused. I could probably also just stick three USBLC6-4SC6 (SOT23-6) in there
<whitequark>
[misuse] since being misuse resistant is a part of being accessible, too
<electronic_eel>
isn't the SP3012-06UTG just 6 pins, so you need 2 of them?
<niklas>
yes
<esden>
I was considering changing the design to use SOT23 level shifters... or at least move to DFN versions of the packages... DFN is easier and more reliable to solder than the packages we currently use...
<niklas>
but using more parts is still better than using few, more exotic parts imho
<niklas>
and wtf, I've never seen a 12 channel ESD diode before :D
<esden>
this part is for HDMI i think
<niklas>
other changes I made:
<niklas>
I swapped all resistor arrays for two 4x arrays
<niklas>
since those are available at JLC and much cheaper than one 8x array
<esden>
yeah it turns out the 8x arrays are expensive and hard to get :/
<esden>
I did not realize that until I tried to source them
<esden>
niklas: if you have your design somewhere I would love to take a peek at least. :)
<niklas>
I changed the TPS73101 for the RT9043GB. Footprint compatible, cheaper and JLC available, also same ref. voltage. I haven't checked anything else, but I'm sure it will just work
<niklas>
esden: I will finish and order it this evening (so in ~6h)
<esden>
unfortunately even despite corona my tax appointment is still happening so I am knee deep in that ... >_<
<esden>
I will only be able to look at it after I am done with that
<electronic_eel>
niklas: the RT9043GB is 400mA, the TPS73101 is 150mA. that means overcurrent protection will kick in muuuch later
<electronic_eel>
that could mean the capacitor can't keep the voltage up and glasgow crashes on a short
<whitequark>
yes, that seems like a potentially major issue
<electronic_eel>
we had this with the TPS73101 too, that was why we added the big cap
<whitequark>
you might not be able to fit the capacitor big enough for RT9034GB on the board
<whitequark>
(and still have it fit in cases)
<whitequark>
electronic_eel: we should call out this on the schematic
<electronic_eel>
you mean next to the cap or next to the ldo?
<whitequark>
both
<niklas>
but relying on the max. output current of a LDO isn't really a short protection
<niklas>
I would have replaced the big cap for a tantal, easyer to reflow and also JLC available
<electronic_eel>
no, the TPS73101 has a foldback limiting
<electronic_eel>
tantals usually aren't that sturdy regarding voltage spikes
<niklas>
ah I see
<whitequark>
does RT9043 protect from backfeeding the board from Vout?
<electronic_eel>
the polymer ones are much better in that regard
<niklas>
Let me check if I can find something else, 1.2V unfortuantly is a quite uncommon ref voltage. But I could also compensate for that by altering the feedback network
<whitequark>
I don't see it in the datasheet and I'm not entirely sure from the topology
<electronic_eel>
I orderd buckets of polymer ones at lcsc, they should have some of them at jlcsmt
<niklas>
electronic_eel: unfortuantly not
<bvernoux>
electronic_eel, a good advise use only Ceramic capacitor the bigger the better for noise suppression ;)
<electronic_eel>
the bigger the better for noise suppression maybe, but the bigger the more likely to crack
<bvernoux>
not ceramic capacitor
<electronic_eel>
I have some in 1210 here and the manufacturer specifies not to use hand soldering at all with them
<whitequark>
I agree that not having exposed metal on the back is valuable
<bvernoux>
today dual side components is as cheap as only one side
<bvernoux>
except if you want to build 5 units or use JLCPB which does not allow it
<niklas>
electronic_eel: oh nice! didn't know that
<whitequark>
regaring NCP600, you can easily verify whether the change will work well by testing the board under crowbar conditions
<whitequark>
which is how marcan tested it in first place
<bvernoux>
JLCPCB
<electronic_eel>
yes, crowbar with different voltage levels
<whitequark>
with decoupling there are two distinct issues
<electronic_eel>
niklas: how do you do no exposed copper on the back with the pin headers?
<whitequark>
first is the PLL power quality, which is likely a more pressing one
<whitequark>
second is voltage sag under pathological switching patterns on the IO drivers
<whitequark>
we don't have an easy way to test either of those
<whitequark>
so I'm not very comfortable with this change
<niklas>
okay, at least the caps for the buffers can easily fit on top, even with sot23
<whitequark>
yes, for the buffers we can absolutely move them to the top
<electronic_eel>
wouldn't you see problems with the pll power quality as increased jitter on a spectrum analyzer?
<whitequark>
there was no reason for them to go on the back besides us having all the decoupling on the back
<niklas>
for the fpga and cypress, I acn add footprints on the top, and we will see if it is sufficient or not
<whitequark>
electronic_eel: sure, but I don't have one (my rigol has an fft function but i don't think it's actually usable)
<whitequark>
of course if someone with relevant experience volunteers to verify that change, we can do it
<electronic_eel>
maybe niklas has access to a spectrum analyzer, or he could send me his board and I test it with mine
<whitequark>
yes, that works
<electronic_eel>
I don't have a fancy jitter analyzer, but glasgow is not designed to be a precision rf instrument
<whitequark>
I'm mostly worried because right now only one applet uses the PLL (VGA) so if it silently breaks we'll not know any time soon
<niklas>
I have a proper HF setup and can even do testing for DIN EN 55032 compliance
<whitequark>
excellent
<awygle>
i have a specan
<whitequark>
if decoupling on top has the same performance then I'm fine with it
<whitequark>
we should also design a test pattern generator to verify IO bank decoupling
<niklas>
electronic_eel: yeah that exactly my point. Imho it will just work. Maybe not 100% as great as before, but it's just a (rather slow) fpga. It will not just don't work
<niklas>
For HF, analog, etc, sure
<niklas>
but that's an ICE40, max clock, like what, 50MHz?
<tnt>
the good news is that the IO are really only driving very small loads so shouldn't be too muhc of an issue.
<whitequark>
probably something like switching IO and OE at twice our maximum advertised frequency
<electronic_eel>
aren't the ios of the ice40 specced to max 150 MHz?
<whitequark>
it depends on the IO standar
<whitequark>
LVCMOS33 is 250 MHz
<whitequark>
we can't support anything beyond 100 MHz as it makes no sense with the fabric it has
<whitequark>
(even 100 is a stretch)
<daveshah>
250Mbps not MHz isn't it?
<whitequark>
so if it doesn't sag too much when toggling at 200 MHz it should be definitely fine for any boards and applets no matter how borderline
<whitequark>
daveshah: the datasheet says MHz
<whitequark>
is it wrong?
<tnt>
daveshah: it's the HX
<daveshah>
Ahh, or maybe I'm just misremembering
<tnt>
Actually no the UP5k is also 250 MHz.
<daveshah>
Weirdly ECP5 is only 150MHz
<whitequark>
smaller IO buffers because it has more pins?
<tnt>
I find it weird that the lower voltage go slower ... isn't it usually the other way ?
<daveshah>
whitequark: but the max drive strength is higher (16MHz)
<whitequark>
tnt: all the drivers in the FPGA are the same, right? other than differential ones
<niklas>
okay but even the SN74LVC1T45DRL won't hold up to >100MHz
<daveshah>
It's possibly just that the specs that define it are tighter
<daveshah>
Or they are just more conservative
<whitequark>
tnt: usually when lower voltage goes faster it's because the max voltage is lower
<niklas>
from my experince 70Mhz is the maximum you can reliably get out of LVC
<tnt>
whitequark: AFAIK yeah they're all the same when operated in lvcmos mode.
<niklas>
ah yes it even says 75MHz max for 1.8V translation
<whitequark>
1.8V is the slowest, wasn't it?
<whitequark>
hang on
<whitequark>
it does 75 Mbps for 1.8 V translation, that's 35 MHz DDR, isn't it?
<daveshah>
Yeah I'd say so
<tnt>
yup
<whitequark>
the number it advertises for 3.3 V is 210 Mbps, which is why I say Glasgow is designed for at most 100 MHz IO pin bandwidth
<tnt>
daveshah: btw, I'm a bit dubious about that 250 MHz spec, because already at 140 MHz the output signal is not all that square.
<whitequark>
best case conditions
<daveshah>
Yeah, I wonder if they really meant 250Mbps
<whitequark>
even if Lattice actually means 250 Mbps that still means it meets the 100 MHz number I'm claiming
<tnt>
daveshah: yeah, that might be what they mean by "toggling pattern". i.e. it switches 250 millions times per second.
<daveshah>
Mmm
<tnt>
(which is a 125 MHz square clock)
<whitequark>
niklas: regarding speed of level shifters, you are completely right
<whitequark>
niklas: the reason I suggest testing it at 200 MHz is to account for variation in parts and environment
<daveshah>
The ECP5 definitions are definitely real MHz ie Mbps/2
<daveshah>
But SiliconBlue may have used a different definition and Lattice copied it without realising
<whitequark>
if we know it won't sag with the 2x margin at room temp, we can be reasonably sure it will work when it's extra cold, with marginal silicon, and so on
<whitequark>
it's not a hard requirement I have but more of a guideline to help convince myself these changes are OK
<whitequark>
maybe we discover that doesn't work, or maybe even our current revC1's can't do that. then we'll have to review them.
<niklas>
haha, reading all of this I wonder if I'm really good or really bad at my daily job :D
<whitequark>
I'm only an amateur electronics designer at best, which is why I try to put in so much effort to make sure these boards are reliable
<niklas>
You worry about environmental conditions FOR A DEBUGGING TOOL, while I design EV charging stations and think about this /occasionally/
<awygle>
wq is cursed with an overabundance of professionalism
<electronic_eel>
aren't these ev chargers out on the street and should also work in winter?
<niklas>
4-layer pcb
<awygle>
which is why all wq software is so usable
<niklas>
1.2GHz ARM core booting linux
<niklas>
not a single cap on the back :D
<electronic_eel>
or is the climate change already planned in?
<whitequark>
niklas: but those packages have caps inside them, right?
<whitequark>
so the vendor sort of taken care of this to a degree
<whitequark>
I guess not in the SoC
<niklas>
yes, but not for the eMMC I think
<whitequark>
er, not for the eMMC
<whitequark>
SoC would have more variable power demands though
<niklas>
still, I believe you should have some decoupling, but if it's 1mm or 5mm apart doesn't matter as much
<niklas>
but we'll see, I'd like to test
<whitequark>
I share your view that it's probably fine
<whitequark>
but I don't like to rely on "probably" for something I intend to support forever
<whitequark>
or at least as long as USB 2 is still supported
<whitequark>
revC1 is so expensive in part because we followed all manufacturer recommendations to the letter
<whitequark>
(and when they were not explicit we went with the conservative choice)
<whitequark>
as you can see revAB boards are still supported for people who have them, even though they barely work
<whitequark>
of course following vendor specs to the letter is often unnecessary and I'm entirely fine with going with cheaper options if we measure it and know it will meet the same spec
<tnt>
(which I really appreciate :)
<whitequark>
frankly
<whitequark>
the weak point in Glasgow is probably Python
<whitequark>
which is also one of its selling points as well
<whitequark>
but that's true in part because so much effort went into the hardware...
<niklas>
I guess for the 3V3 and 1V2 main LDO, whatever I find will be fine?
<niklas>
whats the expected current consumption on those rails? all below 500mA I guess?
<whitequark>
1V2, pretty much whatever works, the FPGA core current is very low
<whitequark>
3V3, we specced 500 mA max for the current design, so a replacement that can do that is definitely OK
<whitequark>
we went for the cheapest TI parts when choosing the LDOs
<electronic_eel>
but also dfn to get the heat away, IIRC also ones with alternatives in the same footprint
<electronic_eel>
the ldos used on revC0 were discontinued or something, so they had to be changed
<niklas>
for the routing, I found some wires around the buffers have larger clearance to each other than just clearance
<niklas>
was that in regards to crosstalk, or just for aesthetics?
<electronic_eel>
aesthetics, marcan wanted to make it nice and symmetric
<whitequark>
crosstalk was actually an issue with revAB because of the way FXMAs work
<whitequark>
but not for revC, that's purely aesthetics
<whitequark>
which I'd like to keep upstream but it's not something I'll ask you to spend time on :p
<niklas>
no worries I'm a perfectionist as well
<whitequark>
I actually have no idea how FXMAs are supposed to be used because of this crosstalk issue, I guess you should just never ever route any asynchronous signals (incl clock) thrugh an FXMA?
<niklas>
just getting really tied with the new buffers at some points
<whitequark>
yeah understandable, do whatever you need to get the prototypes done
<whitequark>
we can always tidy them up later
<electronic_eel>
niklas: regarding "no exposed copper on the back" - we explicitly put the testpoints on the back to allow easy testing in a jig
<whitequark>
if we could actually make boards with *no* exposed metal on back (besides grounded) then it would I think be worth looking into alternate connection variants for the jig
<electronic_eel>
maybe put them there too and just cover them with kapton tape when using on a dirty bench?
<whitequark>
but it seems unrealistic because of PTH headers
<electronic_eel>
yes
<whitequark>
SMT IDC headers don't seem likely to withstand the kind of abuse debuggers get
<whitequark>
they are also extremely rare and expensive
<electronic_eel>
and hard to replace because the shrouds melt in hot air
<whitequark>
I think you won't be replacing them because the breakage in this case will tear off traces from the PCB
<whitequark>
like the SMT USB header
<electronic_eel>
you can often fix the traces, but have to solder on new ones afterwards
<whitequark>
(of course, we do have that SMT USB header, but it's a compromise on all counts)
<electronic_eel>
I would prefer usb-c. I sent some suggestions for nice-to-solder usb-c connectors to esden and he said he will order and test them
<whitequark>
I'm on board with usb-c
<whitequark>
one of the most requested changes, I think
<electronic_eel>
so maybe the dfm roadblock for usb-c will be solved
<whitequark>
I don't actually have any usb-c devices or cables currently, so it'll actually be a bit of a problem for me personally, but it seems clearly better for everyone
<whitequark>
(well no I have one cable from type-C to DC5525 I use for the soldering iron)
<electronic_eel>
I'm pretty sure you can buy usb-a to c cables somewhere near you
<whitequark>
oh absolutely
<whitequark>
I'm only saying that I hear this from people saying they only have A-C cables around whereas I only have A-B cables around
<whitequark>
like usual, different subpopulations have different things they see as the default or most common
<tnt>
Good A-C cable aren't cheap ... (and I don't want to buy "bad" ones because then I'd have a mix and it'd be the lottery everytime I pick one from the bin)
<whitequark>
and we'll probably hear a lot from people who would rather use A-B
<whitequark>
niklas mentioned this tends to degenerate into a sort of holy war, and I see that; which is why I'm saying that overall I see type-C as the better option going forward, even if some people (incluing me) might find it less convenient in some ways
<electronic_eel>
I think the target audience for glasgow will have boxes full of weird and strange adapter cables, incl. usb-a/c, mini-usb, micro usb,...
<tnt>
C is clearly the future, no doubt about that.
<whitequark>
do we know our target audience? do open-source projects ever really know?
<whitequark>
we only hear from people who either have (a) issues they'd like to have fixed, or (b) enough time, goodwill, etc so they'd like to collaborate
<electronic_eel>
I think having some fun at tinkering with electronics can be assumed in the target audience
<electronic_eel>
and that often means connecting to lot's of different stuff
<whitequark>
this is of course true
<whitequark>
but consider this: I have fun tinkering with electronics. I'm also sick and don't have a lot of energy to spare (which is a huge part of -why- Glasgow is so useful to me day to day). I've also recent-ish-ly had to move, several times, on a shoestring budget
<whitequark>
those weird adapters? unless I know I'll need them, not something I'm going to carry around to a place where I have maybe just a corner for my own stuff
<JanHenrik>
electronic_eel Niklas and I have tested quite a few easy-to-solder(-no-bridges) type-c receptacles, the one we intent to use is well tested :)
<whitequark>
this went on a huge tangent, none of this is super relevant to the USB connector type issue
<whitequark>
what I mean is that I'm wary of assuming things about audience of an OSS project
<electronic_eel>
JanHenrik: do you have a link or part no?
<whitequark>
one tends to expect everyone to be exactly like them, and there is not much feedback to correct for that
<electronic_eel>
whitequark: true
<whitequark>
JanHenrik: is it a PTH or SMT one btw?
<whitequark>
I forget, I think otterpill has an SMT one?
<electronic_eel>
JanHenrik: hehe, that is exactly the one I use
<JanHenrik>
(pins dont stick out with 1.6mm PCB)
<whitequark>
that's the best possible option for end users, what about soldering it? iirc esden was worried about paste in pth
<whitequark>
if it works well I'd very much like to use that connector upstream because you can't beat the mechanical strength of a good throughhole connector
<JanHenrik>
afaik, there are also equivalent models from well-known manufacturers
<JanHenrik>
Paste in pth works, that's what I did with the Otterpills
<JanHenrik>
(but please don't look at the pins of the USB-c receptacle of the Otterpills, had an error in the gerber /o\ )
<whitequark>
heh
<electronic_eel>
whitequark: some paste/solder will flow into the hole, but if you don't make it too large the joint will come out good
<whitequark>
electronic_eel: does it translate between PCBA houses well? or do you have to customize the copper/paste layers for each?
<electronic_eel>
I did just use one PCBA manufacturer for these yet and sent them my design for review first. but they didn't recommend to change anything and all worked out well
JanHenrik has quit [Remote host closed the connection]
JanHenrik has joined #glasgow
<electronic_eel>
the key is that the pth fins have separate pads that don't connect to anything else
<electronic_eel>
so if solder is sucked away, it won't affect other parts of the connector
<electronic_eel>
even in the worst case of bad joints, you could easily touch up these parts with a soldering iron
<whitequark>
ah
<whitequark>
that sounds good
<electronic_eel>
esden told me that he just tried the much more dense usb-c connectors that have the pins for usb 3. he had shorts and other trouble with them
<electronic_eel>
that was why he didn't like usb-c
<Twix>
whitequark, the glasgow boards i build for myself are using those usb-c 2.0 connectors. Worked quite well. I just put it a little bit to far away from the board edge :)
<niklas>
why are QA4 and QA6 driven by two fpga pins?
<Twix>
There is an comment below the fpga pins in the schematic describing the issue this solves
<electronic_eel>
I thought when I get the first gear that needs usb pd, I'd use a good meanwell 24vdc supply and combine it with my own usb pd board
<JanHenrik>
hawever they don't negotiate power with every device I have
<electronic_eel>
did you do some debugging to find out why?
<JanHenrik>
hmm, I wouldn't recommend that, I would buy a Lenovo type-c charger
<JanHenrik>
*screams in thousands of pages specification*
<JanHenrik>
No, it was with my own(TM) implementation, which took weeks to eventually work a little bit. I discontinued that project
<electronic_eel>
oh, I thought you used some usb pd code on the otterpill?
<JanHenrik>
I did, but some usb pd code is _alot_. PD is a mess
<electronic_eel>
which part of usb isn't a mess?
<JanHenrik>
:D
<JanHenrik>
a usb pd phy with integrated mcu + pd firmware is ruffly the same price as a standalone usb pd phy, so i switched to such integrated pd controller ics
<electronic_eel>
do you consider the pd part of otterpill unfinished when you say you discontinued it?
<electronic_eel>
the stm32g0 series is interesting for pd, as they have some with integrated pd phy
<JanHenrik>
the PD part works, i can request specific profiles/voltages, but thats it. People can play with that and opefully someday create a better implementation :3
<electronic_eel>
ok, that is a start. but I can understand when you say you don't plan to become renowned as the usb pd expert
<JanHenrik>
yep, but that is kinda proprietary. ST wants you to use their x-cube-pd workbench, which in the end ships closed source binaries. I tried to use the workbench for the FUSB, but the PD part never worked (don't know why, didnt dug into that)
<electronic_eel>
whitequark would probably post her abyss text now
<JanHenrik>
I totally dont plan to become a usb pd expert :D
<electronic_eel>
I like the stm32 series, but don't ever touch their cube stuff
<electronic_eel>
just need it to extract the die ids ;)
<JanHenrik>
sadly knowing a usb-pd-phy with integrated mcu seems to be qualifying enought to be an expert of some kind :D
<JanHenrik>
I like cubeMX tbh, works great and I can configure quite complex stuff which in the end works out of the box
<electronic_eel>
maybe for playing with the clock trees of the more complex parts, but the code that it generates is often buggy and hard to understand/debug
<JanHenrik>
...expert of some kind in some EE bubbles*
<JanHenrik>
what kind of code do you mean? I just use it to generate the Inits, DMA channels and the clocktree
<electronic_eel>
I really like the chibios-hal and base my stuff on top of it
<JanHenrik>
:O the pd implementaition for the otterpill is written in ChibiOS and it does not work at all
<electronic_eel>
hmm, do you think that has to do with chibios or more with the implementation?
<electronic_eel>
I think chibios-hal doesn't have support for usb pd, so this must be some extension
<JanHenrik>
I don't really know, behaviour is: I can init peripherals, e.g. ADC in continious mode and start it, however its update rate is less then 1 Hz
<electronic_eel>
but I have to admit that the documentation sometimes lacks a bit
<JanHenrik>
hmm, i can try to get it working, that would actually revive quite a few PCBs/projects I have laying around ^^
<electronic_eel>
the maintainer, Giovanni, is quite active and helpful, if you have some problem he usually answers quick when you post in the forum
* whitequark
screams in USB PD
<whitequark>
i was more or less forced to become familiar to some extent with USB PD as a part of my Thunderbolt issue debugging
<whitequark>
i also tried reverse engineering USB PD controller firmware
<whitequark>
after learning that TI did a *die respin* of a PD controller to support USB PD 3 (they added some more SRAM to it) it was kind of clear where this all goes
<whitequark>
those firmwares are massive (for the job they do) and brutally complex
<hl>
they had to add SRAM just to fit the added firmware complexity? hahahahaha
<whitequark>
yes
<awygle>
Oh I fukkin love chibios, especially the HAL
<whitequark>
they kind of tried to hide that fact
<awygle>
I ported it to the msp430x mcus
<whitequark>
probably because they are ashamed of the abomination, I mean, I would surely be
<JanHenrik>
:D
<whitequark>
hl: do note that in those controllers there's no integrated flash, so the entire firmware goes to SRAM
<hl>
aah
<JanHenrik>
TI is good at hidint certain facts
<electronic_eel>
does the user compile this firmware or is it just blobs provided by them?
<whitequark>
still it's like a hundred KB of thumb code
<whitequark>
electronic_eel: officially it is a blob which you configure with a tool that appends an app config block (which is similar to serialized I2C register writes)
<whitequark>
(the PD controllers hve a semi standard I2C interface)
<whitequark>
in practice, every TBT3 device I have seen actually had the vendor rebuild the blob
<whitequark>
Apple, Sonnet, Dell, ...
<JanHenrik>
The firmware I use, which is written by google ( and ported to chibios hal), has a file which contains a state machine with ~1400 lines :D
<whitequark>
this is (a) not possible according to TI and (b) expressly prohibited by TBT3 licensing terms according to Intel
<whitequark>
so I am guessing there is lots of behind the scenes action covered by NDAs
<electronic_eel>
wow, that looks like a real big mess
<niklas>
are you happy with the DAC081C081 and ADC081C021?
<whitequark>
no shit it is a mess
<hl>
Jesus that's awful. How fantastic. A chip that's advertised and nominally documented but where you only get to make it work properly if you're a big company.
<whitequark>
electronic_eel: if you ever wondered why all TBT3 devices look alike, it's because they are all the same Intel reference design
<whitequark>
you actually can't just do your own TBT3 device
<whitequark>
you have to pick one of the two or three reference designs per generation
<whitequark>
or you can't get licensed
<whitequark>
you can lay out the PCB with some restrictions and slap your own logo on it
<whitequark>
you can of course integrate whatever PCIe stuff you want on it, and I think any power supply
<whitequark>
but the actual thunderbolt parts have to be a carbon copy of intel schematic
<miek>
i have bad memories of working with one of TI's battery gas gauge ICs. i needed to flash in a blob of calibration data, but the documentation was a mess & any minor mistake in the process bricked the chip. i ended up finding what i needed from someone's defcon talk
<electronic_eel>
niklas: they do what they are supposed to do. but for revD we are planning to replace the adc with INA233
<whitequark>
in fact if you use TBT3 compatible USB PD controllers, TI will flat out refuse to talk to you if you do not tell them whcih Intel reference design you are implementing
<whitequark>
even though they work just fine with normal TI PD controller firmware, and also are sometimes more available
<whitequark>
which is why some major vendor wanted to use those and their engineer asked this question on E2E
<whitequark>
they are also export controlled for some incoherent reason
<electronic_eel>
it seems like intel used some really restrictive licensing terms
<whitequark>
you don't need to sign an NDA but you do need to qualify for export control
<electronic_eel>
but why did they do that?
<whitequark>
even though it's basically the same silicon as normal PD firmware
<hl>
TI seems to be a lot more asinine about export control than most companies
<electronic_eel>
I don't think that comes from ti, but tis lawyers are afraid of the terms intel set
<hl>
I assume they rolled 1 on a d20 where 1 means "your corporate lawyer determining company policy on export control law comes up with the most over-the-top interpretation possible"
<whitequark>
yeah I blame Intel as well
<whitequark>
at least for that case
<hl>
nah TI seems asinine on export control for Intel-unrelated stuff
<whitequark>
miek: an acquaintance a long time ago bought a gas gauge IC devkit from TI, and one day noticed they erased all mentions of that IC from their website
<whitequark>
asked support about it and they silently ban his account
<whitequark>
the most plausible idea I've seen about it is TI unwittingly violated some patent or something
<whitequark>
and decided to just pretend it never happened
<whitequark>
normally TI parts are great though, which is why Glasgow has so many of them
<electronic_eel>
or the ic had some major issue and they had to pay big damages to some customer?
<whitequark>
could be
<hl>
the christ
<whitequark>
hl: re "chip that is advertised and documented": they have a basically exact same chip that is not usable for thunderbolt devices
<hl>
and yeah, I've seen TI delink NRND parts from their listings too (the page still exists, with datasheet and all, but it's not linked from anywhere)
<whitequark>
which actually works like you would expect
<JanHenrik>
ADC081C027CIMK as replacement for ADC081C021?
<whitequark>
well, they don't tell you there is a cortex-m0 inside, and don't even say it has firmwre, but if you treat it as more a thing with registers it works like you'd expect
<JanHenrik>
The new ADC has no alert pin, was that function used?
<whitequark>
yes, it is used
<JanHenrik>
ah, meh
<whitequark>
it's important to avoid backpowering the DUT
<JanHenrik>
ok
<whitequark>
for single domain pure digital logic it's usually not fatal, but my understaning is that if you have multiple power wells and don't put a lot of effort into making the IC nice to use, you can destroy it if the ESD diodes become forward biased
<whitequark>
haven't killed anything myself like that yet
<daveshah>
The more likely issue is just weird behaviour if the DUT ends up half powered
<daveshah>
Which in itself could be annoying
<whitequark>
yes, like if you're trying to reset it by power cycling
<whitequark>
I did actually have routers half-boot when backpowered through JTAG
<whitequark>
well not half but I think they actually printed something from the bootloader
<32NAAFPWN>
is the position of the pullup testpoint connector critical?
<electronic_eel>
I think the headers aren't there as testpoints, but to enable the user to install different pullup values
<electronic_eel>
so the position doesn't matter (if it is not under the shroud of the port headers)
<whitequark>
they are not practical as testpoints as the pitch is too fine
<electronic_eel>
also I don't think you'd need these as testpoints
<electronic_eel>
you can get everything you want for testing from the port headers
<awygle>
i've corrupted flash on half-powered chips
<whitequark>
I think there was some talk of using those as TPs
<awygle>
or, well, FRAM. same thing.
<whitequark>
but we eventually decided to use port header through holes instead
<whitequark>
awygle: you know, flash is really weird. once I discovered by accident that some specific 1.8V flash reads fine from 3.3V but does not write, and neither reads nor writes from 5V
<awygle>
flash _is_ weird
<whitequark>
(but survives that for a few minutes)
<awygle>
before you even get into the multi-bit-per-cell variants
<whitequark>
(the damn thing burned my finger in retaliation)
<awygle>
or the 3D variants
<awygle>
or FG vs CT
<whitequark>
so that implies it has a window comparator for writes, not just brown out detector
<whitequark>
which is interesting
<whitequark>
I guess if you overdrive the voltage pump when writing it's as bad as underdriving it
<whitequark>
you'll just get instability in the other direction
<electronic_eel>
I think the lifetime of flash depends a lot on the conditions in the moment of erase
<awygle>
mhm
<whitequark>
what's FG and CT?
<awygle>
floating gate and charge trap
<whitequark>
oh
<awygle>
apparently one of the hardest tests for flash is "program cold, read hot"
<awygle>
(or... maybe the other way around? i forget)
<whitequark>
that's the classic way instability manifests, right?
<whitequark>
I remember that for old(er) parallel flash this also depended on the frequency
<awygle>
yep
<whitequark>
parallel flash sounds fun to try and push to limits
<awygle>
and you can make it much more likely to pass by changing the width of the programming pulse
<whitequark>
I only need to, er, finish REing this CPLD series
<awygle>
it's super weird
<hl>
what CPLD?
<whitequark>
ATF15xx
<whitequark>
last true 5V CPLD in active production
<hl>
interesting, what's your use case?
<whitequark>
well, the ATF15xxAS
<electronic_eel>
what is missing to the cpld re?
<whitequark>
glasgow io extenders for parallel stuff
<whitequark>
^ that's the use case
<whitequark>
electronic_eel: I have most of the macrocell pinned down, with the last three unknown bits pinned down to a second order truth table
<whitequark>
I'm not yet entirely clear as to what algebraic relationship they have but it seems something fairly reasonable
<whitequark>
I have a small part of the sparse interconnect pinned down but I think I know how to do it either with or without hardware-in-loop
<whitequark>
the main problem with the macrocell is that they really went to town with interdepenent muxes
<whitequark>
every corner case combination of config bits seems to trigger something new and exciting seemingly unrelated to the obvious function of those bits
<electronic_eel>
ok, so their macrocell design is complex and has lot's of non-obvious bits
<whitequark>
I think there is a fairly simple netlist that explains it (there better be, the entire thing is laid out on 2 metal layers, those masks look absurd) but so far I tried to be descriptive
<whitequark>
I believe I know the function of every bit combination, actually
<whitequark>
every possible one at all, not just the ones their software generates
<whitequark>
what remains wrt macrocell is writing a complete Verilog model and fuzzing it against real hardware
<whitequark>
pt1_mux, pt2_mux and xor_a_input don't match the reality (they + one remaining unknown bit are the ones I referred to above)
<whitequark>
the rest seems correct
<awygle>
are you gonna do the azonenberg thing of running your verilog model on an FPGA and putting an official vendor bitstream on it?
<awygle>
not sure it's useful but it's Cool (TM)
<whitequark>
awygle: probably not because the flash layout has some absurdly complex set of permutations applie to it
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow
<whitequark>
well, both flash and JEDEC, JEDEC being more straightforward
<whitequark>
I guess I can just use offsets from chipdb rather than encoding them algebraically in Verilog
<whitequark>
that'd make it a lot easier
<whitequark>
electronic_eel: it's a pretty nice macrocell though, they have a lot of redundant routing paths
<whitequark>
there are some impossible combinations like output enable plus async set
<whitequark>
er, individual output enable plus async set
<whitequark>
awygle: electronic_eel: i think you can actually already play with that CPLD if you want, i have a CLI tool that allows configuring the macrocell manually
<whitequark>
and of course jed2svf converter
divergence has joined #glasgow
diverger has quit [Ping timeout: 240 seconds]
<niklas>
why are R48 and R49 on the back?
<electronic_eel>
niklas: the idea was to easily tweak them
<electronic_eel>
they were added for revC1 to help the shutdown on overcurrent IIRC
<electronic_eel>
so the value was mostly guessed and the idea was to make them easily tweakable
<electronic_eel>
that is also why there are the dnped pads in parallel
<niklas>
I'm surprised in your trust in vias
<electronic_eel>
now that this design aspect is verified I think the r50 and r51 dnped pads could also be removed
<niklas>
at some points a whole rail passes a single via
<whitequark>
which rail?
<whitequark>
I think this happens more than once
<whitequark>
hm, for 1V2 we double the vias, but for 5V DUT power we don't