03:09 <wllenyj[m]> analyzer

05:02 <therealprof[m]> <jamesmunns> "Dunno if we ever hit consensus..." <- One issue here. It is used by the microbit crate which is used in the "discovery" book...

10:39 <JamesMunns[m]> <therealprof[m]> "One issue here. It is used by..." <- Yep, discussion on that going on in the nrf room.

10:44 <vollbrecht[m]> <firefrommoonligh> "Don't feel like the merge to..." <- I agree with all your points here. Still i think talking directly to each other, as a first step if things are not rolling as one side is hoping, should always be done over just accepting the status queue. Every site is always free to do as they wish, but we can't know what the other site on the table is thinking without talking. And in this case with respect to the

10:44 <vollbrecht[m]> incredible work the knurling team did there, i think it would not be justice to not talk first, to know how one should proceed after.

10:44 <vollbrecht[m]> If this is - for one party - to high of a burden no one should think bad of that party, but this step should always taking place. Obviously one should be cautious with the time constraint in mind many peoples have and wishing / nagging can feel exhaustive for people. I am talking generally and not specific about this case here.

10:46 <vollbrecht[m]> * a burden (for whatever reason) no one

10:51 <ryan-summers[m]> <dav1d> "lulf, nice thanks, the first one..." <- Let me guys know if you don't like minimq's API, I agree its a bit off to use, but happy to change it :) We've got all the MQTT functions implemented, but it could be nicer to use imho

10:53 <ryan-summers[m]> Its on my TODO to make it async-enabled, but QUARTIQ's apps are all pre-async embedded so I haven't had much motivation yet

14:34 <maxwickhamOld[m]> Hey all, I am currently building an open-source project for embedded Rust programming to solve the issues I’ve experienced in the firmware industry. I’m really interested to hear other people biggest development issues and their opinions on my current focus.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/AohtHqzwBUIeircAERkRkbEk>)

14:39 <ryan-summers[m]> <maxwickhamOld[m]> "Hey all, I am currently building..." <- > <@maxwickham:matrix.org> Hey all, I am currently building an open-source project for embedded Rust programming to solve the issues I’ve experienced in the firmware industry. I’m really interested to hear other people biggest development issues... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RneSeWHJjGWTJqEcSseETxus>)

14:39 <ryan-summers[m]> * General comment, but this sounds like almost 2-3 startup companies worth of ideas in one project. Source: I've talked to people doing this as an actual company

14:39 <ryan-summers[m]> So great ideas, but a lot of work

14:47 <jessebraham[m]> Sounds like `cargo-generate`, `probe-rs`, and `cargo` already largely solve these problems? Curious what deficiencies you feel these tools have

14:47 <jessebraham[m]> (Not saying they're perfect by any means, of course, but good tools IMO)

15:03 <maxwickhamOld[m]> Yeah we may be doing something similar to probe-rs (or integrating it) for some aspects. But, there’s still some things that could be easier, for example, dealing with multiple chips in one project, i.e. flashing AI accelerators. Also, we want to put a lot of emphasis on emulation for testing pipelines and in general, providing one central tool for dealing with all of these problems.

15:05 <Noah[m]1> PRs are very happily accepted :)

15:54 <thejpster[m]> Cargo workspaces are a bit of a nightmare with multiple targets and different feature flags. Would love to see that improved.

15:54 <thejpster[m]> There's a thing coming where I think that's really going to hurt.

16:00 <diondokter[m]> Wanna spill the beans??

16:00 <diondokter[m]> Looking through the cargo issue and PR tracker, I don't really see anything.

16:03 <dav1d> ryan-summers[m], for me it's currently just the initial hurdle, for me it isnt immediately clear how to use this with my current setup (embassy and esp) and I am not familiar enough with the embedded ecosystem to know how to plug this in.

16:18 <ryan-summers[m]> That's a fair point :)

16:30 <temurumaru[m]> Hi everyone!

18:10 <spinfast[m]> thejpster: so I did end up with a working wm8960 driver, using chiptool to generate the regmap and everything

18:10 <thejpster[m]> nice. I wrote everything by hand.

18:10 <spinfast[m]> * and everything, I think its pretty nice in the end, and I can even keep the regmap cached in memory as the wm8960 needs

18:10 <thejpster[m]> and the PDF was very much not amenable to copy-paste, as the text would come out in a fairly random order

18:10 <spinfast[m]> thejpster[m]: I've done that so many times, I'm done with it

