<whitequark>
we don't currently use badges but I can just add the link yeah
<d1b2>
<esden> Ok the https://discord.gg/P7FYThy is an invite link. But you can also link to https://1bitsquared.com/pages/chat whatever works better. I usually send out the 1b2 page link just in case the interface or the invite link id changes or something. To prevent possible breakage. 🙂
<whitequark>
done I think
<_whitenotifier-c>
[GlasgowEmbedded/glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JfVhd
<_whitenotifier-c>
[GlasgowEmbedded/glasgow] whitequark 9c10e19 - applet.interface.uart: add --pulls option, for pull-up on RX.
<d1b2>
<edbordin> Oh cool, maybe I should use that badge in the fpga-toolchain readme too
<d1b2>
<esden> @edbordin ohh yeah go ahead 😄
<whitequark>
i'm *so* looking forward to the point where glasgow can be used without installing any native dependencies
<whitequark>
because it'll instantly make first-class windows support not just viable but almost trivial
<whitequark>
performance on windows will still be poor compared to linux though, but i'm not sure if there is anything i can do to bring them to parity
setrofim has quit [Ping timeout: 246 seconds]
setrofim has joined #glasgow
<d1b2>
<edbordin> Hmm, curious what the plan is for USB comms without native code? Just present as a uart?
<whitequark>
by "native dependencies" in this context I really mean "things other than stuff in PyPI"
<whitequark>
so yosys and nextpnr
<whitequark>
we'll still depend on wasmtime in PyPI and libusb in PyPI
<whitequark>
and WinUSB (as a part of Windows) or libusbK (maybe? not sure if there's any actual benefit)
<d1b2>
<edbordin> Ah ok, nice :) WinUSB seemed like it worked well for the HaD badge
<d1b2>
<Darius> can't chrome do USB now?
* whitequark
shudders
<whitequark>
let's not go into WebUSB
<d1b2>
<Darius> haha
<whitequark>
edbordin: WinUSB works quite well for most devices, I imagine, but Glasgow does push latency and throughput to their hard limits
<d1b2>
<Darius> how much MORE evil can it be than WASM?
<whitequark>
WASM is awesome.
<d1b2>
<Darius> <lightning strikes> <paw closes>
<whitequark>
the only remotely evil thing in WASM is the control flow restrictions, but even those aren't unbearable
<whitequark>
well
<whitequark>
WASM doesn't seem to work out that well for web itself, like it doesn't yet have good JS interop for example
<whitequark>
fortunately I don't care about the web! I just need an unified substrate
<d1b2>
<Darius> yeah
<d1b2>
<edbordin> I stand by my statement that wasm is just java plugins all over again except the maintainers care more about fixing security holes :P
<whitequark>
I mean, that's fairly accurate
<whitequark>
I have previously described WASM as "like Java plugins but fit for purpose"
<whitequark>
you can tell it's fit for purpose because packaging browser components as WASM reduces the number of holes, not increases them
<whitequark>
edbordin: anyway, regarding WinUSB, Glasgow is an USB 2 device but it actually achieves max possible bandwidth only in USB 3 ports
<whitequark>
because you can quite trivially generate enough data on it to overwhelm the controller
<d1b2>
<Darius> I wonder if that is because xHCI controllers can do over lapping requests but ECHI ones can't
<whitequark>
I think it's something like that yeah
<whitequark>
I don't know much about HCIs but from some casual experimentation (watching a pin go high on my scope while the FIFO was full) it seems like a scheduling issue
<d1b2>
<edbordin> Hah, that is a pretty interesting phenomenon
<whitequark>
so you can observe that effect on Linux but not on Windows
<whitequark>
because all Windows USB drivers I tried introduce enough overhead that you can't actually hit 42 MB/s anyway
<d1b2>
<edbordin> Well fwiw it's on my to-do list to look at the options for a CLI tool to do what zadig does but faster
<whitequark>
you get something like 20 MB/s, maybe a bit better
<whitequark>
which to be fair is still a *lot* of data
karlyeurl has quit [Quit: No Ping reply in 180 seconds.]
StM_ has joined #glasgow
<whitequark>
yeah, a better zadig would be most welcome
<whitequark>
Glasgow doesn't *need* zadig because of WinUSB
<whitequark>
(I think the systems that lack WinUSB by this point are largely irrelevant)
StM has quit [Remote host closed the connection]
<whitequark>
the main circumstance in which you'll need zadig is if you plug a glasgow in that wasn't factory flashed with a firmware
karlyeurl has joined #glasgow
<whitequark>
which is still something we ought to support
<whitequark>
but it's relatively rare, hopefully
<whitequark>
anyway, the reason you get 20 MB/s on Windows is not quite just driver overhead, though IIRC it's larger than on Linux
<d1b2>
<edbordin> It looked like someone had implemented something as a python cli frontend to a Windows driver utility but I haven't tried it yet. And I was trying to avoid bundling a python interpreter. But that wouldn't be an issue for glasgow
<whitequark>
the main reason is that Windows can't issue SET_CONFIGURATION because its USB KMDF sucks (I don't know how else to describe its inability to perform one of the basic USB functions at runtime)
<whitequark>
so it's possible that we're going to have to add a Windows specific quirk where the device lies about always having four endpoints and instead sometimes has two
<whitequark>
effectively adding a vendor-specific equivalent of Set Configuration that tricks the host USB stack into working properly