<electronic_eel>
whitequark: hmm, sometimes I have a hard time understanding you - "I think your suggestion makes a lot of sense" vs. "... justifies adding all this."
<whitequark>
electronic_eel: yes. you are right. i do not communicate well here. i apologize.
<whitequark>
let me explain what i mean
<whitequark>
a) i did not realize that the i2c addresses used on the main board will result in holes poked in the address space available for extension boards.
<whitequark>
in retrospect this is obvious
<electronic_eel>
no problem, I did not realize this at first too
<whitequark>
b) i do not want to add analog muxes, diodes on ~ALERT, and other strange things to revD. i want revD0 to go to production. i think INA233 is too good of an opportunity to pass on (and it's a relatively small change), but the rest goes beyond the level of added complexity i'm comfortable with
ExeciN has joined #glasgow
<electronic_eel>
so it is mostly the risk of getting some design aspect wrong on the first try?
<whitequark>
not necessarily on first try, just unobviously wrong in general
<whitequark>
e.g. we thought the level translators we used on revC0 were fine
<electronic_eel>
I know
<electronic_eel>
how about prototyping this part of the schematics beforehand?
<electronic_eel>
I want to replicate parts of the regulators and so on for my protection board testbed
<electronic_eel>
I could add these parts there too
<electronic_eel>
no big issue because I don't have to make a dense layout there
<whitequark>
I would be much happier with a simpler, slightly more imperfect scheme, with less board area and mux lines
<whitequark>
er
<whitequark>
bom lines
<whitequark>
well, mux lines too, i guess
<electronic_eel>
hmm, hearing "slightly more imperfect scheme" from you
<whitequark>
i was thinking using the 1:4 mux for extension boards, and another 1:2 or 1:1 mux to connect the rest of the board
<whitequark>
tying their EN and ~RESET lines together
<whitequark>
so basically you address either the part of the board with our own I2C stuff, or the expansion boards, but not both at once
<whitequark>
this also solves the boot flash I2C address issue
<whitequark>
and only needs one GPIO
<electronic_eel>
why not the 1:8 mux for everything? I'd say that is more compact and easier to control
<whitequark>
using 1:4 mux with dedicated alert lines simplifies the alert logic greatly. it's just four wires.
<electronic_eel>
these 2 double diodes really don't make it more complex
<electronic_eel>
or take up a lot of space
<whitequark>
we don't have any diodes in the BOM, do we
<electronic_eel>
we could repurpose the esd diode used on the sync pin if you really want to save on a bom line
<whitequark>
sigh
<electronic_eel>
but I don't know if that is worth it
<whitequark>
are there really no 8-channel muxes with interrupt logic
<electronic_eel>
no, they just have one register
<electronic_eel>
either 4 pins irq and 4 switching or 8 switching
<whitequark>
oh right, that's why
<whitequark>
looks like there's a maxim chip that does that lol
<electronic_eel>
you considering maxim?
<whitequark>
nope
<whitequark>
absolutely not
<electronic_eel>
ok, so noone took over your nick ;)
<whitequark>
lol
<electronic_eel>
the 4066 mux in my sketch could by completely DNPed without affecting any other function
<whitequark>
what if we use three identical 1:2 muxes
<electronic_eel>
which ones do you suggest?
<whitequark>
pca9542/9543
<whitequark>
those don't have the EN input like i wanted before, so 3 addresses (i think) would be punched through
<electronic_eel>
pca9542 don't have reset
<whitequark>
ohright, 9543 then
<whitequark>
it's not quite as nice as using the 1:4 ones
<electronic_eel>
pca9543 are only available in tssop14, three of them take a lot of space. the TCA9548A is one qfn in 4x4
<electronic_eel>
just to save 4 diodes?
<whitequark>
my original plan would work a bit like uh
<whitequark>
pca9545a+pca9306
<whitequark>
tie EN and ~RESET together
<whitequark>
so by default on boot you'd get the internal bus, and the 1:4 switch will be in reset
<electronic_eel>
yeah, I understand
<whitequark>
now let's compare this to the 1:8 switch
<whitequark>
one benefit of your suggestion is that all 4 ports may be strapped the same way wrt ADC and stuff
<electronic_eel>
but that also is some strange logic and several bom lines
<whitequark>
that's definitely good and i like it
<whitequark>
yes, both of our solutions add 2 bom lines
<electronic_eel>
" all 4 ports may be strapped the same way wrt ADC and stuff" - I don't think that is too important here
<whitequark>
it simplifies both board and software
<whitequark>
firmware, rather
<whitequark>
it's not a major benefit, but i do like it
<electronic_eel>
as I said, it's good, but not a major point
<whitequark>
sure
<whitequark>
one drawback of my pca9545a+pca9306 approach is that if it takes a long time for an addon to respond, the fx2 led will fade
<whitequark>
which is a moderate drawback
<electronic_eel>
ah, if we don't use my 4066 solution, we could still use my ice-led proposal
<whitequark>
mhhh
<whitequark>
we can't backpot it to revC
<whitequark>
backport*
<electronic_eel>
no, but there are free gpios on revc left for the ldo-enable of revD
<whitequark>
we could, however, wire ice-led to cdone directly
<electronic_eel>
prototype my whole suggestion incl. 4066 or just the 8-way switch with diodes?
<whitequark>
including 4066
<whitequark>
i concede that it might not be as risky / complicated as i originally considered it to be
<electronic_eel>
nice
_florent_ has left #glasgow [#glasgow]
<electronic_eel>
I can add it to my protection testbed board I'm planning
<whitequark>
i do admit that i have a bit of a kneejerk reaction to perceived complexity.
<electronic_eel>
just discussing it and thinking over each bit sometimes helps
<electronic_eel>
and I had the same reaction to your pca9545a+pca9306 approach
<electronic_eel>
it's just that if you don't come up with a circuit yourself you have to take a little time to familiarize yourself with it
<whitequark>
well, in this case it was not quite that
<whitequark>
but I realized that my suggestion had drawbacks (different strapping, FX2 LED issue) that made it not an obvious win even under my own conditions
<whitequark>
and given two solutions imperfect in my mind, yours obviously achieves more
<whitequark>
I bet esden would hate us for introducing 3 bom lines for this