_florent_ has quit [Read error: Connection reset by peer]
_florent_ has joined #glasgow
sorear has quit [Ping timeout: 260 seconds]
sorear has joined #glasgow
<d1b2>
<DX-MON> very happy to see the latch logic Just Work today on stream - that was a relief to me
<d1b2>
<DX-MON> it'll be very interesting to disect the resulting output binaries
<d1b2>
<OmniTechnoMancer> Do you know what arch the PnP machine used?
<d1b2>
<DX-MON> I do not
<d1b2>
<DX-MON> and Esden wasn't sure from where in the machine the PROM is from
<d1b2>
<DX-MON> P&P machines tend to run multiple processors, so this is a rather important data point to know
<d1b2>
<OmniTechnoMancer> Ah :/
<d1b2>
<OmniTechnoMancer> Yea
<DX-MON>
on a plus side, I'm willing to bet that the original 3.3V dump and the 5V dump are identical and that the issue we were seeing was with the lack of support for revC2's IO section
<d1b2>
<OmniTechnoMancer> \o/
<DX-MON>
I didn't say the two dumps are.. I said that was my bet on what was up
<d1b2>
<OmniTechnoMancer> That being the issue would be useful
<DX-MON>
oh, agreed
Stormwind_mobile has quit [Ping timeout: 246 seconds]
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
tomtastic has quit [Ping timeout: 256 seconds]
tomtastic_ has joined #glasgow
<d1b2>
<esden> So as far as I can tell the bit DQ2 is "lazy" on my glasgow revC1...
<d1b2>
<esden> and not all the time... just at the times when certain addresses are being accessed
<d1b2>
<esden> So it is almost certainly a "this specific hardware specimen is iffy" issue.
<d1b2>
<esden> Considering that I had a lot of issues assembling revC1 and had to rework pretty much all of them... this is not super surprising... still annoying that it seems to be one bit having issue transitioning from low to high it seems...
<d1b2>
<OmniTechnoMancer> Inconvenient
<tnt>
Did you check the signal shape on the scope ? And resistance to nearby signals ?
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
<d1b2>
<esden> resistence is fine, I do need to hook it up to the oscilloscope. That is the plan for tomorrow. 🙂
Stormwind_mobile has joined #glasgow
<whitequark>
esden: lazy how?
<whitequark>
oh nvm the prom applet
happycube has quit [Ping timeout: 256 seconds]
sambristow_nz[m] has quit [Quit: Idle for 30+ days]
_whitelogger has joined #glasgow
yorick has quit [Ping timeout: 272 seconds]
yorick has joined #glasgow
<lukego>
tnt: I'm coming back to your short-finding method. For the pins where I've detected a short with continuity test (Z0 and Z1 on expansion connector B) I'm reading 0.14ohm on the connector, 0.15ohm on the south side of RN4, and 66ohm on the north side of RN4. So I guess that short is not due to the BGA which is nice. Have to see if I still have my docker container now to try pulling latest glasgow and rerunning selftest
<lukego>
the other connector pins have ~100kOhm between neighbors
<d1b2>
<tnt> Chances are the short is under the ESD protection diode chip.
<d1b2>
<tnt> (long thin chip between RN4 and the connector)
<lukego>
OK. That's actually fine with me for now. I'm mostly concerned about whether the big stuff is working, e.g. FPGA soldered correctly, and for smaller stuff I can just rework it on demand when it gets in the way of practical usage
<lukego>
(I'm assembling this Glasgow initially for practice at PCB assembly and actual use of it will come a bit later)
<whitequark>
what i hope is that i can write good enough manuals (which recommend virtualenv) that people can treat pip etc more or less as a black box until they improve
<whitequark>
i know pypa folks are hard at work improving pip and i think we'll see material improvement, but we're not there yet
<russss>
most language package managers are equally fucked imo
<russss>
although it seems like the python ecosystem is seeing a fair amount of improvement at the moment
<d1b2>
<edbordin> whitequark yep, can't fault your approach. Telling new users to use anything other than pip doesn't seem worth it to me either
<electronic_eel>
hmm, will virtualenv be the default that is recommended in the manual? or is native pip without virtualenv the default and virtualenv the fallback?
<electronic_eel>
i do not like that a lot of manuals you find tell you to use docker,virtualenv,... and that will clutter your whole machine with all kinds of copies of nearly the same stuff over and over
<electronic_eel>
but in most cases these copies aren't covered by the distributions update mechanism, so you often end up with long-out-of-date software, expired x509 certificates,...
<d1b2>
<edbordin> Once you've dealt with enough bugs that can only be solved by using a specific version of a package, I think you tend to be more willing to lose the hdd space and save some of your time...
<d1b2>
<Attie> i see your point @electronic_eel, but i do really like the "disposable" nature of virtualenv and docker - they don't modify your wider system, potentially breaking other things
<electronic_eel>
it is not so much the hdd space that i care about, more the process of keeping all this up to date
<electronic_eel>
i use my distros update mechanism (fedora dnf in my case) and i want it to update nearly everything on my system
<electronic_eel>
these virtualenvs and containers and so on prevent that
<electronic_eel>
so i have to read between the lines of the manual and try to destill what i have to do to make it work without all that
<electronic_eel>
i can fully understand that other people don't want to do it that way and perfer the container approach. but that shouldn't make it harder for people to do it natively
<d1b2>
<Attie> out of interest (using the venv approach) - aside from skipping the "venv setup" and "step in" steps, what do you bump into that needs to be different for a wider system install?
<electronic_eel>
i haven't tried a venv glasgow install. is there still the same "python setup.py develop --user" call?
<d1b2>
<Attie> yeah
<d1b2>
<edbordin> I don't like using downstream python packages from distros, not sure what value it adds when it doesn't need to be coupled to the OS
<d1b2>
<Attie> (my "yeah" was in response to @electronic_eel's q)
<d1b2>
<Attie> i believe that should still work
<d1b2>
<Attie> i suspect there are some things that will require a little more brain power than simply skipping the two steps mentioned above, but i can't think of any off the top of my head...
<d1b2>
<Attie> and the glasgow install is pleasantly simple / painless
<electronic_eel>
Attie: but the stuff will then not be installed into $HOME/.local/bin, but in some env dir, right? so the user has to figure out what to put into their $PATH
<electronic_eel>
edbordin: the distro will make sure that everything they ship still builds and the correct libraries are provided (for everything that is not pure python)
<electronic_eel>
edbordin: also you then just have one system that is responsible for updating everything. consider you have stuff in python, perl, ruby, php,... and each tool brings their own package manager. how do you ensure everything is up to date?
<electronic_eel>
edbordin: and then scale that up to a whole company. how do i ensure that all the servers are up to date with all package managers? that becomes nearly impossible to do if you don't settle on one system and have it report back it's status
<russss>
story of my life, that
<electronic_eel>
hehe
<russss>
Docker looks like an easy solution to this but it effectively multiplies the number of computers you have
<russss>
fractal dependency hell
<electronic_eel>
i think pip works really well in that regard. it recognizes that i have some dependency already installed from distro package and uses that
<electronic_eel>
russss: yeah. you need to have the experience with that kind of problem though and see it coming before you begin to do the "quick docker install" and go one step further down into hell
<russss>
I think containerisation can help, if you do it right, but it's also an easy way to just forget about things for too long
<d1b2>
<edbordin> I get that security is a competing objective but continually updating dependencies on something you just got working is a recipe to make it broken without constant maintenance
<electronic_eel>
i'm not against containers per se, but you have to plan for maintenance from the beginning
* russss
returns to day 2 in the config management mines
<electronic_eel>
edbordin: that is where stable distributions (RHEL, Ubuntu LTS) come in, also you want to have monitoring (icinga, nagios, zabbix,...) for your services. but the latter is of course no solution for a devel tool like glasgow on a workstation
<DX-MON>
electronic_eel: with setup.py/pip in a virtualenv, all executables go in <env>/bin and on running `. <env>/bin/activate`, it's put in your path correctly for you - 2 cost effort. Additionally, you can use the resulting Glasgow installation without needing to activate the env - `<env>/bin/glasgow` is a small python stub that does the env activate within Python and then launches the real program
<DX-MON>
*0 cost effort
<DX-MON>
for the core part of a virtualenv, if you don't want full system isolation because you want it to stay up to date, you can use `--symlink` mode when you create the environment
<DX-MON>
all things you can normally do with setup.py work inside a virtualenv, and all things you can normally do with pip too [though IIRC, --user redirects into the environment)
<electronic_eel>
DX-MON: how does the venv with --symlink setup then differ from doing a "setup.py develop --user"?
<DX-MON>
er.. it has nothing to do with setup.py develop
<electronic_eel>
I mean conceptually, that it is using different tools and paths is clear
<DX-MON>
when you create the virtualenv, you can choose to either have it be a complete and isolated copy of Python and the core libraries.. or you can choose to have it symlink the system ones
<DX-MON>
stuff you do after that step is seperate still
<DX-MON>
during venv setup, you can also choose to allow the environment to see your complete system libraries or not
<DX-MON>
*system Python libraries
<electronic_eel>
ok, but let's say you choose the symlink approach and let it use your system libs, what is the difference does using the venv make?
<DX-MON>
isolation and stability for non-system deps for glasgow
<DX-MON>
and a guarantee that the system package manager won't accidentally munge the installation
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #glasgow
<DX-MON>
with glasgow.. I would suggest outside of NixOS, that docker is not the solution you want as that's more a solution trying to find a problem in this space.. virtualenv is the isolation solution you want specifically because it's cheap and very easily configured without needing root on a box
<DX-MON>
and glasgow doesn't have to do anything special to support it
<DX-MON>
all the support required is already baked into distutils and argo setup.py
<DX-MON>
*ergo
<electronic_eel>
hmm, yeah. if the user is not aware of what the system package manager does and how to detect and prevent problems with that, a venv is probably a good solution. as long as it doesn't become too hard to find out how to do it without
<DX-MON>
the instructions save for making the env itself (1 line) and activating it to alter it (1 line) are identical
<DX-MON>
:)
<russss>
the risk with installing packages directly on system python, rather in a virtualenv, is that you later install another package which installs an incompatible dependency for your first package.
<DX-MON>
when making a glasgow release, you'd `python setup.py bdist_wheel` and upload the resulting .whl to PyPI.. then in the env a user wanting to get Glasgow working in an env with that release `pip install glasgow`'s
<DX-MON>
I really mean that the support for this is already pre-baked into setup.py as it already works this way
<DX-MON>
interestingly, even though I've been using the tools for years I had a major "TIL" yesterday on learning about setup.py's `develop` mode
<electronic_eel>
yeah, the develop mode is nice for quickly changing between branches or testing out new code
<DX-MON>
I'm definitely going to be using that moving on with my own projects
<DX-MON>
er.. moving forward even
<russss>
you can also do that with `pip install -e`
<russss>
there are some very subtle differences between the two
<DX-MON>
the big thing for me with having a setup.py and ergo a .whl build option, is I can use it offline, which is of huge benefit in my world
<DX-MON>
`pip install --no-index -f /path/to/offline/cache <packages>` is <3 when you're stuck on a box that can never be connected to the internet
<electronic_eel>
if all dependencies are already installed by the system package manager then there is no problem with the machine being offline
<DX-MON>
except when the system deps are ancient..
<DX-MON>
and I mean.. decrepidly old to the point it'd horrify you
<electronic_eel>
one more reason for liking system packaging - you can have your local mirror of it all and don't need internet for using it
<DX-MON>
the first thing we often do at $dayJob in relation to anythinig Python is take one look at the system packaging and go "yeahnope", head to pypi, download what we need, move it over and then virtualenv or module it onto the system
<DX-MON>
CentOS 7 and SLES does that to you
<electronic_eel>
you can quickly package up a newer version if you need to and put it into your own repo. you need some mechanism set up to properly manage that though
<DX-MON>
"sure, we can use pip version 9.." >_<
<DX-MON>
RPM packaging is anything other than fast
<electronic_eel>
depends on the experience and tooling you have
<DX-MON>
in my experience packaging things like coreutils, findutils, tar, etc.. while trying to preserve distro patches for compatability.. expect RPM to take weeks or months to get right
<electronic_eel>
rpms are like the glue that holds together a lot of the infrastructure at work, so i'm used to package stuff up and maintain it over years
<DX-MON>
while we can just yank .whl files from PyPI and chuck them in our non-system Python and be done
<DX-MON>
I am looking at this through a HPC sysadmin lense for what it's worth
<electronic_eel>
hmm, do you have to patch coreutils?
<DX-MON>
we do.. because it doesn't handle tape-migrated files correctly and won't maintain extended attributes by default
<DX-MON>
nothing worse than a user running a command that's not migrated file aware and recalling TiB of data from the silos
<DX-MON>
*accidentally
<electronic_eel>
ok, i haven't experienced that specific bug, but maintiaining a patched version of such a core package takes a bit more effort than e.g. add something like a current version of yosys or nmigen
<DX-MON>
ok, true.. however, I also RPM package some of my own programs like crunch and pcat.. and that was honestly a sucky week each trying to get it right - especially in the face of CentOS 8
<electronic_eel>
but in the past i had to maintain some patched kernel package, it took some effort, but in the end it worked out and solved the problem till the patch went upstream
<DX-MON>
sending things upstream is a painful topic with $dayJob because of the nature of the place
<DX-MON>
(I cannot elaborate on that.. so don't ask please)
<electronic_eel>
the only thing that bothers me about Centos 8 is modularity and the build environment necessary to build stuff needing it
<DX-MON>
the thing that bothered me is that it made, among other things, missing debug info for an RPM build a hard error
<electronic_eel>
hmm, you can disable that iirc
<DX-MON>
so you have to do some really dastadly things to generate an optimised build but also get the debug info it wants in a form it wants
<DX-MON>
well, if you'd like to share, my sanity would appreciate that
<electronic_eel>
think there is something similar for the debuginfos too
<electronic_eel>
%define debug_package %{nil}
<DX-MON>
ahhh, awesome
<DX-MON>
I've transcribed that into crunch's .spec for the next time I have to crank the handle on a release
Stormwind_mobile has quit [Ping timeout: 260 seconds]
grymoire has joined #glasgow
happycube has joined #glasgow
happycube has quit [Ping timeout: 272 seconds]
happycube has joined #glasgow
grymoire has quit [Ping timeout: 245 seconds]
lxdr has joined #glasgow
Stormwind_mobile has joined #glasgow
<lukego>
I feel like docker basically solves this problem at least for me. I'll do 'docker build' and I won't care if it's pip or nix or bazel or whatever going on under the hood.
<lukego>
(oops comment arrived late for discussion that already happened about pip)
<whitequark>
lukego: have you read the help text for pins-loop?
<d1b2>
<Attie> @whitequark yeah i think it is, i just misread
<whitequark>
glasgow run selftest --help
<lukego>
whitequark: no, didn't know there was one
Getorix has joined #glasgow
<lukego>
aha okay mine's not setup in a loop so that explains the unhappiness there :)
<d1b2>
<Attie> (see my link above - you'll need to attach a ribbon from A->B to run pins-loop... and a jumper from Vio to Vsense for voltage)
<_whitenotifier-f>
[glasgow] attie commented on issue #151: False positive results in selftest - https://git.io/JTAt5
<_whitenotifier-f>
[glasgow] whitequark commented on issue #151: Selftest is not supported on revC - https://git.io/JTAqs
<lukego>
I don't have such a cable at the moment, and I've also damaged the plastic of those connectors on my board, so I think I'll classify this board as "completed with minor imperfections" :) and start designing something to use it on...
happycube has quit [Ping timeout: 240 seconds]
<lukego>
Thank you very much everybody for the help!
<d1b2>
<Attie> you can just use standard 0.1" jumper wires from the A[0:7] -> B[0:7] pins if you have them
<d1b2>
<Attie> but well done 🙂
happycube has joined #glasgow
<lukego>
thank you I appreciate that :)
<lukego>
I guess you needn't hook up the ground pins in loopback mode either
<d1b2>
<Attie> correct
<d1b2>
<Attie> (it's just one board, with one ground plane)
balrog has quit [Ping timeout: 240 seconds]
balrog has joined #glasgow
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #223: hardware: Add 3D printed case lid - https://git.io/JTA3f
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JTA3a
<Lofty>
Open hardware in a nutshell: hey can somebody sell me the board I designed?
<d1b2>
<Attie> half wondering if i should do another run...
<whitequark>
maybe, but i'm going to request delivery outside EU again...
<whitequark>
lofty: also it's more than just me
<d1b2>
<Attie> it's tempting, and i think there's certainly interest... but i'm not sure i will at the moment
<Lofty>
Sure, but it never stops being funny to me
<whitequark>
electronic_eel: speaking of which, do you maybe want to edit your part of the acknowledgement section in README? i think it's no longer accurate
<electronic_eel>
if it were just one board, you could maybe ask esden to send you one more of his revC2 prototypes
<whitequark>
these are all boards for other people i know
<whitequark>
so actually revC1 is better
<whitequark>
since there are no known bugs in C1
<electronic_eel>
yeah, revC2 isn't fully usable until i've finished the firmware
<whitequark>
i can help out with that once i get my boards from esden
<whitequark>
i still owe you some i2c stuff
<electronic_eel>
oh yeah, the internal i2c will be needed for the test jig
<electronic_eel>
i'd prefer if you'd work on that and i'll take care of supporting the new adc
<whitequark>
works for me
<whitequark>
do you like 8051 C? :)
<electronic_eel>
my reasoning is that you will want to design the protocol for controlling the internal i2c and there would be lot's of back and forth if i develop that part
<whitequark>
whereas the new ADC already has a protocol?
<electronic_eel>
first step is getting feature parity with revC1, so the protocol will stay the same
<whitequark>
(i.e. the existing ADC-related requests it has to conform to)
<whitequark>
if you want you can add current-limit commands and requests, basically just copy whatever voltage-limit does
<electronic_eel>
yeah, i think the current limit and query commands can be copied pretty much without change from voltage, so not much to discuss
<electronic_eel>
whitequark: re ack section, how about "@electronic_eel improved the hardware for revC2, designed the test jig and is working on advanced protection circuitry"
<whitequark>
sure, sounds accurate to me
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to master [+0/-0/±1] https://git.io/JTAZQ
<whitequark>
ideally non-preview applets which you can test, but really anything goes
<d1b2>
<Attie> ah, thanks for making that... i was going to take a look if it existed later, and create it if not
<d1b2>
<Attie> i'm probably up for ws2812 / uart / spi / i2c, so if others have access to other hardware for testing, feel free to prioritise accordingly
<d1b2>
<Attie> can probably manage vga / ps2 as well, and perhaps some others
<whitequark>
sounds perfect, esp ws2812 one
<d1b2>
<Attie> hoping to get a bit of time in the next few hours
<miek>
cool, yeah i can help chip away at some of those
<d1b2>
<Attie> cool - i've got some ws2812 LEDs handy, so i'll put that at the top of my list
<whitequark>
so here's something i was wondering about
<whitequark>
electronic_eel: do you think I2C with parasitic power is a sane idea?
<whitequark>
for something like a 256K EEPROM
<hl>
...so basically 1-wire except 2-wire?
<whitequark>
yes
<whitequark>
it is obviously *possible* because, well, these EEPROMs pretty much always work (for reads) without Vdd
<hl>
I mean... any reason to do it? If you want it, just use a 1-wire part?
<whitequark>
what's going to drive that?
<hl>
hm?
<whitequark>
well. we ran out of GPIOs. but not out of I2C.
<whitequark>
(it's also necessary to have per-port bus isolation)
<hl>
sorry, what's the context here? haven't been paying attention
<whitequark>
glasgow.
<hl>
right, but what are you trying to do
<whitequark>
small EEPROMs on addons that would identify the connected addon and free you from having to enter pins manually
<hl>
aahhh
<hl>
yes, that would be nice
<whitequark>
thing is, i dedicated 2 last pins on the shrouded connectors for that task
<hl>
and you don't want to consume any of the level-shifted pins?
<whitequark>
back during revA
<whitequark>
i can't
<whitequark>
because addons must be identifiable before you apply voltage to them.
<hl>
aah.
<whitequark>
otherwise, how do you know that it's safe
<hl>
okay, so you're out of GPIOs on the FX2?
<whitequark>
essentially yes
<hl>
what about the FPGA?
<whitequark>
essentially the same
<hl>
huh, really? aren't you scrapping LVDS?
<whitequark>
plus, addons should be identifiable without FPGA bitstream anyway
<hl>
yeah, what I was going to suggest is you load a temporary bitstream just to do ID. it's horrible but
<hl>
(or make it a standard function of all bitstreams)
<whitequark>
ok well
<whitequark>
this is strictly speaking possible but i try to keep BMC functions and protocol conversion functions strictly separate
<hl>
anyway, this parasitic power I2C idea sounds interesting
<whitequark>
it's a 24C01 and a schottky
<hl>
yeah, it's something you'd only want to do if you had no alternative
<whitequark>
and a cap i guess
<gruetzkopf>
hm. for many parts, body diodes are enough
<whitequark>
well yes you could skip the cap too if you are feeling lucky
<hl>
i mean, if it works, honestly go for it. Probably you'd have to have a qualification list of tested EEPROMs addons are required to use
<gruetzkopf>
i mean skip the schottky
<whitequark>
yes, i understood
<whitequark>
i mean that not even the cap is absolutely necessary
<hl>
will the addon I2C be isolated from FX2 I2C somehow?
<whitequark>
yes, it would have to be, since if you jam the internal I2C bus, all sort of thing goes wrong
<hl>
right, exactly
<whitequark>
not protection as of revC2
<whitequark>
but USB requests will hang randomly, you wouldn't be able to actually run any applet because they are reset via I2C, etc
<whitequark>
because of this (and also because it's necessary to relieve address space congestion), revD would feature one of those 8-port I2C switches
<hl>
so these I2C switches literally work by turning on a transistor gating the secondary bus, right?
<whitequark>
we'll scrape the bottom of the schematic for one last GPIO and connect that to the hardware ~RESET line of the switch, because otherwise you have like 8x the possible faults
<whitequark>
yeah, the vast majority of them uses pass transistors
<hl>
....could you reuse FX2_SDA as bitbanged 1-wire connected to the addon pins? >_>
<hl>
via one of the switch ports
<d1b2>
<icb> What about an I2C to 1-wire bridge chip?
<whitequark>
it cannot be bitbanged
<hl>
oh, can the FX2_I2C not be configured as GPIO? damn
<whitequark>
hard I2C only
<hl>
right
<whitequark>
icb: well, yes, obviously a possibility
<whitequark>
two issues with it
nicoo has quit [Ping timeout: 240 seconds]
<whitequark>
1: it takes space (and cost) and we already don't have that much, especially after the added i2c switch
<d1b2>
<icb> It's an additional part, and single-source, which isn't great
<whitequark>
2: it is still necessary to isolate faults between individual addon boards, so you need either 4 or some other analog mux
<whitequark>
actually, yes
<whitequark>
3: 1-wire ecosystem is... what? still alive? you don't really hear much of them these days
<whitequark>
meanwhile i2c has an infinite number of parts that will never go out of production, like any properly awful bus
<whitequark>
you could obviously put an attiny there as a protocol converter but ehhhhhh one more thing to program, it won't be programmable via USB (no GPIOs for that)
<whitequark>
plus one MCU is an ideal number of MCUs on a glasgow board
<whitequark>
we'll *definitely* have an auxiliary power connector on future revs because electronic_eel has made an extremely compelling case that we need it
<whitequark>
i think the question is basically: do we have i2c on the aux connector as well, or do we have i2c on the extra pins on shrouded connectors, intended to be used in most cases with parasitic power?
<d1b2>
<esden> I like the idea of using the i2c on the extra pins of the shrouded connectors. The upcoming aluminium cases would still mechanically work for those boards then. Essentially giving it bit more runway...
<whitequark>
yes, basically that's the idea
<d1b2>
<esden> not sure yet how the aux power connector would work mechanically...
<whitequark>
use the pins for their original intended purpose and make existing cases work, also allow addons on a ribbon cable
<d1b2>
<esden> Will it be a thing one uses a jumper wire with?
<whitequark>
i don't know yet
<hl>
What's the aux power connector for?
<whitequark>
5V and 3.3V for auxiliary addon logic, plus Vio reference ADC output for advanced protection addon
<d1b2>
<esden> The alternative for aux power would be to have some kind of a transistor to switch it onto the remaining two pins after the parasitic i2c detection is done... but considering we already have "pinout shortage" this might not be feasible...
<whitequark>
uhhh
<whitequark>
that's unsafe
<whitequark>
or rather, not intrinsically safe
<hl>
BTW, if you go with this solution, would it be possible to have an addon that powers other I2C devices on the I2C bus (other than the EEPROM) from Vio once it's turned on?
<whitequark>
the 2 things this has to be intrinsically safe against are: 1) people wiring a EEPROM in the simplest possible way ie hanging it off SDA/SCL without any of our recommended coupling, 2) connecting the shrouded connector to an ARM debugging target with a 20-pin connector
<whitequark>
(1) is solved by having normal 3V3 levels on the exposed I2C bus and nothing else
<d1b2>
<esden> I was thinking the aux power would only come on in very specific situations.
nicoo has joined #glasgow
<d1b2>
<esden> When the target announces it needs it essentially, or the user forces it on through the applet in some way.
<whitequark>
(2) is solved by that + making sure the I2C bus predictably hangs when you plug it into an ARM target
<hl>
also, you say you're going to scavenge a last GPIO from the FX2 somehow for an I2C reset. Couldn't you also use that as a 1-wire pin? (the idea here is, while you're using 1-wire, you're not performing an i2c transaction and don't care about resetting things)
<d1b2>
<esden> It won't automatically come on without knowing exactly what the situation is.
<whitequark>
esden: i think we don't have enough pins in the *connector* for that
<whitequark>
since electronic_eel needs a minimum of 3. 3.3V, 5V, Vref
<d1b2>
<esden> ohh all of the voltages at once? ... I see...
<d1b2>
<esden> I thought they could be selected...
<d1b2>
<esden> then two pins would be enough
<whitequark>
we can't realistically ditch 3.3V (it gets turned off during board reset), 5V (it provides a lot more current), or Vref (that would make advanced protection addon impossible
<whitequark>
like, this is even assuming we somehow manage to add a complicated high(ish) voltage high(ish) current mux on the tiny board
<whitequark>
hl: re addon that powers other devices on I2C bus: as long as they have true open drain IO without ESD structures, yes
<whitequark>
*high-side ESD structures
<d1b2>
<esden> @whitequark mhh... ok, it is not an easy problem to solve... just adding a connector somewhere with all three voltages connected permanently, is probably the easiest thing to do.
<d1b2>
<esden> regarding board space... it is still only a 4 layer board with mostly one side load 😉 😛
<whitequark>
hl: re bitbanging 1-wire from that pin: no, not really. this doesn't provide addon-granularity fault isolation
<whitequark>
you'd then need an i2c analog mux or something
<hl>
ah, right
<whitequark>
which may seem like overkill but do you *like* debugging i2c issues without even having a clear indication of where they are located?
<whitequark>
well or 1-wire issues, same general sort of problem if you have an electrical issue