<marcan>
heck it's almost pin compatible with the TCA9534, I just need to lift 2-3 pins and it could be tested on the revC0 board
<marcan>
plus removing the level shifters
<marcan>
only two addresses though, so for revD we still need a switch or something, but should be fine for revC
<marcan>
oh the glasgow is only supposed to go down to 1V8, nevermind
<marcan>
I had 1V2 in my head for some reason
<marcan>
whitequark: I think that chip might solve all of our problems, and get rid of the shifters entirely?
<marcan>
as long as it doesn't do something stupid like clamp the I2V bus when the VddP is off, but I hope not
<marcan>
*I²C
<marcan>
it has well-behaved POR behavior when VddP is applied
<marcan>
so it should cleanly start up in no-pull mode when Vio is raised
<marcan>
(and then we can configure the pulls)
hl has joined #glasgow
<marcan>
heh it even has the same I²C address as our current chips
<marcan>
and an identical interface
<marcan>
so we can just swap out the chips with impunity, zero impact to software
<whitequark>
marcan: excellent
<marcan>
so I'm going to order those, and also some of the other shifters and misc crap as a fallback
<marcan>
and I'm also going to try just bypassing the shifters on the current revC0, and see if the current expanders are happy with a wacko I²C bus, which they might be
<marcan>
that way current revC0 owners can just choose to fix the problem by hotairing the shifters off and shorting them through, which is easy
<marcan>
and optionally put in the new chips if there is a clear benefit, without impact to board ID/whatever
<marcan>
and C1 will be using the NXP chips from the get go
<whitequark>
yup
<marcan>
whitequark: and the Vio enables are dedicated pins, right?
<marcan>
so not an I2C transaction, so no problem with the bus being not-idle when Vio is raised
<marcan>
we just need to make sure we time it right wrt capacitance
<whitequark>
Vio enables are dedicated pins
<marcan>
cool
<whitequark>
marcan: this also fixes *another* problem
<whitequark>
which is that level shifters are powered off Vio and so aren't accessible without Vio
<marcan>
nah, that's still the case
<whitequark>
oh?
<marcan>
the core is powered off of Vio on those
<marcan>
you can't talk to them with that off
<whitequark>
ohhhh i see
<whitequark>
ok that's fine i guess
<marcan>
that's good because we get POR behavior we can control without using the dedicated reset input
<marcan>
but bad because yeah, we can't pre-configure them
<marcan>
but I think that's acceptable
<whitequark>
yeah, sure
<marcan>
the only trip-up here will be if those things do something *really* stupid when Vio is low but Vi2c is active
<marcan>
which isn't really specified
<marcan>
but I really really hope that's not the case
<marcan>
from the diagram I think the only output to the I2C side is an NFET on SDA, and if that gate is low because whatever control circuitry it's connected to is unpowered, it shouldn't do anything to the bus
<whitequark>
yeah
<marcan>
whitequark: I guess the only issue with having the pulls not match Vio is that it could hypothetically confuse e.g. a user I2C device that is being powered off of Vio
<marcan>
but I guess e.g. the i2c applet can just do some lockup-clearing sequence at startup?
<marcan>
(send >9 clocks with SDA high and a STOP)
<marcan>
alternatively it could just drive SCL hard high, which I think is guaranteed not to generate any lockups (then it just needs a STOP condition to clean things up)
<whitequark>
elaborate
<whitequark>
pulls not matching Vio is very undesirable as it will cause current to flow through protection diodes (if any) or kill the device (if it doesn't have those)
_whitelogger has joined #glasgow
<marcan>
whitequark: no, I mean the pulls not coming up with Vio
<marcan>
but later
<marcan>
which could e.g. leave a user i²c bus floating until the pulls are configured
<whitequark>
ohhhh
<whitequark>
hmm
<whitequark>
that should be a documented caveat, yeah
<whitequark>
we can't economically address *every* edge case
<marcan>
I can think of one reasonable fix: put a FET on vio at the connector
<whitequark>
hmmm
<whitequark>
p-channel fet?
<marcan>
yeah
<whitequark>
how do we turn it off with vio=5v
<whitequark>
pullup?
<whitequark>
then we need a 5v safe pin to enable it
<whitequark>
which we don't really have
<marcan>
eh, can be driven from another transistor
<whitequark>
so, another i2c expander
<marcan>
the driver circuit isn't a huge deal
<whitequark>
we don't have any more gpios
<marcan>
but more importantly we'd have to either use the two free enable pins
<marcan>
or something else
<whitequark>
yes
<marcan>
I'm not sure we want to do this for revC1
<whitequark>
agree
<marcan>
but I think it's something to consider for revD
<whitequark>
hmmm
<whitequark>
we could test it on revD0 and then do a revC2 with the fix, maybe?
<whitequark>
i can now transparently fix this
<whitequark>
and revD0 having that means the code is there
<marcan>
sure. I think I can fit the FETs to the left of the A/B labels (might have to sacrifice or move the 3V3/5V testpoints, but I can probably find a place for those)
<marcan>
I think they could be driven by a simple pullup and diode from the FX2
<marcan>
revD0 needs an expander
<marcan>
though it would be nice to be able to time the enable with the pullup activation, which we can do if we have dedicated pins, but not with an expander
<marcan>
something to think about I guess
<marcan>
wait no, the diode thing is bullshit
<marcan>
but anyway, could be a pullup and drive transistor
<marcan>
there are a million ways to solve this problem, that doesn't bother me, it's more about where the IO comes from
<whitequark>
marcan: so we could do something like
<whitequark>
wait no
<whitequark>
we can't time the enable with pullup activation
<whitequark>
how would we?
<marcan>
if we have dedicated IOs, like the two spares on revC, we just flip them at the right point in the I2C transaction where the pullups activate
<marcan>
which from my reading of this is basically right after the rising edge of the ACK clock
<marcan>
could tune it with some spinloop and get really close
<whitequark>
marcan: assuming the FX2 isn't in an interrupt
<whitequark>
unsure if i want to do this in software
<marcan>
eh, we can disable interrupts for that brief period
<marcan>
this is solvable
<whitequark>
hmmm
<marcan>
at the very least, merely issuing the GPIO write to both flip clock and the enable at the same time is atomic, and gets us within propagation delays
<marcan>
if we want to fine tune it, it's just two writes with a few nops in between
<whitequark>
flip clock?
<whitequark>
the fx2 has hardware i2c
<marcan>
oh
<marcan>
I thought we were bitbanging
<whitequark>
no
<marcan>
well we could bitbang this part
<marcan>
:P
<whitequark>
it has hardware i2c *only*
<whitequark>
those aren't gpios
<marcan>
uh
<marcan>
er
<marcan>
okay
<marcan>
then it's harder yes
<marcan>
not impossible but harder
<whitequark>
marcan: i think it's futile
<whitequark>
here's why
<whitequark>
we don't know external capacitance
<whitequark>
which will determine the phase of Vio rise
<marcan>
yeah
<whitequark>
let's kick *this* issue down the road imo
<whitequark>
there are far too many uncertainties here
<marcan>
sure
<marcan>
I think if we have fets and another expander, we can at least let the user pick
<marcan>
e.g. enable pulls first and then vio
<whitequark>
and well the obvious workaround is "add a pullup manually"
<marcan>
which probably works for a ton of things
<whitequark>
we could add that in revD0 and C2, yes
<marcan>
and yeah
<whitequark>
i'm open to that idea
<whitequark>
it's not clear it's pulling its weight in complexity, but we could do that if it turns out useful
<marcan>
I think for revD it might be cheap depending on what we need to add anyway
<marcan>
I'm not sure if it's worth it for C2 yet
<whitequark>
if we add it for D0 we really ought to add it for C2
<marcan>
I'm fine with that as long as it's using the free GPIOs, not an expander
<marcan>
I'm not sure it's worth dumping an expander on C2, even if we get rid of the shifters
<marcan>
if it's an 8bit one that's still a lot of board space
<marcan>
(and wasted IOs)
<marcan>
revD can use an expander
<whitequark>
there are 4 bit and iirc 2 bit ones
<marcan>
looks like it, yeah
<marcan>
not sure about level shifting, but for *this* we might be able to just get away with one powered by 5V on a 3V3 I2C bus
<whitequark>
yep
<marcan>
that config is just barely under spec on Vil for most chips, but I can't remember the last time I sent 3V3 into a 5V device and it didn't work
<marcan>
er Vih
<whitequark>
we could get one that's explicitly supporting that
<whitequark>
i think they exist
<marcan>
I think most just say 0.7V × Vcc
<marcan>
OTOH if we use a pullup for the fets, we can just run this thing at 3V3
<marcan>
since what they *do* have are 5V tolerant IOs
<marcan>
gives us less controlled Vio ramp up though (fet gate capacitance etc, depends on pullup value), but I'd have to do the math to see if it matters
<marcan>
File "/home/marcan/electronics/Glasgow/software/glasgow/applet/audio/yamaha_opl/__init__.py", line 76, in <module>
<marcan>
import aiohttp.web as web
<marcan>
whitequark: does it really try to load all applets, and all applet deps, in the main app?
<marcan>
this seems suboptimal
<whitequark>
marcan: yes
<whitequark>
it needs that to give you the CLI
<whitequark>
marcan: the policy is as follows
<whitequark>
if it's something super common like aiohttp (which is likely to be used by a ton of applets) it is always loaded
<whitequark>
and is a hard edp
<whitequark>
*dep
<whitequark>
if it's something obscure like libsamplerate (audio resampler), it is an optional dep and checked live by the applet
<whitequark>
that's already done btw
DanHatesNumbers has joined #glasgow
DanHatesNumbers has left #glasgow [#glasgow]
<marcan>
fair
<marcan>
fwiw aiohttp is uncommon enough that *I* didn't have it
<marcan>
and I have a metric fuckload of garbage installed on this machine
<marcan>
(this is not a venv)
<whitequark>
hmmm
<whitequark>
i mean, http is common
<whitequark>
and glasgow heavily relies on asyncio
<marcan>
sure
<marcan>
anyway, minor things
<whitequark>
i fully expect more applets to use http
<marcan>
more importantly, how do I test the pulls?
<whitequark>
try uh
<whitequark>
you have a 24c eeprom right?
<whitequark>
memory-24x has a --pulls option
<marcan>
I'm using the i2c-master thing
<marcan>
against a random i2c widget
<marcan>
I: g.applet.interface.i2c_master: scan found read address 0b100001
<marcan>
I: g.applet.interface.i2c_master: scan found read address 0b100010
<marcan>
not sure why it's seeing it twice though (real address should be the first one)
<marcan>
scan-write only finds the first one
<marcan>
wonder if it's really acking the second one or something is broken in glasgow
<marcan>
still trying to wrap my head around it because I'm annoyed
<marcan>
whitequark: argh, I get why they oscillate
<marcan>
it's not about undershoot
<marcan>
I *thought* Vil = Vol - 70mV, but that's not the case
<marcan>
when not driving, Vil = 0.3 × Vcc
<marcan>
they only switch to the extra low Vil *after* they're driving
<marcan>
so when one pulls low the other is immediately going to recognize it, and drive low too
<marcan>
there are round-trip delays involved that make it into a ping-pong oscillation
<whitequark>
ohhh
<marcan>
one drives low, the other sees the low (as soon as it drops below 0.3Vcc), drives its A side low, then eventually sees its own A side drop, and drives its B side low again. By then the first one has given up on driving low, and has its A side rising, flip and repeat.
<marcan>
whitequark: you know what? it works fine without a shifter.
<marcan>
at 1.8V and at 5V.
<marcan>
no diodes to mess with SDA and SCL
<marcan>
I'm going to write this into the revC0 ECN page.
naus has joined #glasgow
<whitequark>
marcan: hmmm
<whitequark>
no leakage?
<marcan>
nope
<marcan>
well
<marcan>
I mean, sure
<marcan>
I see 50mV on Vio
<marcan>
but who cares
<marcan>
:P
<whitequark>
acceptable for C0 with a fix, but make sure to mention it in the ECN page
<whitequark>
people will do far worse things otherwise
<whitequark>
i mean
<whitequark>
like removing FXMAs on revB
<marcan>
sure
<marcan>
whitequark: okay to throw some photos of the rework in the repo? (to link from the wiki; alternatively I can throw them on my server)
<marcan>
(3 x 120KB)
<whitequark>
marcan: can't you put them on the wiki itself?
<marcan>
noep
<marcan>
not a thing apparently
<whitequark>
hm
<whitequark>
marcan: so you can attach them to an issue comment, but never submit
<whitequark>
it goes to githubusercontent.com
<marcan>
does it stay there forever?
<whitequark>
i think so, yeah
<marcan>
that's what I was *hoping* the wiki feature would do
<marcan>
I have no idea why they don't
<whitequark>
probably no one got around to implementing it, i guess
<marcan>
whitequark: still going to order the PCA6408 and validate it as a hotfix before we call C1 done
<marcan>
but I guess you don't particularly need them, right? shouldn't block anything at this point, when the easier fix works
<marcan>
oh btw, if my reading of everything is correct, a design for the PCA6408 *will* be drop-in compatible with the TCA9534 (if we go back to using it), *except* that the slave addresses will be different
<marcan>
RESET makes one address pin high on the TCA, VddI²C makes another one high, and the address that matters gets moved to the next bit
<marcan>
the *address* pins on the TCA *are* specced up to 5V, so I don't expect leakage from putting VddI²C on one of those
<marcan>
so if for whatever reason we need to go back to the old expanders (or another compatible one), we can do that
<marcan>
(accepting the leakage)
<marcan>
I was thinking of putting links/resistors on the board to make it support both chips, but given this I don't think it's worth it, I think it's easier to make the software autoprobe addresses if we need to go this route, than to add a bunch of DNP/0Ω junk to make it board-level
<emily>
oh, what was the fix?
<whitequark>
marcan: should not block anything, yesa