ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
sroemer has joined #rust-embedded
ana_briated_ has joined #rust-embedded
ana_briated has quit [Ping timeout: 272 seconds]
ana_briated_ is now known as ana_briated
pcs38 has joined #rust-embedded
vanner has quit [Quit: ZNC 1.9.1 - https://znc.in]
vanner has joined #rust-embedded
<JamesMunns[m]> Misc thought in passing: if critical-section only uses primask to mask interrupts, and on thumbv6m systick is an exception not masked by primask, does that mean that our systick exception handler functions are not sound?
<JamesMunns[m]> (someone will probably tell me I'm wrong, just reading a bunch of unrelated things, don't take the above statement as fact)
thejpster[m] has joined #rust-embedded
<thejpster[m]> What makes you say the systick exception isn’t disabled by primask (CPSID i)?
<thejpster[m]> See page B1-194 of Arm ARM version 6, M-Profile.
<thejpster[m]> As an aside I think the framing there is really interesting. The PRIMASK bit does not disable interrupts - the PRIMASK bit raises the priority of the main thread to be priority level zero, therefore it cannot be pre-empted except by a fault handler.
<JamesMunns[m]> https://github.com/rtic-rs/rtic/issues/667#issuecomment-1341524007 from @korken89 was what lead me down that thought
<JamesMunns[m]> And yeah, I guess we're only reading "are the interrupts active" from primask: https://docs.rs/cortex-m/0.7.7/src/cortex_m/critical_section.rs.html#11-24
kenny has quit [Ping timeout: 272 seconds]
kenny has joined #rust-embedded
reto[m] has joined #rust-embedded
<reto[m]> Hi all, this is my first venture into writing a device driver. It's for a fast (40MHz) configurable quadrature counter (iC-Haus iC-MD) that I need for a instrument upgrade project. While that project is super specific to our given setup... (full message at
sroemer has quit [Quit: WeeChat 4.5.2]
<thejpster[m]> <JamesMunns[m]> "https://github.com/rtic-rs/rtic..."; <- I think that’s specifically about having shared resources between two tasks and therefore stopping Task A pre-empting Task B. When one task is the SysTick handler, I guess that’s quite hard to do as SysTick Exceptions cannot be masked by talking to NVIC - they only get masked with that single bit in a CPU register. I don’t know the specifics but that sounds racy.
sroemer has joined #rust-embedded
link445645[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]> <i509vcb[m]> "Always a great sign when the..." <- at least they're honest about it 😬 (I actually prefer dialogs like this to dark pattern "cookie consent" popups which are in no way mandated by the GDPR - telling people instead upfront that yes they are a commercial media enterprise and want your money either directly or indirectly seems fair and as-transparent-as-you'll-get-these-days)
MichaFita[m] has joined #rust-embedded
<MichaFita[m]> embedded-hal question: v1.0.0 supports less device types than 0.2.7. If I start moving drivers I have it means I have to disable implementations I don't have HAL's traits for. Is there any intermediate path to take to keep all drivers available (like ADC, Watchdog) or should I just ditch trait based approach for them?
<jason-kairos[m]> .text.HardFault vs .HardFault is my guess at the problem
<jason-kairos[m]> but, I think it would be hard to reproduce. Probably only applies to specific versions and build configurations
<thejpster[m]> I found https://interrupt.memfault.com/blog/arm-cortex-m-exceptions-and-nvic today, and it is excellent. Recommended reading.
<thejpster[m]> Maybe I should write a Rust version...
<JamesMunns[m]> thejpster[m]: if you do, and want it published there, lemme know and I can intro you. They want me to do more rust stuff and I haven't had time :D
pcs38 has quit [Quit: leaving]
Ekho has quit [Ping timeout: 252 seconds]
ello- has joined #rust-embedded
ello has quit [Ping timeout: 248 seconds]
NishanthMenon has quit [Ping timeout: 268 seconds]
tschundler has quit [Ping timeout: 248 seconds]
AdamHorden has quit [Ping timeout: 252 seconds]
Ekho has joined #rust-embedded
NishanthMenon has joined #rust-embedded
dnm has quit [Ping timeout: 252 seconds]
edm has quit [Ping timeout: 268 seconds]
AdamHorden has joined #rust-embedded
dnm has joined #rust-embedded
NishanthMenon has quit [Ping timeout: 252 seconds]
NishanthMenon has joined #rust-embedded
edm has joined #rust-embedded
tschundler has joined #rust-embedded
phycrax[m] has quit [Quit: Idle timeout reached: 172800s]
sroemer has quit [Ping timeout: 276 seconds]
pcs38 has joined #rust-embedded
<JamesMunns[m]> Hello @room! It's about that time! We'll get started in ~5m for the meeting, if you'd like to add anything to the agenda, please do so at: https://github.com/rust-embedded/wg/discussions/841, or drop anything you'd like to announce or discuss!
<JamesMunns[m]> (I'm filling in for Adam this week as a reminder)
<JamesMunns[m]> @rmsyn if you're around I'll probably throw it to you first re: the SDIO hal discussion
<JamesMunns[m]> Okay, let's get started! First is rmsyn re: the SDIO HAL discussion: https://github.com/rust-embedded/wg/discussions/841#discussioncomment-13326668
<JamesMunns[m]> (do we have any hal team folks in the room?)
rmsyn[m] has joined #rust-embedded
<rmsyn[m]> working on the PoC implementation for `mmc` traits, @thebugadani:matrix.org suggested creating a new crate for the traits, instead of directly implementing them in `embedded-hal`
therealprof[m] has joined #rust-embedded
<therealprof[m]> I like the idea. Should make things a lot easier for all of us.
<therealprof[m]> I haven't really checked feasibility but it just came to my mind that maybe that would even be a model for the future to basically have new extensions developed out of tree, and given maturity pulled in as an external depedency and re-exported from embedded-hal?
<JamesMunns[m]> Yep, either re-exported, or upstream and then semver-trick back to the external crate for people that don't immediately change over
<JamesMunns[m]> (depending on whether there are breaking changes between "popularity outside" and "the api that gets merged into e-hal")
<JamesMunns[m]> Sounds good! Anything else to discuss on this?
<rmsyn[m]> not much, just whether I have the necessary permissions to create a `embedded-hal-sdmmc` crate in the `embedded-hal` workspace, or if I should just change the open PR to create the new crate, etc.
<rmsyn[m]> and whether more consensus from the other HAL team members is needed
<JamesMunns[m]> I'd probably say if you want to do it in the embedded-hal repo, you'd probably need to be a member of the e-hal team
<therealprof[m]> I think that would have a ton of benefits, including resulting in quicker benefits and not depending on the HAL team to have enough interest to constantly invest in progressing it in the official repo.
<JamesMunns[m]> the alternative is to do it outside of the e-hal repo
<therealprof[m]> rmsyn[m]: I'd say, start it externally, maybe as a rec project and we can discuss moving it over later.
<rmsyn[m]> JamesMunns[m]: right, if it comes to that I could add it to `rust-embedded-community`, or as a completely independent crate to potentially be upstreamed in the future
<therealprof[m]> rmsyn[m]: ... or as we said above, we could simply make it a dependency and add a re-export shim in e-h.
<rmsyn[m]> alright, that kind of makes sense with `embedded-sdmmc` (the driver crate) also being in `rec`
<JamesMunns[m]> Okay, sounds like the plan is "make a repo in rec or in your own space, follow up with merging into e-hal repo later, then later later merge/re-export to e-hal"
<JamesMunns[m]> @romancardenas if you're around, we'll jump to your topic shortly!
<JamesMunns[m]> Thank you for pushing this forward @rmsyn !
<JamesMunns[m]> (do we have any cortex-m team folks in the house?)
<JamesMunns[m]> sorry, cortex-a/r/m team folks :D
newam[m] has joined #rust-embedded
<newam[m]> I'm a little bit here :)
<JamesMunns[m]> Now up is Roman with some ready cortex-m PRs: https://github.com/rust-embedded/wg/discussions/841#discussioncomment-13358370
romancardenas[m] has joined #rust-embedded
<romancardenas[m]> Not very much to say! There are a couple of PRs that are ready to get reviewed :)
<romancardenas[m]> One deprecates the pre-init macro and the other introduces the famous cortex-m-pac crate for generic traits and error enums that can be used in the rest of the ecosystem
<therealprof[m]> Checking...
<JamesMunns[m]> (I see a couple of arm team folks here, I'll give it a few minutes to let people read and bring up discussion topics...)
<therealprof[m]> jannic just added a comment to the second PR. I merged the first.
<thalesfragoso[m]> Also, it's quite an extension from Adam's PR, I think feedback from him would be good.
<romancardenas[m]> Will wait for his feedback!
<romancardenas[m]> jannic: what do you mean by MAX_EXCEPTION_NUMBER being strange?
jannic[m] has joined #rust-embedded
<jannic[m]> I already updated the comment. Misunderstood the purpose.
<romancardenas[m]> Oh, sorry! I'll check it
jistr has quit [Ping timeout: 252 seconds]
<romancardenas[m]> I will work on your comments and push them ASAP
<JamesMunns[m]> Then @jannic, you'll be up shortly for the triage topic, unless there are any more discussion points re: cortex-m
<JamesMunns[m]> I appreciate folks taking time to review Roman's PRs!
<jannic[m]> I looked at older PRs on embedded-hal. I think the four I listed can be closed. I gave reasons in https://github.com/rust-embedded/wg/discussions/841#discussioncomment-13358474
bartmassey[m] has joined #rust-embedded
<bartmassey[m]> I have to go to class as usual. Thanks jannic for all the triage, and everyone else for the cool stuff.
<JamesMunns[m]> any potentially contentious points? It looks like most of the PRs are pretty conclusively out of date?
jistr has joined #rust-embedded
<jannic[m]> I don't see any value in keeping them open. TriStatePin might still be nice to have, but the merge request itself is no longer useful.
<therealprof[m]> TriStatePin has lots of troubles.
<jannic[m]> Not arguing that. There's probably a reason it wasn't merged back then.
<JamesMunns[m]> @therealprof do you want to swing the sword and do the closing for these four PRs?
<JamesMunns[m]> And then maybe a last call for any topics, if anyone has any last minute agenda topics :)
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> Okay, I think we're about done then! Thanks everyone for being here, and I hope y'all have a good week!
<therealprof[m]> <JamesMunns[m]> "@therealprof do you want to..." <- Issues have been closed.
danielb[m] has joined #rust-embedded
<danielb[m]> <rmsyn[m]> "working on the PoC implementatio..." <- who's that tag lol, i want my name back
<therealprof[m]> JamesMunns[m]: Thanks for running.
zaven[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
<thejpster[m]> Well this PR is getting out of control: https://github.com/rust-embedded-community/pc-keyboard/pull/52/files
<thejpster[m]> Hopefully it's worth it in the end