Yatekii has quit [Remote host closed the connection]
Yatekii has joined #glasgow
<whitequark>
marcan: poke
<marcan>
whitequark: peek
<whitequark>
marcan: what's the house moving status
<whitequark>
I can probably do the footprints myself at this point because I had to page the kicad knowledge back in
<whitequark>
there's other things though like revD and I was wondering about your availability
<marcan>
whitequark: amusingly enough still not finished due to Other Stuff taking over december completely, but I'm literally cleaning right now and would like to make progress this weekend
<marcan>
I am... not exactly running short on things to do for the next couple of months, but at least I'm no longer in panic mode, at least right now.
<marcan>
let me see how progress looks
<marcan>
feel free to poke me periodically, that's how you're going to get me to find some downtime/time I feel like it to do it
<whitequark>
alright. it's kind of frustrating to do this week after week and always get the same answer though
<whitequark>
hm, speaking of which
<whitequark>
electronic_eel: I haven't heard from you for a while--what was the last thing you were working on, the analog mux for the alerts? is there anything I can do to help you here?
<simukis__>
Q: how arbitrary are the voltages that glasgow supports for its pins?
<gruetzkopf>
1.8V to 5V (seperate for each group of 8 pins)
<simukis__>
thanks
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #glasgow
bvernoux has joined #glasgow
parataxis has joined #glasgow
<electronic_eel>
whitequark: last thing I was working on was accessing the internal i2c from applets, that will be needed for the test jig board
<whitequark>
ohh, do you want me to just handle that?
<whitequark>
it's very little work that I keep putting off for some stupid reason
<electronic_eel>
I had begun to think up a design for it, but then we needed to move to another office space at work, that took like 3 month or so and my desk is still a bit buried in boxes...
<electronic_eel>
but I have no problem if you develop this interface
<whitequark>
sure, I know exactly how I want to do it
<whitequark>
and someone else wanted it
<electronic_eel>
I think you'll use control transfers, correct?
<electronic_eel>
do you want to allow just one read or write per control transfer, or will you be able to send a bunch of i2c transactions in one control transfer?
<electronic_eel>
I think it would make sense to have an i2c address scan for the internal i2c, for scanning for addon boards.
<electronic_eel>
one way to do that is purely from python, but you'd want pipelined i2c transactions for that
<whitequark>
the idea was to make a tiny protocol that allows chaining together a bunch of transactions; either using repeated start or stop between
<whitequark>
a bit like what Linux has
<whitequark>
well, it's just an iovec
<whitequark>
conceptually
<whitequark>
it's not actually hard to implement and it makes devices that mandate repstart (eg EEPROM writes) work correctly
<whitequark>
er
<whitequark>
or was that someone else? doesn't matter, I know some devices require using chained transactions with repstart
<electronic_eel>
yes, I think some way to chain transactions together makes sense
<electronic_eel>
should there be a simple control language? like abort the rest of the commands if the device sends a NACK?
<whitequark>
should the rest of the chain be *not* aborted?
<whitequark>
ever?
<electronic_eel>
the i2c address scan should just continue until one device answers
<electronic_eel>
or maybe you repeat some commands until the device is ready?
<electronic_eel>
or am I thinking too far ahead here?
<whitequark>
I'm not very sure if we should even do a scan at all; maybe an ID EEPROM would be more appropriate?
<whitequark>
I need to think more about it and I don't want to commit to a sequential wide scan yet
<electronic_eel>
ok, I just think the i2c access protocol should be designed in a way that we can later add such stuff without worries
<whitequark>
there's no problem with adding a dedicated scan command for example.
<electronic_eel>
ID EEPROMs have the problem that you can't easily stack them without address clashes
<whitequark>
yes
<electronic_eel>
and I think stacking addons makes sense
<whitequark>
well, it seems desirable to some extent
<whitequark>
hmm
<whitequark>
we could use SMBus
<whitequark>
that doesn't have fixed addressing
<electronic_eel>
do regular eeproms work in this mode?
<whitequark>
generally not
<whitequark>
this would require investigating whether it'll solve more problems than it introduces
<electronic_eel>
that would mean always using a microcontroller
<whitequark>
just saying that it is one solution to this general problem
<electronic_eel>
ok, we don't need to solve this right now
<electronic_eel>
scan is a bit special, so it could be done by the fx2 and have it's own command
<whitequark>
one thing about i2c on addons is that even if you avoid collisions on ID pin you still have collisions on, well, actual addon stuff
<whitequark>
I think you need some sort of daisy chainable i2c
<whitequark>
i know of them, and i don't like it a lot more than using i2c directly
<whitequark>
what about something like, mm
<whitequark>
you can't stack addons more than 2 or 4 high, and we route the I2C address pin(s) such that the boards end up with geographical addresses?
<whitequark>
eg the first board has A0 shorted to GND, the second has it on VCC
<whitequark>
doing A[0:1] is probably impractical, and the limit of 2 stacked addons seems fair
<electronic_eel>
2 stacked addons seems to be enough for me
<whitequark>
this means you can just route that A0 to every I2C chip you use
<whitequark>
it's dead simple, and I think it's good enough for most applications
<whitequark>
no protocol converters, no MCUs, just one inverter
<electronic_eel>
but how do the geographical address pins get to the correct addons?
<whitequark>
let's backtrack a bit
<whitequark>
what I remember is that we agreed to route the internal I2C bus to the 4 sets of INA chips, and 4 sets of addon I2C headers
<whitequark>
INA chips, DAC/ADC pairs, GPIO extenders
<electronic_eel>
yes
<whitequark>
ok, so the stackable addon connects to glasgow on the bottom, and has the same connector as glasgow on top
<electronic_eel>
so each port has it's own separated i2c bus
<whitequark>
we pick whatever pin is convenient to be connected to GND on glasgow, and addons will connect that pin to VCC
<whitequark>
this means that on the bottom addon, it will be 0, and on the top addon, it will be 1
<whitequark>
(scaling beyond 2 would need active logic, but 2 seems just fine)
<electronic_eel>
ok, so stackable boards won't be able to use stacking connectors, but have to provide dedicated input and output pins
<whitequark>
would they not?
<whitequark>
I'm not sure what you mean here
<electronic_eel>
IIRC samtec has some pin header connectors that are female on the bottom and male on top
<whitequark>
errr
<whitequark>
link?
<electronic_eel>
I hate the samtec website, lost my way there several times
<whitequark>
I don't quite see how that works, and also it sounds super expensive, but I want to understand this option better
<whitequark>
well
<whitequark>
if you want to use them you gotta find them at some point :P
<electronic_eel>
;)
<gruetzkopf>
easily fixed by SMT connectors?
<whitequark>
^ also that
<whitequark>
they're not as mechanically sound, it's true
<whitequark>
but I think electronic_eel's addon is pretty much intended to stay on forever
<whitequark>
the one that goes in the middle
<electronic_eel>
right, could be solved by smt connectors
<electronic_eel>
but my protection addon wouldn't be able to use these kinds of connectors
<electronic_eel>
I can't drain 30V, I need to block it
<whitequark>
these = smt ones? passthrough ones?
<electronic_eel>
so it needs separated inputs and outputs
<whitequark>
ok so no passthrough
<electronic_eel>
yes, no passthrough
<whitequark>
didn't you also have an analog addon?
<gruetzkopf>
SMT connector on top and bottom is feasible there
<whitequark>
is that the 2nd one in the stack?
<electronic_eel>
the analog addon idea I had would uses muxes, so that could use passthrough
<whitequark>
oh I'm just thinking addressing-wise
<awygle>
are you talking about I2C EEPROMs living on addon boards (like e.g. beaglebone capes) and how to avoid address collisions?
<electronic_eel>
awygle: yes
<whitequark>
not just EEPROMs
<gruetzkopf>
and yeah, stackable THT would provide more stability
<whitequark>
for revD we can't stuff all the DACs on the same internal bus because of collision
<whitequark>
with the boot EEPROM
<electronic_eel>
the 8way i2c-switch is designed to go on the glasgow revD
<electronic_eel>
or are you suggesting to put the i2c switch on each addon?
<awygle>
if you mandated one per addon board, you could daisy chain them. you end up with a hilariously deep and unbalanced address tree tho
<awygle>
yes, that was my suggestion
<whitequark>
I thought about it
<whitequark>
my view is that it's cursed as fuck
<awygle>
oh undeniably
<gruetzkopf>
very much this
<whitequark>
there are 1:2 I2C switches
<awygle>
but it does work, i've seen it used
<whitequark>
that are less bad than 1:8 ones for this
<gruetzkopf>
i mean how deep would one scan
<awygle>
sure, you'd use 1:N where N is chosen based on how many devices you have on your addon
<electronic_eel>
gruetzkopf: till stackoverflow?
<whitequark>
hm
<whitequark>
how do you daisy chain 3 of those then?
<whitequark>
dedicate the 7th output to "next PCA"?
<awygle>
yep
<electronic_eel>
the i2c switch itself needs an address too. and that is always on the bus. so we avoid addr clashes of the eeproms. but have clashes of the switches instead
<whitequark>
yeah that
<whitequark>
I think you can uh
<awygle>
you can swizzle three bits
<whitequark>
yeah but how?
<whitequark>
I mean
<whitequark>
how is this any better than swizzling three bits without a PCA?
<electronic_eel>
i2c gpio extender ;)
<whitequark>
most I2C devices have at least 2 address bits
<whitequark>
ghhh NO
<gruetzkopf>
don't make us end up with the PCI IRQ "solution"
<awygle>
"most" but not all
<awygle>
(currently dealing with one which does not)
<awygle>
anyway not really a _suggestion_, just an option to put on the table
<whitequark>
then you'd add a switch, yeah
<whitequark>
I just mean that this doesn't free us from swizzling address bits
<whitequark>
which was my suggestion
<awygle>
it makes the swizzling more uniform, basically
<whitequark>
and yours is just a (valid) extension of it, in the sense of being more annoying
<whitequark>
at some point addons become mostly I2C junk
<awygle>
very true
<whitequark>
and I2C is frankly quite bad enough as it is
<whitequark>
you don't have to goose it up
<awygle>
use CAN instead :p
* whitequark
slaps awygle around a bit with a large trout
<awygle>
CAN is good! (not in this application at all, but it's good)
<whitequark>
yeah I'm not complaining about CAN in general
<whitequark>
if only because I never used it
* whitequark
← does not drive, does not have a license, never sat in the driver seat of a car
<electronic_eel>
these are like field busses, always need some kind of transceiver. this is a bit overkill for addons I think
emily has joined #glasgow
<awygle>
LIN is just UART
<awygle>
but they don't make LIN EEPROMs, sadly
<electronic_eel>
open-collector uart bus was what I suggested before.
<electronic_eel>
the problem is also that we don't have enough free pins to drive it on the fx2
<awygle>
> <electronic_eel> i2c gpio extender ;)
<electronic_eel>
not for software uart
* awygle
closes irc, goes back to Actual Work
<whitequark>
heh
<electronic_eel>
but we could move the leds to a gpio extender
<whitequark>
are there good arguments against what I suggested?
<whitequark>
swizzling exactly 1 pin in a passive way
<electronic_eel>
I think i2c with one address pin swizzled is ok
<electronic_eel>
still allows to make a simple addon with just one extra ic
<whitequark>
hm
<whitequark>
so we can clearly reserve one EEPROM address per addon, using the swizzling
<whitequark>
but there's a possible issue where if you use anything beyond the ID EEPROM, then if you're unlucky, the top addon's address on chip A would conflict with the bottom addon's address on chip B
<whitequark>
depending on assignemtn
<electronic_eel>
yes, was just thinking about the same thing
<whitequark>
so I think we should mandate that an addon uses an I2C EEPROM *or* an I2C EEPROM plus I2C mux
<whitequark>
which I think they make as a single chip so it's actually not any worse package wise
<gruetzkopf>
(or nothing at all and not touch swizzling if not needed?)
<gruetzkopf>
(in the "passive protection" case)
<whitequark>
yes
<electronic_eel>
the i2c mux would also use the swizzled address?
<whitequark>
yes
<whitequark>
the muxes and eeproms have well defined addresses
<whitequark>
that I think other ICs avoid, generally
<whitequark>
I would fucking hope they avoid those
<whitequark>
well, the DACs clash with EEPROMs, because clearly the DAC is a kind of memory device
<whitequark>
but at least the DACs have enough address choices you can sort of avoid that most of the time
<electronic_eel>
we need to specifiy small eeproms, the larger ones need more address space
<whitequark>
uh
<whitequark>
yes of course we need to specify <64K EEPROM
<whitequark>
what is the purpose of having >64K of ID info?!
<whitequark>
you could stuff JSON in there and still not hit 64K
<electronic_eel>
memory addon ;)
<whitequark>
in fact i think we could just as well stuff JSON into them
<whitequark>
or something equally stupid and easy to poke
<whitequark>
well ok not JSON because it'll make q3k very sad
<davidc__>
You might be able to hide the EEPROM + other circuitry behind an I2C switch
q3k has joined #glasgow
<q3k>
whitequark: i am now :)
<whitequark>
we don't want to hide the ID EEPROM
<whitequark>
q3k: we just discussed something that involved stuffing JSON into ID EEPROMs
<davidc__>
whitequark: Well, you just enable the switch, then read the ID EEPROM
<whitequark>
and then I remembered it'll make you very sad, and decided to not do that
<whitequark>
davidc__: yeah but it means you can't make a muxless addon that is ID-only
<q3k>
whitequark: i uh
<sorear>
you could use XML
<q3k>
whitequark: 'i'm not sad, just disappointed'?
<whitequark>
I was just thinking that having human-readable data in EEPROMs is sort of neat from usability perspective
<whitequark>
because it lets you to probe a random board and have it identify itself immediately
<whitequark>
*monkey paw curls* toml in ID EEPROMs
<q3k>
human readable for what?
<q3k>
i mean, if you ahve some sort of complex binary structure
<whitequark>
glasgow addon board self-description
<q3k>
that also includes some identifiable string
<q3k>
that can be read in a hexdump
<q3k>
then that's also okay?
<whitequark>
i'm not actually sure yet what those descriptions should include besides an unique global identifier
<q3k>
not sure what you're actually trying to achieve here
<whitequark>
but it should be at least that
<whitequark>
maybe it's fine to leave it at that
<q3k>
i mean, i really don't see the appeal of the human-readable part that much
<q3k>
i think a decent binary format with a known schema (flatbuffers?) with a string that lets you google and find this schema
<whitequark>
i might just be wrong about it
<q3k>
should be good enough
<q3k>
so that if you xxd it, you see glasgow.org/addon-schema
<q3k>
you go there, and you get docs there
<whitequark>
yeah that seems basically fine to have that as a magic value
<whitequark>
huh, glasgow.org isn't registered, it's parked by tucows
<whitequark>
er
<whitequark>
no it's some bullshit service that's only a notch better than parking
<whitequark>
i guess
<q3k>
you can call them 'glasgow cards' and get glasgow.cards
<whitequark>
heh, could work
<q3k>
plenty of weird ass gtlds for which glasgow.<tld> is free
<electronic_eel>
some youngster might ask us the decade question about our usage of irc
<whitequark>
IRC is proprietary though
<whitequark>
I'm surprised that whatever country owns it right now still exists, mostly
<whitequark>
and still hasn't shut it down as a money sink
<whitequark>
company* not country
<electronic_eel>
owns irc?
<whitequark>
er
<whitequark>
owns ICQ
<whitequark>
I can't type this evening
<electronic_eel>
icq, does that still exist? or is it just the brand, reused for something else?
<gruetzkopf>
it's still OSCAR based even
<whitequark>
did ... did rambler buy it?
<whitequark>
i forget
<whitequark>
oh, mail.ru group
<whitequark>
ok so mail.ru still owns it
<electronic_eel>
they have https://github.com/mail-ru-im/im-desktop, but there is "Download external libraries and extract it to ./external folder.". The external.7z seems to have a bunch of binary libs in it
<whitequark>
they're also in cahoots with the feds so it's not like that even matters a lot
<electronic_eel>
whitequark: so you take care of the internal i2c access code?