08:16 <_whitenotifier-3> [glasgow] whitequark reviewed pull request #649 commit - https://github.com/GlasgowEmbedded/glasgow/pull/649#discussion_r1694169757

08:17 <_whitenotifier-3> [glasgow] whitequark reviewed pull request #649 commit - https://github.com/GlasgowEmbedded/glasgow/pull/649#discussion_r1694170316

08:18 <_whitenotifier-3> [glasgow] whitequark commented on pull request #649: Isabelburgos/spi controller applets padless - https://github.com/GlasgowEmbedded/glasgow/pull/649#issuecomment-2254390241

14:20 <whitequark[m]> purdeaandrei (@_discord_693328004947902465:catircservices.org) nobody is working on it afaik. to fix it you'd basically need to build a capacitance meter

14:25 <purdeaandrei[m]> I'm thinking one thing that could be done would be to read the status of the data lines through the pull-up/down gpio expander

14:26 <purdeaandrei[m]> Why capacitance meter though?

14:37 <whitequark[m]> tells you if something's likely to be short or open

14:38 <whitequark[m]> gpio expander would also work

14:39 <whitequark[m]> i'm not sure how to do the accesses though; the available space in the firmware is very tight, but also the i2c port doesn't do multi-master communication

14:39 <whitequark[m]> * also the fx2's i2c port

14:39 <whitequark[m]> or maybe it does and then we're fine

14:39 <purdeaandrei[m]> oh, so we can't master from the FPGA

14:39 <whitequark[m]> i think you should check the FX2's datasheet tbh

14:40 <whitequark[m]> but i seem to recall it doesn't do that

15:36 <purdeaandrei[m]> Looks like it supports multi-master arbitration, but only cancels the current transfer, the hardware doesn't retry on it's own, and libfx2 doesn't seem to implement retries

15:36 <whitequark[cis]> ah, i think that's fine then

15:37 <whitequark[cis]> the transfers will just fail and this will percolate to the toplevel

15:37 <whitequark[m]> ah, i think that's fine then; the transfers will just fail and this will percolate to the toplevel

15:37 <whitequark[m]> selftest isn't normal operation so we should be able to ensure the transfers don't collide, on a one-off basis

16:46 <purdeaandrei[m]> this is the right place for look at firmware memory usage right?

16:47 <purdeaandrei[m]> build/glasgow.mem

16:47 <purdeaandrei[m]> looks like there's 1756 bytes left

16:48 <purdeaandrei[m]> my initial implementation consumed 92 bytes, but then I did a bit of optimization, using goto statements for e0 stall, and got it to consume only 19 bytes:

16:49 <purdeaandrei[m]> would this be acceptable

16:49 <purdeaandrei[m]> * be acceptable?

17:03 <_whitenotifier-3> [glasgow] purdeaandrei opened pull request #650: Firmware read pull io expander input - https://github.com/GlasgowEmbedded/glasgow/pull/650

17:03 <purdeaandrei[m]> Just for reference, I haven't tested this yet: https://github.com/GlasgowEmbedded/glasgow/pull/650/files

17:06 <purdeaandrei[m]> As it is it's -59 bytes optimization + 78 bytes for the feature, results in +19 bytes total change

17:06 <purdeaandrei[m]> I put the optimization in a separate commit

18:41 <purdeaandrei[m]> oh, the firmware includes a git status, which makes results variable. Accounting for that, the real impact is:

18:41 <purdeaandrei[m]> -59 bytes optimization + 72 bytes for the feature, results in +13 bytes total change

18:41 <_whitenotifier-3> [glasgow] purdeaandrei commented on pull request #650: Firmware read pull io expander input - https://github.com/GlasgowEmbedded/glasgow/pull/650#issuecomment-2254607497

19:30 <_whitenotifier-3> [glasgow] purdeaandrei synchronize pull request #650: Firmware read pull io expander input - https://github.com/GlasgowEmbedded/glasgow/pull/650

19:30 <purdeaandrei[m]> Saved another 35 bytes with two more optimizations

19:31 <_whitenotifier-3> [glasgow] purdeaandrei commented on pull request #650: Firmware read pull io expander input - https://github.com/GlasgowEmbedded/glasgow/pull/650#issuecomment-2254621208

19:31 <purdeaandrei[m]> I can split these up as separate commits if you wish

19:32 <purdeaandrei[m]> the pr's now at -22 bytes

19:33 <purdeaandrei[m]> whoops , just re-reading I introduced a non-identical change, fixing...

19:37 <_whitenotifier-3> [glasgow] purdeaandrei synchronize pull request #650: Firmware read pull io expander input - https://github.com/GlasgowEmbedded/glasgow/pull/650

19:39 <purdeaandrei[m]> actually it was right, there's no reason to toggle OEQ_N_REVAB high then low on revAB. It's already high before the code runs due to the pull-up resistor, and it doesn't need to be high

19:59 <_whitenotifier-3> [glasgow] purdeaandrei synchronize pull request #650: Firmware read pull io expander input - https://github.com/GlasgowEmbedded/glasgow/pull/650

20:00 <_whitenotifier-3> [glasgow] purdeaandrei synchronize pull request #650: Firmware read pull io expander input - https://github.com/GlasgowEmbedded/glasgow/pull/650

20:31 <purdeaandrei[m]> does amaranth still not support controlling the internal pulls of the ice40?

20:38 <Wanda[cis]> um... what?

20:38 <Wanda[cis]> was that ever an issue?

21:48 <urja> I have no idea how to enter `Ctrl+\ q` (as the glasgow uart tty mode says is the quit combo) on a finnish layout keyboard.

21:51 <urja> I tried to press Ctrl+\ (Which is Ctrl+AltGr+the-keyright-of-0), then release AltGr (and tried with or without releasing Ctrl at this point),press space and q but nothing significant happened (the remote echoed space and q...)

21:52 <urja> oh. the space was not part of the combo.

21:54 <urja> SO yeah got it now, but that's a really weird sequence to parse out lol (at first i thought someone tried to \-escape a space lol)

22:27 <Attie[m]> ah, glad you figured it out... it is indeed Ctrl+\ ... and then q

22:36 <urja> Yeah, the \ had me so bamboozled that I didnt notice that i had misintrepreted the rest of the sequence

22:36 <urja> Until i wrote out what i tried

22:54 <Attie[m]> 😂

22:59 <urja[m]> Oh, a totally different question that I guess works better here (but still not sure of the channel). Are we going to have the glasgow pigtails / breakout cables sold seperately later? Because they're so good that I had the desire to cut one up for a project-specific configuration (but then I'd need ... more of them).

23:24 <Attie[m]> that's one for @esden ... iirc the answer was "yes, once things settle"

23:59 <attiegrande[m]> sorry, urja. (@_discord_463814842445201419:catircservices.org) ... I replied on Matrix and it seems my message didn't cross the bridge

23:59 <attiegrande[m]> that's one for esden (@_discord_269693955338141697:catircservices.org) ... iirc the answer was "yes, once things settle"