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
<whitequark[cis]> if the transaction isn't empty, it issues a stop condition at the end. that's it
FFY00 has quit [Ping timeout: 276 seconds]
FFY00 has joined #glasgow
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #glasgow
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
<_whitenotifier-4> [GlasgowEmbedded/archive] whitequark pushed 1 commit to main [+1/-0/±0] https://github.com/GlasgowEmbedded/archive/compare/99042f62b24c...106538e927f0
<_whitenotifier-4> [GlasgowEmbedded/archive] whitequark 106538e - Add G00101.
<whitequark[cis]> galibert: your stream manipulation code in i2c-initiator violates the stream rules
<whitequark[cis]> you have feedback from ready to valid. this isn't allowed
<whitequark[cis]> valid->ready: ok; ready->valid: not ok
balrog has quit [Ping timeout: 252 seconds]
balrog has joined #glasgow
dustinm`_ has quit [Ping timeout: 252 seconds]
dustinm` has joined #glasgow
<_whitenotifier-4> [glasgow] isabelburgos opened issue #938: Applets without CLI missing reset - https://github.com/GlasgowEmbedded/glasgow/issues/938
<whitequark[cis]> i think we should rename i2c-initiator to i2c-controller
<whitequark[cis]> the "initiator" name predates the official change from master/slave terminology in the spec, so it's different from what NXP says you should use
<_whitenotifier-4> [glasgow] whitequark opened pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<whitequark[cis]> check out the new API reference we (will) have in the manual: https://whitequark.github.io/glasgow/refactor-i2c-initiator/applets/interface/i2c_controller.html
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<galibert[m]> <whitequark[cis]> "you have feedback from ready..." <- It was just a renaming of the fifo code, didn't notice the rules were subtly different
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<galibert[m]> I like the interface, it's nice and clean
<galibert[m]> and yeah, using the "controller" name makes perfect sense and aligns with spi
<whitequark[cis]> of course the Device ID function that i never tested contains a subtle bug
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<whitequark[cis]> okay, there is now a full complement of simulation based tests for the I2C controller
<galibert[m]> wow nice
<whitequark[cis]> amaranth 0.5 and applet api v2 makes writing these really easy
<whitequark[cis]> it's only awkward because the i2c gateware is ancient
<galibert[m]> that is nice
<whitequark[cis]> check the test file out
<whitequark[cis]> this isn't hard or onerous
<galibert[m]> thinking about the "convert to v0.5" issue, what is it you consider obsolete, fifos? Elaboratables?
<whitequark[cis]> there's a python option that i don't recall this specific moment that lets you enable deprecation warnings
<whitequark[cis]> -Wdev i think
<whitequark[cis]> every warning needs to be fixed. nothing but the warnings has to be fixed
<galibert[m]> Ahhhh ok
<whitequark[cis]> amaranth is very good at giving you specific directions :p
<galibert[m]> when you find how to ask it :-)
<whitequark[cis]> i mean this isn't an amaranth thing, python just hides all deprecation warnings under "certain circumstances"
<whitequark[cis]> the "certain circumstances" happen to be not ideal for amaranth projects
<galibert[m]> indeed
<whitequark[cis]> actually i think our tests enable those warnings by default?
<whitequark[cis]> it might not be using any amaranth 0.5 deprecated features
<whitequark[cis]> try running the entire testsuite
<whitequark[cis]> there are definitely some
<galibert[m]> tried spi-controller, got the same result
<whitequark[cis]> that one is migrated to v2 api long ago
<whitequark[cis]> run the entire testsuite
<galibert[m]> is there a way to do that or I should play with the shell to test every applet one by one?
<galibert[m]> I'm not sure what you mean by entire testsuite honestly
<whitequark[cis]> pdm test
<galibert[m]> ok, I'm missing some packages, but that's fixable
<galibert[m]> ok, I'm missing something fundamental, I need to learn about pipx I guess
<whitequark[cis]> here we go
<galibert[m]> how do you tell pdm test to work in the pipx venv? It's failing because it's not finding glasgow and amaranth
<whitequark[cis]> i don't, i just have a second venv that pipx uses
<whitequark[cis]> it's possible to get pdm to use the pipx venv but i don't bother
<whitequark[cis]> (put the path to the pipx venv python into .pdm-python file in software/
<whitequark[cis]> * (put the path to the pipx venv python into .pdm-python file in software/)
<galibert[m]> I tend to do something that's completely anathema, e.g. install everything in the system
<whitequark[cis]> yeah that tends to break system packages in your distro
<whitequark[cis]> so i don't encourage or support that
<whitequark[cis]> (this is the case even if you do pip install --user
<whitequark[cis]> s//`/, s//`)/
<galibert[m]> ok pdm install / pdm test works
<galibert[m]> Yeah, I'm not using the term anathema lightly :-)
<whitequark[cis]> well the problem isn't so much that i dislike it, it's that i refuse to direct people to create obscure problems for themselves down the line
<galibert[m]> sure
<galibert[m]> which is why I use glasgow exactly as the documentation tells to, and I solve problems with my nonstandard installation of amaranth by myself
<galibert[m]> not that there are many problems in practice, amaranth is solid
<whitequark[cis]> which is appreciated, yeah
<galibert[m]> honestly, the V2 + fifo -> stream transition work is what's significant
<whitequark[cis]> note that warnings are only displayed once
<whitequark[cis]> that "use async testbenches" warning is probably referring to dozens of testbenches
<whitequark[cis]> (also oops, i messed up stacklevel= in that warning...)
<whitequark[cis]> UnusedElaboratable is displayed multiple times because the mechanism is nonstandard
<galibert[m]> ahhh, the warning is emitted by add_testbench, I understand better now
<whitequark[cis]> yeah
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<whitequark[cis]> okay, i think the PR is done
<galibert[m]> Cool
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
redstarcomrade has quit [Read error: Connection reset by peer]
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<whitequark[cis]> galibert: i also converted the bmx280 applet, as a way to test out the new API (and added tests for it. or rather, a tes)
<whitequark[cis]> s/tes/test/
<galibert[m]> nice
<galibert[m]> you tested it on real hardware then?
<whitequark[cis]> yes
<galibert[m]> excellent
<whitequark[cis]> i think we will probably need some form of UI testing, to test all the stuff in async def run
<whitequark[cis]> since right now it's basically untested
<whitequark[cis]> but we can add that later, I have so much stuff to do regardless
<galibert[m]> yeah
<_whitenotifier-4> [glasgow] whitequark opened pull request #940: cli: simplify/clarify argument group titles. - https://github.com/GlasgowEmbedded/glasgow/pull/940
<whitequark[cis]> https://github.com/GlasgowEmbedded/glasgow/pull/940 i kinda feel like we should unify add_build_arguments and add_setup_arguments into something like add_config_arguments
<_whitenotifier-4> [glasgow] whitequark opened pull request #941: Modernize `sensor-bmx280` applet - https://github.com/GlasgowEmbedded/glasgow/pull/941
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-940-76bf8fbcb3965f99721cf06c3a114a5462f40e35 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #941: Modernize `sensor-bmx280` applet - https://github.com/GlasgowEmbedded/glasgow/pull/941
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #941: Modernize `sensor-bmx280` applet - https://github.com/GlasgowEmbedded/glasgow/pull/941
<whitequark[cis]> idle thought: it should be possible to bind several applets using I2C to the same pins
<whitequark[cis]> it's actually much better to implement shared access to the medium on the software level (ie by sharing an I2CControllerInterface)
<galibert[m]> hmmm, should they be sharing a i2c_iface?
<whitequark[cis]> but sometimes you'll have situations where you can't do that
<galibert[m]> I don't think we have a mechanism to do that in the first place anyway
<whitequark[cis]> to do what? share i2c_iface?
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-939-8bb331319ca3c0579d37cb768c30eb1a373f4c08 - https://github.com/GlasgowEmbedded/glasgow
<galibert[m]> yeah
<galibert[m]> I mean a way to instanciate multiple applets that will end up sharing the i2c_iface
<whitequark[cis]> ah yeah, there would have to be an entire new dependency injection mechanism
<whitequark[cis]> an applet would need to be able to indicate that a part of its implementation can be uniquified between instances... but only if the configuration matches
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/76bf8fbcb396...8bb331319ca3
<whitequark[cis]> this is a can of worms all right
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-940-76bf8fbcb3965f99721cf06c3a114a5462f40e35 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark closed pull request #940: cli: simplify/clarify argument group titles. - https://github.com/GlasgowEmbedded/glasgow/pull/940
<galibert[m]> Why do you have BMx280Interface and BMx280I2CInterface? I would have thought the second didn't need to exist anymore
<whitequark[cis]> BMx280 sensors support SPI too
<whitequark[cis]> I even have an example of an SPI device here
<galibert[m]> So you'd like to share BMx280Interface between the two cases? Or even have an applet that can do either depending on the command line parameters?
<whitequark[cis]> yes that is the idea
<whitequark[cis]> I figured that I would write it in a way generic enough to support that in the future
<whitequark[cis]> like 6 years ago
<galibert[m]> So a BMx280I2CInterface and a BMx280SPIInterface inheriting from a common abstract interface with the correct one instantiated
<whitequark[cis]> yes
<galibert[m]> makes sense
<galibert[m]> any others of the to-convert i2c thingies in the same category?
<whitequark[cis]> all of them?
<galibert[m]> they all can do spi?
<whitequark[cis]> oh, I misunderstood
<galibert[m]> :-)
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 6 commits to main [+3/-3/±15] https://github.com/GlasgowEmbedded/glasgow/compare/8bb331319ca3...b685e96c2346
<_whitenotifier-4> [GlasgowEmbedded/glasgow] whitequark ab8bf95 - manual: `pdm live`: watch source directory for changes.
<_whitenotifier-4> [GlasgowEmbedded/glasgow] whitequark e362784 - manual: prepare for using Python docstrings.
<_whitenotifier-4> [GlasgowEmbedded/glasgow] whitequark 75e3ea9 - applet.interface.i2c_{initiator→controller}: follow the spec.
<_whitenotifier-4> [GlasgowEmbedded/glasgow] ... and 3 more commits.
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-939-8bb331319ca3c0579d37cb768c30eb1a373f4c08 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark closed pull request #939: Refactor the (new) `i2c-initiator` applet - https://github.com/GlasgowEmbedded/glasgow/pull/939
<whitequark[cis]> probably some of them but don't really care, I'm not sure anyone is interested in using SPI when a sensor does I2C in practice
<whitequark[cis]> i mean it's more reliable but people like to save pins
<galibert[m]> mah pins! Ok, good
<whitequark[cis]> I'll just let whoever first wants SPI to implement it
<galibert[m]> So the other ones should go with only one interface
<galibert[m]> so reason to separate things
<whitequark[cis]> yeah
<galibert[m]> s/so/no/
<galibert[m]> Ok, I'll see when I can do that
<galibert[m]> I don't think I'll look at 0.5 before V2 is fully here
<galibert[m]> but I least now I know how to look at it
<whitequark[cis]> "V2 is fully here" might be months away
<whitequark[cis]> there's a lot of work there
<galibert[m]> Well, there is a list, it is finite :-)
<galibert[m]> And I didn't hit anything insanely complicated at least on i2c
<galibert[m]> Maybe some applets will be more annoying, but we'll see
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #941: Modernize `sensor-bmx280` applet - https://github.com/GlasgowEmbedded/glasgow/pull/941
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #941: Modernize `sensor-bmx280` applet - https://github.com/GlasgowEmbedded/glasgow/pull/941
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-941-b685e96c23464f3c8ae53288701c5cab6f37830b - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+5/-0/±3] https://github.com/GlasgowEmbedded/glasgow/compare/b685e96c2346...1d58f93b4717
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-941-b685e96c23464f3c8ae53288701c5cab6f37830b - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark closed pull request #941: Modernize `sensor-bmx280` applet - https://github.com/GlasgowEmbedded/glasgow/pull/941
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
manawyrm has joined #glasgow
manawyrm has quit [Quit: Read error: 2.99792458 x 10^8 meters/second (Excessive speed of light)]
manawyrm has joined #glasgow
<_whitenotifier-4> [glasgow] whitequark opened pull request #942: Add API documentation to manual, where possible - https://github.com/GlasgowEmbedded/glasgow/pull/942
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-942-1d58f93b47172522efe1881024c33aae696c2214 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark opened pull request #943: manual: revC3: fix typo - https://github.com/GlasgowEmbedded/glasgow/pull/943
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±33] https://github.com/GlasgowEmbedded/glasgow/compare/1d58f93b4717...bbdd8e252127
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-942-1d58f93b47172522efe1881024c33aae696c2214 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark closed pull request #942: Add API documentation to manual, where possible - https://github.com/GlasgowEmbedded/glasgow/pull/942
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-943-bbdd8e252127e2e64245c6bcb404fa408ac70968 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark opened pull request #944: CI: cache PDM installation - https://github.com/GlasgowEmbedded/glasgow/pull/944
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #944: CI: cache PDM installation - https://github.com/GlasgowEmbedded/glasgow/pull/944
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/bbdd8e252127...cdb2e56d1561
<_whitenotifier-4> [glasgow] whitequark closed pull request #943: manual: revC3: fix typo - https://github.com/GlasgowEmbedded/glasgow/pull/943
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-943-bbdd8e252127e2e64245c6bcb404fa408ac70968 - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #944: CI: cache PDM installation - https://github.com/GlasgowEmbedded/glasgow/pull/944
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #944: CI: cache PDM installation - https://github.com/GlasgowEmbedded/glasgow/pull/944
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-944-cdb2e56d1561135e6581d902b76fd4c7d8e3ee1e - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-944-cdb2e56d1561135e6581d902b76fd4c7d8e3ee1e - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark synchronize pull request #944: CI: cache PDM installation - https://github.com/GlasgowEmbedded/glasgow/pull/944
<_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-944-cdb2e56d1561135e6581d902b76fd4c7d8e3ee1e - https://github.com/GlasgowEmbedded/glasgow
redstarcomrade has joined #glasgow
<_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/cdb2e56d1561...ab2de1144c6d
<_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-944-cdb2e56d1561135e6581d902b76fd4c7d8e3ee1e - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-4> [glasgow] whitequark closed pull request #944: CI: cache PDM installation - https://github.com/GlasgowEmbedded/glasgow/pull/944
redstarcomrade has quit [Read error: Connection reset by peer]
wiebel[m] has joined #glasgow
<wiebel[m]> Are there any plans on implementing an applet to program risc-v or a probe-rs like interface for risc-v (eg. CH32V003)?
<whitequark[cis]> yep, it's on my list
<whitequark[cis]> probe-rs support should not be that hard
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
<wiebel[m]> Awesome thanks so much.
redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
ALTracer[m] has joined #glasgow
<ALTracer[m]> <whitequark[cis]> "gtkwave is awful, pulseview is..." <- scopehal/ngscopeclient, obviously
redstarcomrade has quit [Read error: Connection reset by peer]