<whitequark[cis]>
ported the glasgow software stack to webusb
<galibert[m]>
that's insane, that's so you :-)
<whitequark[cis]>
thanks
sazzach[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
the idea is that if you don't need anything beyond the basics (i.e. no code editing) you can just open the website in chromium and start touching hardware
<galibert[m]>
you're >< far from a LA in a browser
<whitequark[cis]>
i could just compile pulseview to wasm
Attie[m] has joined #glasgow
<Attie[m]>
😱
<whitequark[cis]>
it's a qt application that uses libusb
<whitequark[cis]>
slightly painful but doalbe
<whitequark[cis]>
s/doalbe/doable/
nstandart[m]1 has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
the problem has never been the drivers or the gateware
<nstandart[m]1>
is there any documentation on how the applet API looks like, actually? kinda want to try my hand at porting a rather simple looking one (selftest) to v2, since it's apparently using v1
<nstandart[m]1>
heck, ig it's time to look through other PRs
<whitequark[cis]>
nstandart: yeah, at the time there's no documentation besides "look at past commits"
<whitequark[cis]>
re: selftest, another contributor was working on improving that applet in a number of ways
<galibert[m]>
Look also at the discussions between Cat and me on the last month, we worked on the i2c conversion
be65da6e451238ff has joined #glasgow
<be65da6e451238ff>
I'm seeing some weird behavior with my glasgow -- when I use the `uart` applet, it seems to sometimes duplicate characters kinda randomly and it will fail the `sink` and `loopback` benchmarks, but never the `source` one
<be65da6e451238ff>
Not entirely sure how to debug it or figure out if it's a problem with the hardware
<nstandart[m]1>
<whitequark[cis]> nstandart: yeah, at the time there's no documentation besides "look at past commits"
<nstandart[m]1>
fair enough, I'll try my best
<nstandart[m]1>
worst case scenario, I can try working on improving the docs I'm complaining about :^)
<be65da6e451238ff>
I ran into this problem before and "fixed" it -- at least I thought -- by just reflashing
<whitequark[cis]>
be65da6e451238ff: which OS are you using?
<be65da6e451238ff>
Fedora
<whitequark[cis]>
nstandart: the main reason there's no docs right now is because the API isn't finished and certainly not in a state where I'd actively like people to learn it; I think that breaking an established API is kinda rude, but for the same reason I am motivated to not document it until I'm confident that it's good
Lord_Nightmare has quit [Killed (ozone (No Spam))]
<be65da6e451238ff>
When I reflash (I do this by checking out `3651b66bed1b9beac55125b160a16f9f1eca3415` and running `glasgow flash` and then checking out `main` and running that again) it seems to pass the benchmarks at least
<be65da6e451238ff>
but eventually goes back to failing
<whitequark[cis]>
nstandart: it isn't (just) a lack of time to write docs, it is a lack of a well-defined semantic that can be documented
Lord_Nightmare has joined #glasgow
<whitequark[cis]>
we're getting a fair bit closer to the point where we do have well-defined semantics
<whitequark[cis]>
is there a reason you're using a checkout from 2 months ago?
<be65da6e451238ff>
I think I check that one out to reflash just because it was a version I found with an older firmware
<be65da6e451238ff>
I guess I could just ues `--remove-firmware` and rerun can't I...
<whitequark[cis]>
the latest software version with the latest firmware should work reliably
<nstandart[m]1>
hm, what do you think would be the important things to do, then? hardware is unfortunately not my forte, but maybe I can latch onto other topics and help a bit with that
<nstandart[m]1>
because ngl I'm liking the project the more I use it, and I don't even own the device myself
<whitequark[cis]>
nstandart: as an example of API changes, i think i should probably unify the `add_build_arguments` and `add_setup_arguments` methods. basically every single applet uses those, so i'm going to take advantage of all applets currently being in-tree and do a bulk upgrade
<whitequark[cis]>
(also, i find it that writing documentation is an excellent opportunity to give your API one final look and decide whether it's even worth teaching or not; i've overhauled a few pieces of Amaranth that has proven too difficult to teach)
<be65da6e451238ff>
maybe it has nothing to do with reflashing over and over and more to do with the power cycling :)
<whitequark[cis]>
quite possibly yes
<be65da6e451238ff>
either way it seems to fail those benchmarks eventually
<whitequark[cis]>
so, it's interesting that it fails at the very beginning
<whitequark[cis]>
hold on, why is it so slow?
<whitequark[cis]>
oh right you're limiting it to a very small size
<be65da6e451238ff>
In that paste it passes sink - source - source then fails sink
<whitequark[cis]>
this shouldn't matter: the applet is reset in between invocations
<whitequark[cis]>
what if you use glasgow run --reload?
<be65da6e451238ff>
then it will continue to fail sink and still pass source
<be65da6e451238ff>
I'll check
<whitequark[cis]>
that would make it possible to narrow it down to whether this is a reset issue
<be65da6e451238ff>
Still fails with --reload
<whitequark[cis]>
that smells like a QA issue
<be65da6e451238ff>
but if I unplug/replug it starts to succeed again for a bit
<be65da6e451238ff>
then starts failing again consistently
<whitequark[cis]>
i've never seen this failure before and all of the FPGA-side state would be reset after --reload
<be65da6e451238ff>
hm..
<be65da6e451238ff>
That makes sense to me
<whitequark[cis]>
(by "QA issue" i mean "it's a bad board")
<whitequark[cis]>
it is possible there is some sort of sleeper bug on the FX2 side, but i can't imagine that happening on something that is not a 512 byte boundary
<be65da6e451238ff>
Is there a good way to check if it's a bad board?
<whitequark[cis]>
actually hang on
<whitequark[cis]>
you say that loopback fails, can you look at how it fails?
<whitequark[cis]>
it should dump the exchange in the log and then you'll see if it's a bitflip, a dropped byte, etc
<whitequark[cis]>
so... there are a lot of 0b's and then the actual loopback data?
<be65da6e451238ff>
Looks like it
<whitequark[cis]>
that sounds like a bug on my side somehow
<whitequark[cis]>
but i can't reproduce it
<whitequark[cis]>
where/when did you buy your device?
<be65da6e451238ff>
1bitsquared
<be65da6e451238ff>
end of March
<whitequark[cis]>
unless you're very comfortable doing board level rework i recommend RMAing
<whitequark[cis]>
i suspect, but cannot prove, that there's a short or something on one of the FX2 control lines
<whitequark[cis]>
so whenever the applet ends up in reset, the line stays asserted and writes this junk into the FIFO, with the IOs staying at whatever the last value i s
<whitequark[cis]>
i don't know if it's under the FX2 or under the FPGA but it's probably under the FPGA if anything
<be65da6e451238ff>
I don't have the tools to check under the FPGA
<be65da6e451238ff>
well, I can remove it..
<be65da6e451238ff>
but not put it back on :)
<whitequark[cis]>
i don't imagine you have an xray, yeah
<whitequark[cis]>
if you remove it the short will be gone
<be65da6e451238ff>
ok I'll get in touch with 1bitsquared support
<be65da6e451238ff>
On a different note: I've been working on an applet for detecting UARTs similar to the JTAGulator functionality. Would that be something you'd be interested in having in main at some point once I verify it with a working device?
<whitequark[cis]>
yes, absolutely, having UART and SWD detection would be nice
<whitequark[cis]>
would that basically instantiate an UART with autobaud enabled per pin and check which of these have reasonable rx counters?
<be65da6e451238ff>
Cool, once I get this device fixed up I'll run some tests. I've got a few simulation tests already that all pass
<whitequark[cis]>
very nice
<be65da6e451238ff>
The way I have it working right now is basically just instantiate a UART and cycle through all pins looking for an echo of any sort
<whitequark[cis]>
oh right, jtagulator would also send characters and wait for echo
<be65da6e451238ff>
It will cycle through bauds
<be65da6e451238ff>
Yea
<be65da6e451238ff>
It's very similar to their method
<whitequark[cis]>
one thing that's different is that we have much stronger output drivers
<whitequark[cis]>
a glasgow pin can source or sink over 50 mA
<whitequark[cis]>
for JTAG, i dealt with it by making sure that the bus contention can only last a very short time (which is why the jtag-pinout applet doesn't use GPIO but a custom command interface)
<be65da6e451238ff>
I used jtag-pinout as a guide
<be65da6e451238ff>
I spun my wheels for all day today trying to figure out why my host communcation wasn't working though heh
<be65da6e451238ff>
seems like it wasn't my code
<whitequark[cis]>
yeah no this very much looks like a hardware issue
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
esden[cis] has joined #glasgow
<esden[cis]>
If I had issues with the comms between FPGA and FX2 it turned out to be a FX2 soldering issue in majority of the cases. FPGA is surprisingly robust regarding soldering.
<esden[cis]>
So IF you want to figure it out yourself it should be visible under the microscope if one of the FX2 connections is a cold joint. Otherwise, yes get in touch with 1bitsquared for RMA.
<whitequark[cis]>
specifically the cold joint could be at the SLWR pin
<be65da6e451238ff>
I did take a quick look for any shorts on the FX2 and don't see any. I didn't get out a microscope though just a little magnifying glass. I can take a closer look later