ExeciN has quit [Quit: so long king Bowser]
futarisIRCcloud has joined #glasgow
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?
Ekho- has joined #glasgow
plaes_ has joined #glasgow
yuriks has quit [*.net *.split]
spacekookie has quit [*.net *.split]
ec0 has quit [*.net *.split]
hthh has quit [*.net *.split]
superbaloo has quit [*.net *.split]
asy has quit [*.net *.split]
zeiris` has quit [*.net *.split]
plaes has quit [*.net *.split]
Ekho has quit [*.net *.split]
parataxis has quit [Ping timeout: 240 seconds]
yuriks has joined #glasgow
zeiris` has joined #glasgow
hthh has joined #glasgow
asy has joined #glasgow
ec0 has joined #glasgow
spacekookie has joined #glasgow
superbaloo has joined #glasgow
thaytan has quit [Ping timeout: 268 seconds]
thaytan has joined #glasgow
fibmod has quit [Ping timeout: 260 seconds]
fibmod has joined #glasgow
Neil_ has joined #glasgow
Neil_ has left #glasgow ["The Lounge - https://thelounge.github.io"]
pg12 has quit [Ping timeout: 252 seconds]
pg12 has joined #glasgow
simukis__ has joined #glasgow
<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> which sounds horrifying actually
<whitequark> for pure ID we can do this: https://www.st.com/resource/en/datasheet/m34e04.pdf
<whitequark> smbus eeprom
<whitequark> 0.34€@1
<whitequark> there are also GPIO expanders with smbus and integrated eeprom
<whitequark> for backplane applications apparently
<whitequark> ie exactly this kind of problem
<electronic_eel> so even if this has slave address pins SA0-2 it does not use fixed addresses?
<whitequark> hang on
<whitequark> nevermind, I should not skim these things
<whitequark> both of those are not actual smbus
<whitequark> it's just a normal EEPROM with an smbus-themed datasheet
<electronic_eel> hmm, seems like not many devices implement this smbus address resolution protocol
<whitequark> yeah
<whitequark> urgh
<whitequark> I kind of see why SYZYGY went with a microcontroller now
<whitequark> I hate it, and yet, they have a point
<electronic_eel> but if you have a microcontroller, I'd probably not use i2c/smbus, but a uart bus with open collector
<whitequark> hmwe can't afford
<whitequark> *hm
<whitequark> can we afford that pin-wise?
<whitequark> was the plan to use AUX?
<whitequark> or hook things up to internal bus?
<electronic_eel> a uart bus just needs one pin
<whitequark> I think we were going with an I2C switch and an internal bus
<whitequark> yeah but I don't think we have one pin
<electronic_eel> I think the problem is more like the fx2 doesn't have uart-hw
<whitequark> all pins on the FX2 are allocated on revD, and not being able to use addons with no bitstream is a pain
<whitequark> well, it doesn't, but it's not that bad
<whitequark> I have a software UART for it
<electronic_eel> there are i2c<->uart adapters available
<whitequark> ugh.
<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
<gruetzkopf> (like PC104 uses)
<whitequark> electronic_eel's protection boards needs DACs
<electronic_eel> the protection addon probably wouldn't need an eeprom or id at all
<whitequark> to set bias voltage or something
<gruetzkopf> (but their solution was "none" or "ISAPNP", which are both bad
<whitequark> can we not talk about ISAPNP in the year 2020.
<whitequark> this is just rude gruetzkopf.
<electronic_eel> I think we decided to provide the dac output for that
<whitequark> (joking, joking)
<whitequark> hmm
<whitequark> that strikes me as inelegant but if past wq agreed to it that means there were good reasons
<whitequark> awygle: we already are going to
<whitequark> kind of have to
<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
<awygle> arright i'll shut up now
emily has quit [Quit: Updating details, brb]
<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
<q3k> glasgow.engineering _and_ glasgow.engineer
<q3k> https://iwantmyname.com/?domain=glasgow (known to not snipe your domains)
<whitequark> glasgow.engineering seems like there's a lot of better contenders
<whitequark> glasgow.cards seems fine tho
<whitequark> even glasgow-cards.org, except .org went down the drain recently so eh
<q3k> myeah
* q3k stares at q3k.org
<whitequark> i renewed for 10y i think
<gruetzkopf> should also push out gruetzkopf.org
* gruetzkopf goes off to message registrar on icq
<whitequark> icq
<whitequark> what decade are you living in again
<whitequark> does that still exist and if yes why
<whitequark> i remember having a 6-digit icq number. i do not remember what the number was and there are no traces of the account left
<_whitenotifier-5> [glasgow] electroniceel commented on issue #169: revD minispec - https://git.io/JvTF2
<_whitenotifier-5> [glasgow] whitequark commented on issue #169: revD minispec - https://git.io/JvTFV
<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?
<whitequark> electronic_eel: yup
<electronic_eel> would you also mind to take a look at https://github.com/GlasgowEmbedded/glasgow/pull/159
<whitequark> ugh I totally forgot, sorry
<whitequark> sure
<electronic_eel> thanks
<electronic_eel> when you are finished with the i2c stuff, I'll continue with the test jig code
Stormwind_mobile has quit [Ping timeout: 240 seconds]
Stormwind_mobile has joined #glasgow
<q3k> speaking of which, i really need to manufacture myself a glasgow
<q3k> mwk lent me heirs for a few moments at 36c3 and it was pretty neat
<q3k> *hers
<whitequark> nice :3
<gruetzkopf> q3k: count me in
<q3k> gruetzkopf: aight, didn't even do the maths on the BOM yet tho
<q3k> gruetzkopf: aisler PCBs are 25eur a pop
<q3k> gruetzkopf: jlcpcb PCBs are 5 eur a pop
<gruetzkopf> i might have some aisler rebate codes somewhere (or i could just walk there and poke them)
<gruetzkopf> yeah JLCPCB perf/€ is absurd
<q3k> @20 it dips to <2eur/pcb
<q3k> it's annoyingly cheap
<q3k> with ENIG it's 2.5 eur/pcb @20
<whitequark> don't worry you're going to go broke on the MLCCs
<gruetzkopf> i've recently bough like full 3U 19" backplanes off them for <10€/pop (4l)