<marcan>
whitequark: $work raised my NMI yesterday T_T
<marcan>
tonight if nothing else hits the fan
<whitequark>
alright
thaytan has quit [Ping timeout: 246 seconds]
<_whitenotifier-1>
[Glasgow] whitequark commented on commit aab41274f63814b26f5e82aab47e901a7c55ae86 - https://git.io/fjTn5
thaytan has joined #glasgow
<marcan>
whitequark: so, new expanders and connecting the enables to the shifters
<marcan>
anything else?
<marcan>
should I put the shifter enable thing through a 0Ω link, just in case somehow it breaks something?
<whitequark>
marcan: can't hurt
<marcan>
whitequark: the change, or the link?
<whitequark>
the 0 ohm link
<marcan>
will do then
<whitequark>
i've yet to regret putting in a design feature like that
<marcan>
we can probably remove it in a minor revbump (revC1.1? lol)
<marcan>
once it's obvious it's not a problem
<whitequark>
it's just fine to have a revC2 for that
<whitequark>
and yeah
<marcan>
sure
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<marcan>
whitequark: um, wait, we're making shit up. the shifters don't *have* enables.
<marcan>
they're 6 pins. vcc×2, io×2, gnd, dir
<whitequark>
marcan: LDO enables
<whitequark>
they're functionally shifter enables
<whitequark>
because shifters have UVLO
<whitequark>
i'm not sure when LDO enables became shifter enables, i think i referred to them as LDO enables and then i assumed you just meant it that way
<marcan>
um, but we already have the LDO enables? I'm confused
<marcan>
we have enable pins for the LDOs. I thought the idea was to connect that to the shifters too, so the shifters powered down as soon as the LDOs power down, without having to wait for the rail to discharge
<marcan>
butw e don't have shifter enable pins at all
<_whitenotifier-1>
[Glasgow] marcan commented on issue #107: Consider connecting level shifter EN to DAC EN - https://git.io/fjTRn
<_whitenotifier-1>
[Glasgow] marcan closed issue #107: Consider connecting level shifter EN to DAC EN - https://git.io/fjTRc
<Hellsenberg>
O_o
<marcan>
whitequark: any idea what the hell the difference between QFN16, UQFN, VQFN, WQFN is?
<marcan>
NXP calls what they offer the part in "HVQFN16"
<marcan>
kicad has QFN16, UQFN16, WQFN16
<marcan>
NXP also has XQFN16 which is rectangular, not drawing that one.
<marcan>
this is just for the footprint filter setting
<marcan>
VQFN supposedly stands for "very thin"; why does thickness matter for a freaking footprint definition? (okay, 3D model, but still, the footprints are subtly different, but look compatible...)
<marcan>
oh the QFN doesn't even have the same pinout
<marcan>
nevermind, not adding it
<whitequark>
marcan: who the fuck knows, each vendor has their own bizarre rules ofr that
<whitequark>
i think this kinda counts as pseudosymmetry?
<marcan>
kind of I guess?
<marcan>
I mean you have to accept a certain level of "subsections" of course
<marcan>
like on the regulator side, there are parts which aren't mirror symmetric, but if you treat a unit of, like, a resistor and a capacitor as one, then it's translated about a mirror-symmetric origin
<whitequark>
right
<marcan>
not much I can do that without doing some utterly silly routing though
<marcan>
*about
<marcan>
(which is stupid for regulator decoupling)
<whitequark>
yeh
<marcan>
I'm rotating the C59 refspec to match C45 though
<marcan>
whitequark: there's so much space left of the pulls now, it feels weird
<marcan>
considering how packed everything else is, it's obvious we removed stuff there :p
<whitequark>
do you want suggestions on fixing that or? :P
<marcan>
dunno :p
<whitequark>
like the obvious suggestion is to move RNs
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±5] https://git.io/fjTuG
<whitequark>
but eh
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan 88ee1fe - revC1: replace pulls with PCA6408A and remove shifters
<marcan>
I could move the traces, there isn't really anything to gain by moving the RNs. they're fine where they are.
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjTuc
<marcan>
technically I can stick a pile of 16 resistors on the back to pull down all the DIRs. it won't be terribly nice, but I can make it fit.
<marcan>
if you think it's worth the extra parts, I can do it, otherwise let's close_?
<marcan>
(they have to be discrete, I can't really route a network to do that)
<whitequark>
marcan: let's closes
<whitequark>
we can do this for revC2 if it becomes a major problem
<whitequark>
i think it's good enough for now and esden will hate me for +16 parts
<_whitenotifier-1>
[Glasgow] marcan commented on issue #96: Level shifter state during reconfiguraiton? - https://git.io/fjTu6
<_whitenotifier-1>
[Glasgow] marcan closed issue #96: Level shifter state during reconfiguraiton? - https://git.io/fjTui
<_whitenotifier-1>
[Glasgow] marcan commented on issue #106: Pulls on revC0 are BROKEN and I²C level shifters require replacement - https://git.io/fjTuP
<_whitenotifier-1>
[Glasgow] marcan closed issue #106: Pulls on revC0 are BROKEN and I²C level shifters require replacement - https://git.io/fjTuX
<marcan>
whitequark: so, next things to do, exporting revC0 files, something something PLLs?
<marcan>
there are a few more open issues, can you take a quick look?
<whitequark>
yep, sec
<whitequark>
#102 should be easy
<marcan>
also upstreaming things of course
<whitequark>
#98 as well
<whitequark>
#104 is a comment on schematic
<whitequark>
and yeah #97 is the PLL issue
<whitequark>
that's the major one
<marcan>
I don't really know what 102 is about
<whitequark>
marcan: oh, it was before you arrived
<whitequark>
so the SYNC pullup is currently sized for the huge-ass UP5K LED drive pins
<whitequark>
that are like 20 mA
<marcan>
oh wait
<marcan>
130 lol
<marcan>
yeah okay that's ridiculous
<marcan>
so uhh, 1K/
<marcan>
?
<whitequark>
what's the lowest we can get?
<marcan>
checking the datasheet
<whitequark>
i almost want a discrete transistor there
<whitequark>
but ehhhh
<marcan>
that requires two FPGA pins
<whitequark>
wait, why
<whitequark>
oh
<whitequark>
oh of course
<marcan>
I mean we *do* have two FPGA pins, if I can escape route one of those balls out again
<marcan>
buuut
<marcan>
yeah
<whitequark>
no, we need those for PLLs i think
<marcan>
on the A bank?
<whitequark>
we need something to do with PLLs
<whitequark>
i'm no longer sure what
<marcan>
I mean we already have the doubled pins on the A bank
<marcan>
I'm saying we have two totally disconnected pins on top of that
<marcan>
though maybe you're saying you want to do something something to reuse those from the FX2 bank
<marcan>
to fix the PLL problem there
<whitequark>
i guess 1k is fine
<whitequark>
i keep trying to shoehorn the SYNC pin into some sort of software PLL or whatever
<whitequark>
which probably isn't happening anyway
<whitequark>
we can keep it just as a trigger
<marcan>
wait, hold on, what
<marcan>
I'm lookingat the datasheet and it says max sink/source current 100µA for sysIO LVCMOS 3.3.
<marcan>
what?
<marcan>
there is no way.
<whitequark>
what
<whitequark>
it should be 4 mA or something
<marcan>
oh I'm reading this wrong
<marcan>
okay, it's 100µA guaranteed to <0.2V and >Vccio-0.2V swing
<marcan>
and 8mA guaranteed to <0.4V and >Vccio-0.4V swing
<marcan>
16mA/24mA is for the LED shit
<marcan>
I thought that row was all for the LED shit
<marcan>
so 8mA at 3.3V levels
<marcan>
whitequark: so that's 480 ohms if you want to push things
<marcan>
*470
<marcan>
(rounding up)
<whitequark>
marcan: let's push things
<marcan>
note that that's a new value
<marcan>
we also only use 1k for the rail discharge resistors though
<marcan>
could make all of those 470 (that does eat 10mA or something off of VIO though, of note since they're current limited)
<whitequark>
hrm
<whitequark>
hrmmmm
<whitequark>
let's make them all 1k i think
<whitequark>
i mean, i've never really used SYNC for anything yet
<whitequark>
it just sort of exists
<whitequark>
we can always make them more aggressive later
<marcan>
sure
<Hellsenberg>
miaow
<Hellsenberg>
oops, wrong channel
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan pushed 2 commits to master [+0/-0/±4] https://git.io/fjTz9
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan d2af97c - revC1: fix old value/datasheet for PCA6408, style fixes
<_whitenotifier-1>
[GlasgowEmbedded/Glasgow] marcan 154ebbd - Make Sync pull-up 1K
<_whitenotifier-1>
[Glasgow] marcan closed issue #104: Indicate 10/12-bit ADC and DAC as functional equivalents to the 8-bit ones - https://git.io/fhjiK