Catherine[m] changed the topic of #glasgow to: digital interface explorer · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.irclog.whitequark.org/glasgow · Matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
<whitequark[cis]> one potential solution is to use configuration "D" here
<d1b2> <omnitechnomancer> Gotta have the asn.1 for all the implementation security vulns
<electronic_eel> i'm not sure if we are making the communication between the python and the fx2 firmware more complicated when we add an extra endpoint that needs special length handling and stuff, while we still need the control endpoint for bitstream uploading and basics like reset
<whitequark[cis]> bitstream uploading?
<whitequark[cis]> no, I don't think I was clear enough: if we go EP1IN/EP1OUT route, all of the vendor specific USB requests will be removed
<whitequark[cis]> so bitstream uploading will use it as well
<whitequark[cis]> as for the reset, it will be integrated into Set Interface handling, with the FX2 automatically resetting FX2 by using the pin we currently use for FLAGD (which will go unused in this new configuration)
<whitequark[cis]> so the FPGA won't have any I2C registers
<electronic_eel> ok, so the limitation with 64 bytes you mentioned earlier doesn't exist with the buffer configuration scheme D
<whitequark[cis]> correct
<whitequark[cis]> with scheme D, we will be fully USB compliant
<whitequark[cis]> however I'm not sure if scheme D allows hitting full USB2 throughput. this will need to be tested
<electronic_eel> which scheme do we use now?
<whitequark[cis]> right now we use one of the two options: A+A' or B+B'
<whitequark[cis]> A+A' does not result in using the full USB2 throughput. B+B' does
<whitequark[cis]> oh, wait
<whitequark[cis]> Scheme D won't work since EP8 is unidirectional
<whitequark[cis]> basically the only limitation with EP1IN/EP1OUT is that the host software must never queue a transfer bigger than 64 bytes
<whitequark[cis]> instead of the normal situation where you can use transfers of, well, any size
<whitequark[cis]> however, because we also have Set Interface for EP1IN/EP1OUT, this means that a half transmitted packet can be cleared (and will automatically be cleared) if e.g. host software crashes
<whitequark[cis]> so I think EP1IN/EP1OUT solution justifies its complexity more than the EP0 solution does
<whitequark[cis]> almost all of the FX2 pipe packets will be smaller than 64 bytes and require confirmation, so not being able to easily pipeline transfers isn't an issue; this will actually not have any performance downside compared to the current scheme at all
<whitequark[cis]> wtf is Utopia
<electronic_eel> so what advantage does the ep1in/ep1out have over the control endpoint?
<electronic_eel> there are no access clashes on linux
<whitequark[cis]> - it is not possible to have two applications transmit on it simultaneously on Linux
<whitequark[cis]> - it is easy to recover from e.g. someone hitting ^C while firmware is loading
<whitequark[cis]> basically, we know when the host application crashes if we go that route
<whitequark[cis]> oh, there's another important one
<whitequark[cis]> the FX2 can initiate transfers on EP1IN to report conditions such as alert
<whitequark[cis]> so it's not necessary to e.g. poll it
<electronic_eel> yeah, that is a good feature
<whitequark[cis]> this is actually something I planned to make possible anyway by e.g. using EP1IN as an interrupt endpoint
<whitequark[cis]> but it sending a packet would be way better
<electronic_eel> so this sounds like a good idea to me - but i'm now getting really tired and i think i should go to sleep soon
<whitequark[cis]> yeah, have a good rest
<whitequark[cis]> I'll probably take a stab at implementing this
<electronic_eel> you too - have a productive night :)
<whitequark[cis]> thanks
<galibert[m]> ‘Night all
<whitequark[cis]> oh, btw, should we recommend that people self-build revC3's now? cc esden
<sorear> > universal test and operations physical interface for ATM (UTOPIA)
<whitequark[cis]> horrifying
<sorear> i'm guessing this is like (R)(G)MII?
<sorear> do we have anything explaining what is and isn't in scope for clients not using the glasgow python stack?
<d1b2> <esden> @whitequark I have to push a thing (i think it is just a meta data field change or something), then we can merge revC3 into main, and can recommend revC3 to build.
<d1b2> <esden> Not near the machine with that right now.
<whitequark[cis]> got it
<whitequark[cis]> sorear: anyone not using the glasgow python stack is on their own
<sorear> you mentioned a rust thing more than once
<whitequark[cis]> that would be internal to Glasgow
<sorear> so we will be shipping and using native code other than the system libusb at some point?
<whitequark[cis]> this depends on how fast we can get Python to frame and unframe communications with the device
<whitequark[cis]> I'm thinking of two potential uses for Rust:
<whitequark[cis]> - speeding up framing code that's too slow in Python
<whitequark[cis]> - exporting a Glasgow connected to USB as a TCP socket
<whitequark[cis]> s/socket/server/
<whitequark[cis]> the first one will happen whenever we can't hit USB 2 throughput with Python alone
<whitequark[cis]> the second one doesn't strictly have to use Rust, but it's much cheaper to install a Rust binary on, say, a Raspberry Pi, that you may be using for remoting
<whitequark[cis]> does this clarify things?
<sorear> yes
<whitequark[cis]> oh, neat:
<SnoopJ> pyo3 goes brrrr
<sorear> i'm just thinking that if we are already planning to use rust for the framing, it might make sense to look more closely at options like byte escaping that would be non-starters in python
<whitequark[cis]> broadly speaking I agree
<whitequark[cis]> I'm thinking that the firmware could be made considerably smaller with one optimization for I2C
<whitequark[cis]> basically, a tiny bytecode for I2C that's interpreted by a loop
<whitequark[cis]> instead of a ton of calls to i2c_* and jumps
<whitequark[cis]> anyway, we don't have to build that unless we really run out of firmware space
<whitequark[cis]> basically you would have sth like... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wbZZBJIuwvnoJVolDjYQJJYV>)
<whitequark[cis]> * basically you would have sth like... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nJFMUJGeyqEOtzzODseZCqBX>)
<whitequark[cis]> and then that would be turned into a bunch of literal stores into the paged data area
_whitelogger has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<d1b2> <esden> @whitequark should glasgow not return with a value != 0 if no device is found? I am getting a 0 return from factory when no glasgow is connected
<whitequark[cis]> esden: factory is weird...
<whitequark[cis]> let me just fix that
<whitequark[cis]> oh that's just a typo
<d1b2> <esden> Thank you. I am just trying to run it in a loop and "do stuff" when it succeeds (audio cue in this case)
<_whitenotifier-8> [glasgow] whitequark opened pull request #368: cli: fix typo - https://github.com/GlasgowEmbedded/glasgow/pull/368
<whitequark[cis]> see PR above
<d1b2> <esden> ahh lol ok 🙂
<whitequark[cis]> when are you finishing flashing for today? I can remain on call in the meantime
<_whitenotifier-8> [glasgow] esden commented on pull request #368: cli: fix typo - https://github.com/GlasgowEmbedded/glasgow/pull/368#issuecomment-1657001762
<d1b2> <esden> @whitequark I am putting the scripts for the different steps right now. factory is working now it seems. 🙂
<d1b2> <esden> next, is flash and IO test and led blinker. Then last but not least the serial number sticker generation. (I rather do that in 3 distinct steps... for now and streamline as we go)
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to gh-readonly-queue/main/pr-368-6b4dbfdfc4c03627ffaabadae62c091d2dd10305 [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/commit/1c055a48e52d
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark 1c055a4 - cli: fix typo.
<_whitenotifier-8> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-368-6b4dbfdfc4c03627ffaabadae62c091d2dd10305 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-8> [glasgow] whitequark commented on issue #187: applet.interface.i2c_initiator: timeout & error message when SCL stuck low - https://github.com/GlasgowEmbedded/glasgow/issues/187#issuecomment-1657003014
<d1b2> <esden> ok, selftest when it fails also returns 0 it seems?
<d1b2> <esden> I mean it returns 0 if it finds a device but one of the tests fails.
<whitequark[cis]> think so
<whitequark[cis]> that would be a more substantial modification
<d1b2> <esden> ok, I guess I can do some grep magic to check if there is an error or not. But it would be nice to get an expected return in the future.
<whitequark[cis]> lemme just fix that now I guess
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/6b4dbfdfc4c0...1c055a48e52d
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark 1c055a4 - cli: fix typo.
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-368-6b4dbfdfc4c03627ffaabadae62c091d2dd10305
<_whitenotifier-8> [glasgow] whitequark closed pull request #368: cli: fix typo - https://github.com/GlasgowEmbedded/glasgow/pull/368
<_whitenotifier-8> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-368-6b4dbfdfc4c03627ffaabadae62c091d2dd10305 - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]> okay, i think i implemented it
<chipb> > - exporting a Glasgow connected to USB as a TCP socket <3
<chipb> remote network access to a device is severely underrated.
<d1b2> <esden> thank you @whitequark 🙂
<_whitenotifier-8> [glasgow] whitequark opened pull request #369: Rationalize return codes - https://github.com/GlasgowEmbedded/glasgow/pull/369
<whitequark[cis]> esden: see PR above
<d1b2> <esden> 👏 ... let me test it 🙂
<_whitenotifier-8> [glasgow] esden commented on pull request #369: Rationalize return codes - https://github.com/GlasgowEmbedded/glasgow/pull/369#issuecomment-1657005918
<_whitenotifier-8> [glasgow] whitequark opened pull request #370: CI: group all required workflows into one status check - https://github.com/GlasgowEmbedded/glasgow/pull/370
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 2 commits to gh-readonly-queue/main/pr-369-1c055a48e52dae4a28f16402f821a0fe91917a3a [+0/-0/±2] https://github.com/GlasgowEmbedded/glasgow/compare/90999d3f93fb^...619dd54e8a27
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark 90999d3 - cli: rationalize return codes for running applets.
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark 619dd54 - applet.internal.selftest: ensure CLI exits with code 1 on failure.
<_whitenotifier-8> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-369-1c055a48e52dae4a28f16402f821a0fe91917a3a - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-8> [glasgow] whitequark synchronize pull request #370: CI: group all required workflows into one status check - https://github.com/GlasgowEmbedded/glasgow/pull/370
<d1b2> <esden> ok, I think I have all the steps working. 🙂 Thank you @whitequark 🙂
<_whitenotifier-8> [glasgow] whitequark synchronize pull request #370: CI: group all required workflows into one status check - https://github.com/GlasgowEmbedded/glasgow/pull/370
<_whitenotifier-8> [glasgow] whitequark synchronize pull request #370: CI: group all required workflows into one status check - https://github.com/GlasgowEmbedded/glasgow/pull/370
<_whitenotifier-8> [glasgow] whitequark synchronize pull request #370: CI: group all required workflows into one status check - https://github.com/GlasgowEmbedded/glasgow/pull/370
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 2 commits to main [+0/-0/±2] https://github.com/GlasgowEmbedded/glasgow/compare/1c055a48e52d...619dd54e8a27
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark 90999d3 - cli: rationalize return codes for running applets.
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark 619dd54 - applet.internal.selftest: ensure CLI exits with code 1 on failure.
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-369-1c055a48e52dae4a28f16402f821a0fe91917a3a
<_whitenotifier-8> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-369-1c055a48e52dae4a28f16402f821a0fe91917a3a - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-8> [glasgow] whitequark closed pull request #369: Rationalize return codes - https://github.com/GlasgowEmbedded/glasgow/pull/369
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to gh-readonly-queue/main/pr-370-619dd54e8a27aa1c725f2ba2d402c7235c90eca8 [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/commit/b5d1ef8defcd
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark b5d1ef8 - CI: group all required workflows into one status check.
<_whitenotifier-8> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-370-619dd54e8a27aa1c725f2ba2d402c7235c90eca8 - https://github.com/GlasgowEmbedded/glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/619dd54e8a27...b5d1ef8defcd
<_whitenotifier-8> [GlasgowEmbedded/glasgow] whitequark b5d1ef8 - CI: group all required workflows into one status check.
<_whitenotifier-8> [GlasgowEmbedded/glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-370-619dd54e8a27aa1c725f2ba2d402c7235c90eca8
<_whitenotifier-8> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-370-619dd54e8a27aa1c725f2ba2d402c7235c90eca8 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-8> [glasgow] whitequark closed pull request #370: CI: group all required workflows into one status check - https://github.com/GlasgowEmbedded/glasgow/pull/370
joerg has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
joerg has joined #glasgow
<whitequark[cis]> 70?
<d1b2> <esden> so far yes
trh has quit [Quit: weg]
trh has joined #glasgow
shaiku has joined #glasgow
shaiku has quit [Client Quit]
shaiku has joined #glasgow
shaiku has quit [Client Quit]
<d1b2> <thestumbler> Congrats on the news shared in the Crowd Supply product update. It’s been so long since I ordered (Feb 2021), I can’t remember if I was an “early bird” or a regular supporter.
<d1b2> <bob_twinkles> You can check on CS (it will say "early bird" in the name of the product if you are I believe) but feb2021 is almost certainly not
<d1b2> <bob_twinkles> (for reference I ordered in 2019 or early 202 and I'm not =P)
redstarcomrade has joined #glasgow
<d1b2> <thestumbler> Thanks. I see a label that says "pre-order" Guess I'm in that Feb 2024 batch. Looking forward to it regardless.
<Wanda[cis]> also, what is the AUX connector for? we've been wondering about this for ages (and don't see any explanation on the CS page)
<whitequark[cis]> some people REALLY hate leaving unused FPGA balls uncnnected
<whitequark[cis]> there were two left
<whitequark[cis]> (+ ground)
<Wanda[cis]> oh.
<Wanda[cis]> yeah, that explains it
<whitequark[cis]> yea you can just do whatever with them lol
<Wanda[cis]> it's raw FPGA connection like the LVDS pins, right?
<whitequark[cis]> yep, at 3.3V
<whitequark[cis]> oh
<whitequark[cis]> it's actually properly protected
<d1b2> <bgb711> will these boards be factory programmed before shipping?
<whitequark[cis]> yes
<whitequark[cis]> this means you'll be able to immediately plug them into your Windows PC and not install any additional drivers
<galibert[m]> They appear as serial?
<whitequark[cis]> no
<whitequark[cis]> there is a WinUSB descriptor that lets libusb immediately interact, without having to use Zadig
<galibert[m]> Oh nice
<galibert[m]> that's a lot more elaborate than most usb designs
<whitequark[cis]> Glasgow is a lot more elaborate (and customer focused) than most designs
<d1b2> <bgb711> cool, that is the yoWASP thing, right?
<galibert[m]> Color me unsurprised :-)
<whitequark[cis]> bgb711: no, yowasp is unrelated (but it is another piece that makes Windows support seamless)
<d1b2> <bgb711> ok
<whitequark[cis]> I think the one thing we could do better is having a shortcut to Glasgow cmd be installed with pipx
<d1b2> <bgb711> I have installed glasgow on my arch linux according to the main github page, though my order number is 1700+😅
GNUmoon has quit [Ping timeout: 240 seconds]
GNUmoon has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<galibert[m]> My order number is 177887 so… ;-)
<whitequark[cis]> those are straight thru all of CS
<galibert[m]> I sure hope so. It would be a resounding success for 1b2, but the kind of success that implodes a company
<whitequark[cis]> lol
<Wonka> Feb 2024... not before next CCC congress then... *sigh* ;)
jstein has joined #glasgow
bvernoux has joined #glasgow
<d1b2> <adaisdead> Is there any idea on how many Glasgows where ordered so we can try to guess when ours might be delivered?
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #glasgow
bvernoux has quit [Read error: Connection reset by peer]
<d1b2> <perigoso.> I think such predictions would do more harm than good
<cyborgar> based on past data all we know that until the boards are all packed and sent to mouser's warehouse the delivery date is anyone's guess :)
TT[m]1 has joined #glasgow
ar-jan has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
<d1b2> <esden> @cyborgar that is indeed a good attitude. This is why I am reluctant to provide delivery dates. There is so much that can always go wrong along the way. I will feel more confident and better over all when all those glasgows are shipped to mouser. (just remember mouser tends to take a few weeks to ship things they received on their dock...)
<d1b2> <esden> @adaisdead Yes, we have to send around 1500 Glasgows and 1000 cases to fulfill the backers, and another 1k Glasgows and 700 cases for pre-orders.
rcombs has quit [Quit: ZNC - http://znc.in/ZNC]
<d1b2> <esden> but you can't predict when you will get your board based on that
rcombs has joined #glasgow
<d1b2> <esden> The best thing is to relax, lean back, and just wait, be pleasantly surprised when a package get's delivered. 😄 (That is what I do with everything I back myself)
<d1b2> <nemanjan00> It is hard to predict customs delays alone, with stuff that is already shipped
<d1b2> <nemanjan00> Here in Serbia, it can take up to 20 days, for example
<d1b2> <esden> yes, indeed, "domestic" (USA) orders are variable 2-5 days ... international orders more like 2-4weeks? International post works in mysterious ways... and I hate it. 😦
<d1b2> <esden> I recently had someone in Australia, that made me refund their order because the package did not arrive in 3 weeks... it took another 2 weeks and the package was eventually delivered... :/
<d1b2> <nemanjan00> In my case, I hoped to use it as a part of project, for talk, but i think I will switch to samething I can procure faster and something that has protocol I need already implemented
<d1b2> <esden> I am sorry it is taking so long, I wish you could use Glasgow for your project 😦
<d1b2> <nemanjan00> It is not a huge part of project, just wiegand logger and emulator, so I will manage just fine without it 😃
<d1b2> <esden> 👍
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
TT[m]1 has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
RobTaylor[m] has quit [Quit: Bridge terminating on SIGTERM]
esden[cis] has quit [Quit: Bridge terminating on SIGTERM]
wifasoi[m]1 has quit [Quit: Bridge terminating on SIGTERM]
ericr[m] has quit [Quit: Bridge terminating on SIGTERM]
Wanda[cis] has quit [Quit: Bridge terminating on SIGTERM]
Chips4MakersakaS has quit [Quit: Bridge terminating on SIGTERM]
galibert[m] has quit [Quit: Bridge terminating on SIGTERM]
charlottia has quit [Quit: Bridge terminating on SIGTERM]
sszilvasi[m] has quit [Quit: Bridge terminating on SIGTERM]
bboett[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #glasgow
whitequark[cis] has joined #glasgow
Wanda[cis] has joined #glasgow
galibert[m] has joined #glasgow
RobTaylor[m] has joined #glasgow
charlottia has joined #glasgow
esden[cis] has joined #glasgow
Chips4MakersakaS has joined #glasgow
wifasoi[m]1 has joined #glasgow
sszilvasi[m] has joined #glasgow
jevinskie[m] has joined #glasgow
bboett[m] has joined #glasgow
ericr[m] has joined #glasgow
TT[m]1 has joined #glasgow
<d1b2> <josuah_dem> I think that if I received mine to day, I'd be excited and poke at it, but it would stay on the desk taunting me until I gather enough time to give it a real go.
<_whitenotifier-8> [glasgow] whitequark opened issue #371: Replace the dependency on `crc` using `amaranth.lib.crc` - https://github.com/GlasgowEmbedded/glasgow/issues/371
<whitequark[cis]> does anyone want an easy contribution to Glasgow? here is an issue: https://github.com/GlasgowEmbedded/glasgow/issues/371
<Wanda[cis]> it's for software use only, isn't it?
<whitequark[cis]> yes, though eventually we'll want to do it in hardware too
<whitequark[cis]> e.g. for the floppy applet
<Wanda[cis]> (we're not going to touch it for now btw, we have bigger fish to fry)
<whitequark[cis]> nod!
<whitequark[cis]> 180!!
<d1b2> <esden> This is 200, 5 in a stack 4x10
ar-jan has quit [Ping timeout: 244 seconds]
<whitequark[cis]> ohh
<whitequark[cis]> I miscounted oops
<d1b2> <esden> Yeah the far row is not visible very well...
<d1b2> <vegard_e> enable output on a single pin at a time and leave the rest as input with pullup or pulldown, then sample all pins for the expected return, open pin shows up as no change and short shows up as changes on pins that shouldn't, and as long as you don't pick adjacent pins for the loopback, it can't mask a short
<d1b2> <vegard_e> the orbtrace testsuite works in this manner, but there I've got the extra challenge that I've got the same signals on three different connectors and want to test all of them, so what I ended up with there is different loopback patterns on each connector, effectively making three groups that still satisfy the requirement that no pins in a group are adjacent
<d1b2> <vegard_e> when you've got point to point signals to a single connector, you can just wire one half to the other half, taking care that you're not looping the middle adjacent pins back
<sorear> "open" is tricky because it's not a binary condition - the pin exists and is driving a ball, at least, since the FPGA was factory tested, but depending on the board condition the pin could be driving a quite variable amount of trace, with or without the level shifter, pulls, or ESD diodes
<whitequark[cis]> vegard_e: yeah we know how to implement this
<whitequark[cis]> it's just that I got much more disabled while revC was being developed
<d1b2> <vegard_e> ah, I'm not sure if the reference to the message I replied to came across the bridge
<Wanda[cis]> it did not
<d1b2> <vegard_e> sorry, I forgot this was a bridged channel, that was a response to something @esden said yesterday
<d1b2> <esden> It was something I said in regards to the lvds loopback connector idea from electronic_eel
duderonomy has quit [Ping timeout: 244 seconds]
<whitequark[cis]> ahh
<_whitenotifier-8> [glasgow] icb- opened pull request #372: Replace dependency `crc` with `amaranth.lib.crc` - https://github.com/GlasgowEmbedded/glasgow/pull/372
<_whitenotifier-8> [glasgow] whitequark reviewed pull request #372 commit - https://github.com/GlasgowEmbedded/glasgow/pull/372#discussion_r1278640426
<_whitenotifier-8> [glasgow] whitequark reviewed pull request #372 commit - https://github.com/GlasgowEmbedded/glasgow/pull/372#discussion_r1278640558
<_whitenotifier-8> [glasgow] whitequark reviewed pull request #372 commit - https://github.com/GlasgowEmbedded/glasgow/pull/372#discussion_r1278640595
<_whitenotifier-8> [glasgow] whitequark reviewed pull request #372 commit - https://github.com/GlasgowEmbedded/glasgow/pull/372#discussion_r1278640697
<_whitenotifier-8> [glasgow] icb- synchronize pull request #372: Replace dependency `crc` with `amaranth.lib.crc` - https://github.com/GlasgowEmbedded/glasgow/pull/372
<_whitenotifier-8> [glasgow] whitequark reviewed pull request #372 commit - https://github.com/GlasgowEmbedded/glasgow/pull/372#discussion_r1278640948