whitequark[cis] changed the topic of #glasgow to: https://glasgow-embedded.org · digital interface explorer · https://www.crowdsupply.com/1bitsquared/glasgow · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.catirclogs.org/glasgow · matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
fibmod has quit [Ping timeout: 252 seconds]
redstarcomrade has joined #glasgow
fibmod 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
<whitequark[cis]> <ALTracer[m]> "scopehal/ngscopeclient, obviousl..." <- i gave up on those, too miserable to interact witg
<whitequark[cis]> * i gave up on those, too miserable to interact with
redstarcomrade has quit [Read error: Connection reset by peer]
brainstorm_nopco has quit [Quit: Idle timeout reached: 172800s]
ali_as has quit [Remote host closed the connection]
lxdr533 has quit [Remote host closed the connection]
lxdr533 has joined #glasgow
esc_ctrl[m] has quit [Quit: Idle timeout reached: 172800s]
unlobito has quit [Remote host closed the connection]
unlobito has joined #glasgow
<galibert[m]> I'm sending 17-bytes packets, and I'm systematically losing 1571 bytes after 2560. No loss afterwards. Any idea what can cause that?... (full message at <https://catircservices.org/_irc/v1/media/download/ATakMAGywefkzny3Uq92qLXSOpPgkJss-Ay47UnBihvUbLNLwjb9DS-JNz2KWvIhlonSar3LuDBPuhe-LtE0Kjq_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9oY3dHZFFDQk1DakhHelRtdW1SemZ3Tnc>)
icb-[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]> galibert: how big are your USB packets?
<galibert[m]> should be 17 bytes + overhead
<galibert[m]> I'm flushing every 17 in any case
<whitequark[cis]> every USB packet drains a finite resource (4-deep packet FIFO in the FX2) that only replenishes whenever the controller polls you
<galibert[m]> and the recv is 17 too
<whitequark[cis]> so flushing every 17 bytes means you have much more overhead than the bare size suggests
<galibert[m]> what's weird it's that it's not losing entire packets
<galibert[m]> and it drops exactly at 2560 bytes
<whitequark[cis]> hm
<galibert[m]> which is a very programmer number
<whitequark[cis]> well, all the data you write gets stuffed into multiples-of-512 series of FIFOs
<whitequark[cis]> so it would make sense that at 5 of those (this is exactly the 4 ones in the FX2 and one more in the gateware) it overflows
<whitequark[cis]> ah, I see what's happening
<whitequark[cis]> you start capturing straight away, without any command from the host, right?
<galibert[m]> yep
<galibert[m]> is that bad?
<whitequark[cis]> there is a short pause between when the FPGA configures and when the FIFO starts to get drained
<whitequark[cis]> actually, sorry, let me clarify
<whitequark[cis]> your applet should be in reset between when the FPGA configures and when the USB interface is opened
<whitequark[cis]> but there is a short pause between when the USB interface is opened and when the FIFO actually starts to get emptied
<whitequark[cis]> so you overflow it in that period
<galibert[m]> can I do that without having the build a istream just to send one byte?
<whitequark[cis]> sure, add_rw_register
<galibert[m]> ah, good idea
<whitequark[cis]> it's kind of cursed because i recently finished a refactor that was supposed to bring resets to a good order
<whitequark[cis]> and clearly this is a very real downside of the post-refactor code
<galibert[m]> it really needs to be in the future docs :-)
<whitequark[cis]> tbh i think "applet that starts writing right after the reset" is kind of an antipattern
<whitequark[cis]> it does come up every once in a while and i've hit the issue myself
<galibert[m]> note that I may like having the capability to suspend and restart the capture in the future, and a register should make that easy
<whitequark[cis]> nevertheless we should either document it or fix it so that it's not a problem, and i'm leaning towards fix
<whitequark[cis]> galibert[m]: yes, exactly; in most real-world circumstances you would have suspend/restart functionality
redstarcomrade has joined #glasgow
<galibert[m]> ah, resources can only be requested once
<galibert[m]> Yep, stable, thanks
<whitequark[cis]> nice
<galibert[m]> Love how trivial adding a register was
<whitequark[cis]> yep that's the idea: most common operations should be as easy as one function call
<galibert[m]> For reference
<galibert[m]> looks like I'm nearing the point where I can do mu captures again, but this time with the glasgow rather than the saleae, which will be a lot nicer
<_whitenotifier-4> [glasgow] whitequark opened pull request #945: Modernize `sensor-scd30` applet and add test - https://github.com/GlasgowEmbedded/glasgow/pull/945
<whitequark[cis]> one thing re: sharing one i2c_iface between different things is that they may not be able to agree on clock rates
<whitequark[cis]> for example, this SCD30 sensor's recommended i2c clock rate is 50 kHz
<galibert[m]> if you're not running at the slowest clock rate the slow devices on the line are going to be hopelessly confused
<whitequark[cis]> it really depends
<whitequark[cis]> i'm sure some devices can't run arbitrarily slow
<whitequark[cis]> i think smbus has this quirk
<galibert[m]> sure, but there we're talking about multiple devices connected to the same scl/sda lines. If they're not compatible, glasgow is not going to solve that
<whitequark[cis]> miek__: do you still have your Sensirion SEN5x? I'd like to add HIL tests for which I'd need to collect data from a real device
<whitequark[cis]> galibert[m]: no, but it should be able to point out the incompatibility
<whitequark[cis]> if it requires you to do legwork like going through the datasheets, it might as well punt on you to combine the applets manually
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-945-ab2de1144c6df724df25f939caa3e086733b1208 - https://github.com/GlasgowEmbedded/glasgow
<galibert[m]> and it's entirely going to depend on what the command line looks like anyway
<galibert[m]> sharing lines between applets is so unusual it would make sense that it's kinda special
<whitequark[cis]> it's not unusual to have multiple things hanging off an i2c bus you connected to somewhere
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+3/-0/±2] https://github.com/GlasgowEmbedded/glasgow/compare/ab2de1144c6d...d3cbeb77b305
<_whitenotifier-4> [glasgow] whitequark closed pull request #945: Modernize `sensor-scd30` applet and add test - https://github.com/GlasgowEmbedded/glasgow/pull/945
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-945-ab2de1144c6df724df25f939caa3e086733b1208 - https://github.com/GlasgowEmbedded/glasgow
miek__[m] has joined #glasgow
<miek__[m]> yep, i've still got it
icanc[m] has joined #glasgow
<icanc[m]> is there an applet that does simple tests like generating PWM or generating a simple clock?
<whitequark[cis]> there's control-servo
<whitequark[cis]> which does a PWM of sorts
<icanc[m]> i see, but there isnt control of exact frequency and duty cycle right?
<whitequark[cis]> you didn't specify the application, and for simple tests of "does this work or not" type that applet would work
<whitequark[cis]> what do you want to achieve?
<_whitenotifier-4> [glasgow] whitequark opened pull request #946: Modernize `sensor-sen5x` applet - https://github.com/GlasgowEmbedded/glasgow/pull/946
<whitequark[cis]> miek__: okay, i'd like you to test https://github.com/GlasgowEmbedded/glasgow/pull/946 by running `glasgow test sensor-sen5x`
<whitequark[cis]> that should create a new fixture file in the applet directory (test_sen5x.json or something) which i'd like you to give me
<whitequark[cis]> well also test glasgow run sensor-sen5x too of course
<whitequark[cis]> also, since i don't have the hardware, would you like to be the code owner for that applet?
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #946: Modernize `sensor-sen5x` applet - https://github.com/GlasgowEmbedded/glasgow/pull/946
<icanc[m]> sorry i didnt really clarify, was wondering if i can generate several arbitrary PWM signals that switches between 1mhz and 20mhz. an applet to test some system would be really nice
<whitequark[cis]> you can write an applet that would do that, yeah
<galibert[m]> the clock is 48MHz, so generating 20Mhz is nearing the limits of the thing
<whitequark[cis]> you have two PLLs to play with, so depending on the resolution you want, there's some headroom
<galibert[m]> true that
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #946: Modernize `sensor-sen5x` applet - https://github.com/GlasgowEmbedded/glasgow/pull/946
redstarcomrade has quit [Read error: Connection reset by peer]
<icanc[m]> i see, thank you, ill play around with it!!
<icanc[m]> honestly it would be a cool expansion board to add a mems clock generator
<galibert[m]> Read that as a meme clock generator. That was something
<whitequark[cis]> there is a control-si535x applt
<whitequark[cis]> s/applt/applet/
<whitequark[cis]> so you could get a cheap si5351 devboard and use that to generate arbitrary clocks
<_whitenotifier-4> [GlasgowEmbedded/archive] whitequark pushed 1 commit to main [+1/-0/±0] https://github.com/GlasgowEmbedded/archive/compare/106538e927f0...43f6e8fb9f42
<_whitenotifier-4> [GlasgowEmbedded/archive] whitequark 43f6e8f - Add G00102.
<_whitenotifier-4> [GlasgowEmbedded/archive] whitequark pushed 1 commit to main [+1/-0/±0] https://github.com/GlasgowEmbedded/archive/compare/43f6e8fb9f42...67636f621e69
<_whitenotifier-4> [GlasgowEmbedded/archive] whitequark 67636f6 - Add G00103.
ih8c0ff33[m] has joined #glasgow
<ih8c0ff33[m]> Hi, I just got a new rev C3 (from mouser) but it’s giving me errors when I try to run any applet: FPGA health check failed. I tried measuring power supply test points and it seems that there’s no power on the 1.2V line… does this mean the board is broken and I should ask for a replacement or is there something that can be done to fix it?
<whitequark[cis]> iggi8463: this is unfortunately a known issue with the 1b2 boards. you can always RMA it, but also I believe that it's a soldering issue and you may be able to fix it yourself (which would disqualify you for an RMA)
<whitequark[cis]> esden would be able to say more
<whitequark[cis]> oh, just realized you got yours from mouser... it's still a 1b2 board but I don't know what the RMA process is. I assume you have to go through mouser again
esden[m] has joined #glasgow
<esden[m]> Sorry to hear that. It is a bit odd because I was pretty sure mouser ran out of stock quite a while ago. That said, you can send me an email to info@1bitsquared.com and we can talk through the options. RMA is definitely an option, we will be happy to replace the board for you.
<whitequark[cis]> mouser still has like 60 revC3's in stock
<whitequark[cis]> 56 as of right now
<esden[m]> mhh... surprising, but ok
<ih8c0ff33[m]> esden[m]: Ok, will send an email as soon as I get back home (so that I can get the serial number if needed).
<whitequark[cis]> why is that surprising?
<esden[m]> because they should not have more units than here were needet to fulfill the campaign
<whitequark[cis]> they stocked about a hundred of them publicly like a month or two ago and have been selling them at a slow pace ever since
<esden[m]> yeah it makes no sense because I have no idea where they would have them from...
<esden[m]> unless they kept a pile back a while ago
<esden[m]> that is the only explanation I have for that
<ari> unsuccessful deliveries from campaign?
<esden[m]> could be
<esden[m]> it would be indeed very useful to get the serial number from you iggi8463 (@_discord_1057322300170571876:catircservices.org)
<esden[m]> looking forward to your email 🙂
<esden[m]> if they kept back units from earlier on, that would also explain why there is a power supply issue. Because I am pretty sure I have not shipped a unit with that issue out in a while. I specifically test for that these days.
ali_as has joined #glasgow
ali_as has quit [Remote host closed the connection]
josHua[m] has quit [Quit: Idle timeout reached: 172800s]
zyp[m] has quit [Quit: Idle timeout reached: 172800s]
<ih8c0ff33[m]> esden: Just sent the email. btw the board is from mid december 2024 if that could be useful information.
bvernoux has joined #glasgow
bvernoux has quit [Quit: Leaving]
<_whitenotifier-4> [glasgow] whitequark opened pull request #947: Modernize `control-si535x` applet - https://github.com/GlasgowEmbedded/glasgow/pull/947
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-947-d3cbeb77b3052d69db80493f93dee32e3196a72d - https://github.com/GlasgowEmbedded/glasgow
<whitequark[cis]> our CI times are down to 3 minutes \o/
<whitequark[cis]> i think most people don't care, but i've been landing many enough PRs recently that i kind of ... do
<SnoopJ> nice
<whitequark[cis]> i could probably make it even faster by using uv as the resolver?
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+4/-0/±5] https://github.com/GlasgowEmbedded/glasgow/compare/d3cbeb77b305...276a4a52611c
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-947-d3cbeb77b3052d69db80493f93dee32e3196a72d - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark closed pull request #947: Modernize `control-si535x` applet - https://github.com/GlasgowEmbedded/glasgow/pull/947
<whitequark[cis]> but eh, good enough
<SnoopJ> pretty much how I feel about most of its speedup cases
<SnoopJ> PubGrub does seem cool though
<whitequark[cis]> it does feel snappier that uv run glasgow is 0.3s instead of 0.8s for pdm
<whitequark[cis]> but the pipx-installed editable one is also 0.3s
<SnoopJ> huh
<whitequark[cis]> ok, let's try something
<whitequark[cis]> i might be able to implement the "Nagle-like" behavior we've been discussing with very little performance impact
* SnoopJ stares sadly at 30 min test suite
<whitequark[cis]> i... think i did it??
<whitequark[cis]> the flush problem, solved once and for all????
<whitequark[cis]> whaaat