18:10 <thejpster[m]> https://github.com/thejpster/nau88c22

18:11 <spinfast[m]> * with it, inevitably I screw something up and have to go refactor things

18:11 <thejpster[m]> yeah the TLV320AIC23 doesn't have read support, so you have to cache everything. The NAU88C22 does have read support though. Apparently.

18:11 <spinfast[m]> The nice part of this chiptool stuff is I can use yaml to then generate the regmap, so I mean I didn't get it working with python to rip the regmap out of the pdf, but maybe I could've

18:12 <spinfast[m]> rip out regmap, dump yaml (with doc strings and all perhaps), generate rust code from easy to grok yaml

18:12 <dirbaio[m]> I've written python regex crimes to rip registers from C headers to yaml :)

18:12 <spinfast[m]> like vs directly trying to rip the pdf and generate rust code, but then if you mess up...

18:12 <JamesMunns[m]> I know I saw japaric write a PDF-to-SVD converter once :D

18:12 <dirbaio[m]> usually a bit more machine readable than the pdf

18:12 <spinfast[m]> yaml's easy enough to hand edit if needed

18:13 <spinfast[m]> dirbaio: yeah but then perhaps you miss all the register and field doc strings, which are pretty awesome to have in an editor with autocomplete

18:13 <spinfast[m]> I added some to the yaml for chiptool to generate for, but not all

