<re_irc>
| help: a similar name exists in the module: `ADC`
neon[m] has quit [Remote host closed the connection]
<re_irc>
<@jamesmunns:beeper.com> : If you have a J-Link, I think I've used their GUI tools to do the same as well
<re_irc>
<@mehmet:grusbv.com> I really thought that I had used something from the rust ecosystem, but maybe you are right. Time to revert the Jlink driver to original
<re_irc>
<@jamesmunns:beeper.com> There might also be that! I've just not had to use it :D
dc740 has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> I mean, you could just write a quick rust utility using probe-rs as a lib and do it. Doubt it would be more effort than downgrading JLink firmware
<re_irc>
<@dirbaio:matrix.org> seriously, "probe-rs-cli dump" should work
<re_irc>
<@dirbaio:matrix.org> if it doesn't then there's either something wrong with the addresses, or with the probe, or it's just slow and you're not waiting enough. Try a smaller size to get a feel for how slow it is
<re_irc>
<@mehmet:grusbv.com> : You mean the command 'probe-rs-cli dump' right?
<re_irc>
<@mehmet:grusbv.com> Let me try it after updating probe-rs, since that gives me an stdout of address data pairs
<re_irc>
<@mehmet:grusbv.com> Rather than a binary file
<re_irc>
<@mehmet:grusbv.com> : I will try this as well
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> ah wtf, indeed it prints it as human-readable
<re_irc>
<@adamgreig:matrix.org> hi @room, meeting time again! agenda is https://hackmd.io/LxM7H54USI-pLWKqz3K3vg, please add anything you have to announce or discuss and we'll start in 5 min
<re_irc>
<@adamgreig:matrix.org> ok, let's start! no announcements from me this week, did anyone else have anything?
<re_irc>
<@therealprof:matrix.org> Nothing here.
<re_irc>
<@adamgreig:matrix.org> I wanted to discuss a couple of meta items, first up do people find the @ room notifications useful before the meeting?
<re_irc>
<@diondokter:matrix.org> Yes!
<re_irc>
<@adamgreig:matrix.org> I assume after all this time people either have them muted or find them useful but wanted to check I wasn't pissing off 1800 people every week in exchange for reminding a few people about a meeting, lol
<re_irc>
<@therealprof:matrix.org> I do find them useful, too.
<re_irc>
<@adamgreig:matrix.org> great, thanks :) let's keep them, then
<re_irc>
<@therealprof:matrix.org> It's also a nice delineation to easily find the start of the meeting.
<re_irc>
<@adamgreig:matrix.org> second question, should we keep the 'attendance' section of the minutes?
<re_irc>
<@adamgreig:matrix.org> it's sometimes helpful to know if someone is around when a discussion comes up that they're involved with
<re_irc>
<@adamgreig:matrix.org> but my guess is some people who are here listening aren't putting their names on, and it does then get archived afterwards
<re_irc>
<@eldruin:matrix.org> Yes, it's helpful when reading the meetings to know if somebody has potentially participated/knows about the discussion
<re_irc>
<@therealprof:matrix.org> I don't care either way.
<re_irc>
<@therealprof:matrix.org> But I agree with your reasoning.
<re_irc>
<@jannic:matrix.org> I don't mind putting my name there (otherwise I just wouldn't do it). As I'm not a WG member it probably doesn't matter anyway.
<re_irc>
<@adamgreig:matrix.org> to be clear, everyone is very welcome to put their name there, wg member or not
<re_irc>
<@adamgreig:matrix.org> cool, well let's keep them for now, if anyone's reading this later and has opinions on those subjects please chat or let me know
<re_irc>
<@eldruin:matrix.org> ehat I never understood is the motivation to keep last week's minutes
<re_irc>
<@eldruin:matrix.org> * what
<re_irc>
<@adamgreig:matrix.org> oh... i hadn't even considered that, lol
<re_irc>
<@adamgreig:matrix.org> it _is_ kinda pointless. it's helpful for me because this week's minutes are made by copy-pasting last week's minutes lol
<re_irc>
<@therealprof:matrix.org> And we used to put action items in there we could follow up with.
<re_irc>
<@adamgreig:matrix.org> but I guess I could just delete the entire last week section? perhaps it provides some context to discussions this week though
<re_irc>
<@eldruin:matrix.org> it's fine if it is useful for something like follow up
<re_irc>
<@adamgreig:matrix.org> but really, most of the relevant content should be in the agenda anyway
<re_irc>
<@adamgreig:matrix.org> ok, i'll ponder that but yea i guess it's not very important
<re_irc>
<@adamgreig:matrix.org> : would you like to see a return on action items? I'm not sure how practically useful they were by the time we stopped doing them, but perhaps not their fault
<re_irc>
<@therealprof:matrix.org> : Probably no use reintroducing them. I guess I prefer tagging people on GH nowadays.
<re_irc>
<@adamgreig:matrix.org> no update on the bors stuff this week, I meant to write up a quick note for our ops folder but haven't yet, it shouldn't be too difficult though
<re_irc>
<@adamgreig:matrix.org> on the book translations front, the PR author added some more details in https://github.com/rust-embedded/book/issues/326#issuecomment-1580987514 in response to the questions last week, and also pointed out that you could use po files for translations and still publish each language as a separate book (e.g. for the official rust docs they could remain just-english, I suppose)
<re_irc>
<@therealprof:matrix.org> : stm32f4xx-hal is also using GH MQ.
<re_irc>
<@dirbaio:matrix.org> embassy and smoltcp too. no issues to report, works great
<re_irc>
<@dirbaio:matrix.org> I miss "bors d+" tho 🥲
<re_irc>
<@adamgreig:matrix.org> github has automerge which is sort of exactly the opposite :P
<re_irc>
<@dirbaio:matrix.org> automerge disables itself if the contributor pushes more commits yep
<re_irc>
<@adamgreig:matrix.org> ok, I think next up is the per-peripheral steal() thing again, I haven't heard anything from japaric about whether there was some deep reason steal() needed to set the taken() flag, but actually it turns out we were all operating under something of a misunderstanding as far as the current PR goes
<re_irc>
<@adamgreig:matrix.org> because it provides "steal(&self) -> Self"
<re_irc>
<@dirbaio:matrix.org> what
<re_irc>
<@adamgreig:matrix.org> yea lol
<re_irc>
<@dirbaio:matrix.org> that's not stealing, that's piracy
<re_irc>
<@dirbaio:matrix.org> (stealing removes the original, piracy makes a copy :D)
<re_irc>
<@adamgreig:matrix.org> so as it stands you have to have either already used "Peripherals::steal()" or "Peripherals::take()"
<re_irc>
<@adamgreig:matrix.org> it just lets you make a copy easily, which I guess is useful for the "split UART into rx/tx pair" thing
<re_irc>
<@dirbaio:matrix.org> then 👎️ from me on having it the same name
<re_irc>
<@dirbaio:matrix.org> -it
<re_irc>
<@burrbull:matrix.org> there was a comment to rename it to "clone_unchecked"
<re_irc>
<@dirbaio:matrix.org> why limit it to clone though?
<re_irc>
<@dirbaio:matrix.org> why not add a "real" steal? then you don't need clone
<re_irc>
<@adamgreig:matrix.org> yea, I think we had basically concluded that you might as well add the real steal
<re_irc>
<@adamgreig:matrix.org> with only the slight lingering question of whether it should set the global flag
<re_irc>
<@adamgreig:matrix.org> (and if not, whether the normal steal() still should)
<re_irc>
<@burrbull:matrix.org> this flag also blocks it to be "const"
<re_irc>
<@adamgreig:matrix.org> I guess isn't around, if you are/are back later, did you get a chance to ask japaric about this?
<re_irc>
<@thalesfragoso:matrix.org> IIRC correctly it was just to make take() "safe safe"
<re_irc>
<@thalesfragoso:matrix.org> But take can still be safe, since we can have a future requirements in steal()
<re_irc>
<@thalesfragoso:matrix.org> Future requirements are weird, but they exist here and there
<re_irc>
<@adamgreig:matrix.org> future requirement as in "don't call take after calling steal()"?
<re_irc>
<@thalesfragoso:matrix.org> : Something like that, but more general
<re_irc>
<@adamgreig:matrix.org> I guess the problem with this safety case is it constrains every crate in your build in ways they can't really agree on
<re_irc>
<@dirbaio:matrix.org> the requirement is "don't use two instances of the same peripheral at the same time"
<re_irc>
<@adamgreig:matrix.org> but that's of course already the case given as they could just access memory themselves or use another hal or pac or whatever
<re_irc>
<@thalesfragoso:matrix.org> And less strict, since pheripherals are just a bunch of ZST
<re_irc>
<@dirbaio:matrix.org> that covers calling "take()" either before or after
<re_irc>
<@adamgreig:matrix.org> perhaps the idea was that if one crate calls steal() before another crate calls take(), the second knows it failed, but if the ordering is reversed everything proceeds in the bad way, so it's not much of a defence
<re_irc>
<@thalesfragoso:matrix.org> : Of someone is stealing they should be the one to prove atomicity or ownership
<re_irc>
<@thalesfragoso:matrix.org> So that's finr
<re_irc>
<@thalesfragoso:matrix.org> * fine
<re_irc>
<@adamgreig:matrix.org> it seems like just writing "don't allow two instances to be used at the same time" as a safety requisite in the docs of "steal()" would be more or less just as good?
<re_irc>
<@adamgreig:matrix.org> yea, makes sense
<re_irc>
<@adamgreig:matrix.org> like because they already have the peripheral (the typical HAL case) or they are in an critical section or something
<re_irc>
<@thalesfragoso:matrix.org> If someone is stealing they should be the one to prove atomicity or ownership
<re_irc>
<@thalesfragoso:matrix.org> Are we still using the deref trick for pheripherals? Not sure if that can cause problems
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@thalesfragoso:matrix.org> But iirc &mut to UnsafeCell<T> doesn't mean &mut to T anymore
<re_irc>
<@thalesfragoso:matrix.org> Since that was causing UB in Arc::drop
<re_irc>
<@thalesfragoso:matrix.org> But I have to check that again, my memory is fuzzy
<re_irc>
<@adamgreig:matrix.org> either way I think ultimately we need to move away from memory-mapped structs, but I don't think the steal api has much impact on that?
<re_irc>
<@thalesfragoso:matrix.org> Does the ZST implement DerefMut ?
<re_irc>
<@thalesfragoso:matrix.org> No, they don't. So that's fine I guess
<re_irc>
<@adamgreig:matrix.org> yea, just deref
<re_irc>
<@romancardenas:matrix.org> Pointer-like regs can be copy, right? So all the steal thing is not necessary
<re_irc>
<@adamgreig:matrix.org> yea, if you removed the owned singleton concept from PACs, there'd be no need for steal
<re_irc>
<@romancardenas:matrix.org> Quite a breaking change right?
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@dirbaio:matrix.org> yeah imo svd2rust should remove owned singletons and switch to rawpointer-based reg access
<re_irc>
<@dirbaio:matrix.org> but
<re_irc>
<@dirbaio:matrix.org> gonna be blunt here
<re_irc>
<@dirbaio:matrix.org> if adding a per-peripheral "steal()" takes a month of weekly meetings
<re_irc>
<@dirbaio:matrix.org> I don't see these other changest happening anytime soon 😅
<re_irc>
<@dirbaio:matrix.org> * changes
<re_irc>
<@thejpster:matrix.org> Sorry, was away. I did ask Jorge but didn’t get an answer. I’ll ask again.
<re_irc>
<@adamgreig:matrix.org> : thanks!
<re_irc>
<@adamgreig:matrix.org> : maybe, maybe not, sometimes the small issues take way more discussion :P
<re_irc>
<@dirbaio:matrix.org> small PR everyone can understands, everyone can bikeshed
<re_irc>
<@dirbaio:matrix.org> 🙃
<re_irc>
<@adamgreig:matrix.org> ok, for this week: is there any point to clone_unchecked if we end up with per-peripheral steal()?
<re_irc>
<@adamgreig:matrix.org> I think clone_unchecked is fairly uncontroversial since it doesn't touch on the static flag, so we could probably just go ahead with it, but if we actually want per-peripheral steal() and could probably decide on that soon instead, maybe no point having clone_unchecked
<re_irc>
<@adamgreig:matrix.org> (I say uncontroversial only in the context of the recent discussions around steal() where I feel like the remaining sticking point has been the static flag)
<re_irc>
<@romancardenas:matrix.org> : My CLINT PR for riscv already uses the raw pointer fashion, we can use it as a probe to test the ergonomics and expand to other crates
<re_irc>
<@dirbaio:matrix.org> just remove steal() setting the flag
<re_irc>
<@dirbaio:matrix.org> there's no compelling reason for it
<re_irc>
<@dirbaio:matrix.org> : chiptool too
<re_irc>
<@dirbaio:matrix.org> the approach is proven
<re_irc>
<@dirbaio:matrix.org> the problem is that when you want to change svd2rust then everyone is affected, so everyone will have opinions
<re_irc>
<@dirbaio:matrix.org> 🤷
<re_irc>
<@thalesfragoso:matrix.org> : That seems about right.
<re_irc>
<@therealprof:matrix.org> Agree.
<re_irc>
<@adamgreig:matrix.org> and once you remove it, no reason to not also have per-peripheral steal, right?
<re_irc>
<@dirbaio:matrix.org> yep
<re_irc>
<@romancardenas:matrix.org> : Yep... At least riscv is less expanded and "pushing" peripherals this way might be easier to swallow
<re_irc>
<@adamgreig:matrix.org> OK, I think in conclusion we'll ask the PR author to make the methods into associated functions, and separately PR steal not setting the flag
<re_irc>
<@adamgreig:matrix.org> I think at this point it's been discussed a bunch in the chat, so probably more of a hal team thing to work out any remaining concerns and make a decision?
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> iiuc the concern mentioned was fixed (it was missing "flush()" calls)
<re_irc>
<@therealprof:matrix.org> If is happy, I'm happy.
<re_irc>
<@dirbaio:matrix.org> they haven't responded :P
<re_irc>
<@dirbaio:matrix.org> (and I'm pretty sure linux-embedded-hal can impl "SpiBus::flush()")
<re_irc>
<@eldruin:matrix.org> I think it's fine with the flush due to the time alignment
<re_irc>
<@eldruin:matrix.org> I'll have another look
<re_irc>
<@dirbaio:matrix.org> cool
<re_irc>
<@dirbaio:matrix.org> any other concerns?
<re_irc>
<@eldruin:matrix.org> actually, I want to check how flush would work on l-e-h haha
<re_irc>
<@dirbaio:matrix.org> if it can't impl "SpiBus::flush()" then it can't impl "SpiBus" at all
<re_irc>
<@esden:matrix.org> Hi everyone. It might not be the right time to ask this. (I can wait till after the meeting) But I would like some guidance on what needs to be done to merge STM32L4R5 support. https://github.com/stm32-rs/stm32l4xx-hal/pull/324 (I have the hardware, can test and work on getting this to a mergable state)
<re_irc>
<@dirbaio:matrix.org> : use "embassy-stm32", it supports STM32L4+ (including STM32L4R5)
<re_irc>
<@eldruin:matrix.org> hmm, it would be important to add the bit about needing flush before delays and time difference and so on to the docs for downstream implementations
<re_irc>
<@dirbaio:matrix.org> (I don't think stm32l4xx-hal is seeing much active maintenance)
<re_irc>
<@dirbaio:matrix.org> anyway I don't think it should be blocking for this PR, "SpiBus::flush()" already existed before
<re_irc>
<@adamgreig:matrix.org> : I don't think any of the stm32l4xx-hal maintainers have much time for it atm, _perhaps_ except ?
<re_irc>
<@adamgreig:matrix.org> if you have a PR that passes tests I can merge it for you, or if you'd like to be a maintainer and merge it yourself I can also arrange that
<re_irc>
<@esden:matrix.org> : ok, sounds good. Then maybe it should be communicated that this is a stale path. I will work using embassy instead.
<re_irc>
<@adamgreig:matrix.org> (or indeed check out embassy-stm32, which does support stm32l4)
<re_irc>
<@dirbaio:matrix.org> : well that'd be up to the stm32l4xx-hal maintainers
<re_irc>
<@esden:matrix.org> Yeah fair enough.
<re_irc>
<@dirbaio:matrix.org> the stm32-rs org is not part of the rust embedded WG
<re_irc>
<@adamgreig:matrix.org> yea, it's no more or less official than embassy-stm32 etc
<re_irc>
<@dirbaio:matrix.org> i've already brought this up in the past
<re_irc>
<@dirbaio:matrix.org> people search "stm32l4 rust" on google, come across that HAL, then get disappointed
<re_irc>
<@dirbaio:matrix.org> and get the impression "embeddded rust is not mature" etc etc
<re_irc>
<@adamgreig:matrix.org> i guess you need better SEO for embassy 😎
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@esden:matrix.org> I am glad I asked here then, as I would have pressed on trying to get that working. googling for tutorials/guides mostly talks about the stm32xxxx-hal stuff. embassy is younger so google is not rating it higher yet. I would have banged my head against the wall for no reason. :)
<re_irc>
<@adamgreig:matrix.org> they're quite different HALs, to be fair
<re_irc>
<@eldruin:matrix.org> can we organize an application for a grant to do all the stuff we always wanted to do in all stm32 pacs/hals ?
<re_irc>
<@adamgreig:matrix.org> and afaik you still need to use a git dependency for embassy-stm32?
<re_irc>
<@eldruin:matrix.org> first we would need a willing candidate, though 😓
<re_irc>
<@dirbaio:matrix.org> : the question is WHY
<re_irc>
<@dirbaio:matrix.org> why spend effort copypasting the same code across 10 repos
<re_irc>
<@adamgreig:matrix.org> just briefly, are we done on the spi delayus point?
<re_irc>
<@eldruin:matrix.org> : from my side yes
<re_irc>
<@dirbaio:matrix.org> (talking about the stm32-rs hals. the PACs are in good shape)
<re_irc>
<@dirbaio:matrix.org> it doesn't scale 😂
<re_irc>
<@eldruin:matrix.org> : well, then maybe have a different structure with all the hals in one place, I understood the main problem we have is that it is a lot of work to do anything and nobody has the time
<re_irc>
<@dirbaio:matrix.org> that's what embassy-stm32 does
<re_irc>
<@dirbaio:matrix.org> single HAL supporting all 1500 stm32 chips
<re_irc>
<@therealprof:matrix.org> : Why keep the PACs when there're no HALs using them?
<re_irc>
<@adamgreig:matrix.org> I guess the more pertinent question is what a different HAL to embassy might look like and whether it's worth having as a separate project
<re_irc>
<@dirbaio:matrix.org> and you have to structure the HAL quite differently to be able to do that
<re_irc>
<@adamgreig:matrix.org> : I mean, I use the PACs, that's why I made them in the first place, and I don't use the HALs
<re_irc>
<@eldruin:matrix.org> : yes, but I understand the implementation design also differs, it is not only monorepo vs distributed
<re_irc>
<@adamgreig:matrix.org> the SVDs from it have ended up in all sorts of weird places too, the embedded go and zig people took them I think?
<re_irc>
<@adamgreig:matrix.org> 99% of the work is the svds, generating the pacs from that is of course the easy bit
<re_irc>
<@jamesmunns:beeper.com> Just for a note: I just put out an ask on #nrf-rs:matrix.org (https://matrix.to/#/#nrf-rs:matrix.org) to see if folks are okay with marking the nrf-rs repos as archived, and forwarding on to embassy, which is much more actively developed.
<re_irc>
<@esden:matrix.org> Lol the monorepo vs. distributed argument. I just heard the same discussion about it comparing tokio vs smol ;)
<re_irc>
<@therealprof:matrix.org> : As in svd2rust generated PACs or the RAL ones?
<re_irc>
<@jamesmunns:beeper.com> (there's nothing _wrong_ with nrf-rs, but embassy-nrf is generally more mature at the moment)
<re_irc>
<@adamgreig:matrix.org> I mostly use stm32ral rather than the svd2rust pacs personally, true
<re_irc>
<@adamgreig:matrix.org> but I mean, I'd keep maintaining the svd2rust builds even if no one used the stm32-rs hals any more, it's all automated
<re_irc>
<@adamgreig:matrix.org> (hopefully a new stm32-rs release quite soon now, got a lot of the outstanding PRs merged)
<re_irc>
<@esden:matrix.org> the svd2rust is very useful when working with custom MCU... like a DIY Risc-v soft core on fpga... being able to generate the PAC from json is quite nice. (I know it is quite a hack but works nicely)
<re_irc>
<@adamgreig:matrix.org> oh yea, svd2rust certainly isn't going away, the question is just about the stm32-rs PACs generated using it (which also aren't going away)
mrtazz has quit [Server closed connection]
<re_irc>
<@esden:matrix.org> : It is on my very long TODO list, to clean up the svd2rust path to generate directly from json. I am currently abusing the "patch" path using an empty svd template. It should not be necessary and just allow to ingest a json directly. One day I might come around to it. ;)
mrtazz has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> ah, got you
<re_irc>
<@adamgreig:matrix.org> I think that should be pretty easy to add now, yea
<re_irc>
<@esden:matrix.org> yeah it is pretty easy, I "just" ™️ have to find time to do it :D
<re_irc>
<@adamgreig:matrix.org> I think is talking about "svdtools"'s patch stuff atm
<re_irc>
<@adamgreig:matrix.org> but yea, if you are just generating a json from your hdl or whatever, maybe better to use "svd2rust" directly with its json format input
dc740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@dirbaio:matrix.org> is there some no-std protobuf lib out there?
<re_irc>
<@dirbaio:matrix.org> +no-alloc
<re_irc>
<@jamesmunns:beeper.com> you uh, could bind to nano-pb?