18:13 <dirbaio[m]> yeah (:

18:13 <dirbaio[m]> * yeah :(

18:14 <spinfast[m]> JamesMunns[m]: yeah I mean, same idea really I suppose, though svd to me is not so human friendly as the chiptool yaml IR stuff

18:15 <spinfast[m]> like this is pretty decent I feel like for readability https://github.com/SpinFast/wm8960-rs/blob/develop/wm8960.yaml

18:15 <spinfast[m]> though having to repeat the register size in the fieldset wasn't cool, I might have to look into that

18:15 <dirbaio[m]> neat!! :D

18:15 <dirbaio[m]> but most importantly... will it spin fast?

18:16 <spinfast[m]> haha, it does indeed let me generate a square wave from the imxrt1010 I have now :-D so I guess... in a way sure

18:16 <spinfast[m]> need to fix my sine lut, should copy James Munns stuff from his blog

18:16 <JamesMunns[m]> spinfast[m]: Yeah, that was in the Old Days where I don't think any of the YAML tooling stuff existed yet

18:17 <spinfast[m]> Imagine yaml from top to bottom, here's my board yaml describing how everything is connected, here's my soc yaml, here's my regmap yaml, before you know its kubernetes all over... lets not go too crazy I guess :-)

18:17 <JamesMunns[m]> Tho I think the more recent allwinner PACs are scraped from PDF as well, would be good to have a reference for the PDF -> ??? -> YAML -> chiptool pipeline

18:17 <JamesMunns[m]> spinfast[m]: hope nobody has a `NO` register :)

18:18 <spinfast[m]> yeah that would be nice, wm8960 pdf has a nice table even for python to rip, but I guess trying to readout those tables is hard

18:18 <spinfast[m]> it came out as gibberish

18:18 <spinfast[m]> * is hard, I tried it with the camelot package

18:18 <spinfast[m]> * is hard, I tried it with the camelot python package

18:20 <dirbaio[m]> ST's own SVDs for the newer families are scraped from PDF

18:21 <spinfast[m]> you'd think people might put some metadata in the vhdl/verliog/sv to generate regmaps...

18:21 <spinfast[m]> * generate regmaps from the rtl...

18:21 <spinfast[m]> * generate regmaps from the rtl..., * ... or maybe they do but only dump it in pdfs and no one else has access

18:21 <JamesMunns[m]> spinfast[m]: surprise! it's all interns and spreadsheets

18:21 <spinfast[m]> I'm not surprised... at all

18:22 <JamesMunns[m]> (just a guess, I would love to know the real process tho)

18:22 <spinfast[m]> we need to send in some R-E industrial spies to find out

18:22 <dirbaio[m]> ST's was intern-powered until L5 or so, then they switched to scraping their own PDFs

18:23 <spinfast[m]> * we need to send in some rust embedded wg industrial spies to find out

18:23 <dirbaio[m]> s/L5/L4/

18:23 <spinfast[m]> yeah its like... the asic doc writers I guess are the human firewall between the actual rtl source and the rest of the world

18:24 <spinfast[m]> gotta keep that spi IP block secret, surely there's massive value locked up there

18:24 <JamesMunns[m]> <spinfast[m]> "need to fix my sine lut, should..." <- btw there's some fun optimization tricks I didn't even hit in that code, like you can chop the LUT into 1/2 or 1/4 if you are willing to do a bit more math per lookup

18:24 <spinfast[m]> I kind of hope one of these open chip designs gets printed one day, would love a neorv32 in a qfp I can drop on a board

18:25 <JamesMunns[m]> (for that blog post, keeping the full 512B LUT wasn't a big deal, and I was going for max speed anyway :p)

18:26 <dirbaio[m]> how does the SVD look like...???... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/hFlnUMVpRlMXBTcOJjcQyZZg>)

18:26 <dirbaio[m]> 😬

18:27 <dirbaio[m]> useless garbage

18:27 <dirbaio[m]> that's the SVD straight from ST

18:28 <dirbaio[m]> there's more instances like this ... the human writing the Word document types things formatted slightly different than usual ... then their scraper doesn't pick it up.. 🥲

18:29 <dirbaio[m]> and of course no enum names, they're all B_0xWhatever

18:29 <dirbaio[m]> because the PDF doesn't have enum names, just value + description

18:30 <dirbaio[m]> (╯°□°）╯︵ ┻━┻

18:38 <mameluc[m]> garbage in, diamonds out

19:02 <Noah[m]1> Who's up for founding a chip company with proper materials? :P

19:03 <dirbaio[m]> sure just wait a moment I got a few spare million under my mattress

19:19 <barnabyw[m]> maybe we can team up with that guy who put together a DIY IC fab in his garage and (jokingly) was projected to beat moore’s law within a few years

19:35 <Noah[m]1> <dirbaio[m]> "sure just wait a moment I got..." <- and you have been hiding it all this time???!!!

19:35 <dirbaio[m]> i'd say that's a good reason to hide

19:35 <Noah[m]1> <barnabyw[m]> "maybe we can team up with that..." <- he already founded a company: https://atomicsemi.com/ and if they werent in SF I would be working there (copium) :'(

19:36 <Noah[m]1> err make that US instead of SF

19:37 <barnabyw[m]> oh cool, I hadn’t heard that! been a bit out of the loop about things like this since leaving twitter/X

19:48 <Noah[m]1> Yeah it's extremely dope!

19:48 <Noah[m]1> pun not intended

20:30 <thejpster[m]> <Noah[m]1> "Who's up for founding a chip..." <- Some might say Raspberry Pi already did…

20:31 <Noah[m]1> thejpster[m]: fair!

20:38 <thejpster[m]> Hell of a place to end up when they weren’t sure they could shift their first pallet of 10,000 Pi boards.

22:25 <Ecco> Dumb embassy-stm32 question: is it possible to do Output-only SPI? As in, I don't need MISO

22:29 <adamgreig[m]> (probably better to ask in #embassy-rs:matrix.org for embassy-specific stuff, btw)

22:30 <adamgreig[m]> but anyway, have you tried the new_txonly() method?

22:32 <Ecco> oh, didn't see it

22:32 <Ecco> awesome, thnaks :)

22:33 <Ecco> (I'm on IRC, is there a mirror for embassy-rs?)

22:33 <adamgreig[m]> aah, no, I don't believe there is

22:33 <M9names[m]> Also: not a dumb question, please don't feel like you need to add a disclaimer before you ask something here

22:33 <adamgreig[m]> you'll have to ask here instead :P

22:33 <Ecco> I guess I could use Matrix

22:33 <adamgreig[m]> the docs are on https://docs.embassy.dev/embassy-stm32/git/stm32g431cb/spi/struct.Spi.html but make sure you select the right stm32 in the dropdown at the top

22:33 <Ecco> but I gotta say I kinda like IRC

22:34 <Ecco> Thanks

22:34 <Ecco> So, I did browse the doc

22:34 <adamgreig[m]> yea, irc is nice! you can run your own irc-matrix bridge to let you access any matrix room through irc, too, but it's a bit of bother

22:35 <Ecco> but being very new to Rust I'm having a hard time following

22:35 <Ecco> like for instance, where is the "new" function documneted

22:35 <Ecco> ?

22:36 <adamgreig[m]> ah, unfortunately it's simply not documented, many/most of the embassy-stm32 functions don't have any documentation https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/src/spi/mod.rs#L86

22:36 <adamgreig[m]> you just gotta guess from the name what it does :P

22:37 <Ecco> yeah, that'x what I ended up doing: just looking at the source code