ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <firefrommoonlight> Yes
<re_irc> <firefrommoonlight> You can add the tag wherever
<re_irc> <yruama_lairba> is there other doc tag like that ?
<re_irc> <yruama_lairba> firefrommoonlight: i was only missing the deprecated attribute
inara has quit [Quit: Leaving]
inara has joined #rust-embedded
explore has joined #rust-embedded
<re_irc> <Clark Kozak> hey y'all, where does this nb come from?
<re_irc> my best guess is the microbit hal though i checked their doc and couldn't find it
<re_irc> <Clark Kozak> thank you
<re_irc> <Clark Kozak> ...what does it do I don't really understand
ymwm has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
ymwm has quit [Quit: Leaving]
jackneillll has quit [Read error: Connection reset by peer]
jackneilll has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
Guest2 has joined #rust-embedded
<re_irc> <gauteh> Clark Kozak: "nb::block" just busy-waits on a function that returns a result or a "WouldBlock". So you could also use that to do other work while the function is returning WouldBlock. Its a way to create code that can be both blocking and non-blocking.
Guest2 has quit [Quit: Client closed]
Guest2 has joined #rust-embedded
ymwm has joined #rust-embedded
ymwm_ has joined #rust-embedded
ymwm has quit [Ping timeout: 240 seconds]
<re_irc> <olaoni> writing documentation for myself and a bit confused when I use the following crate in my Cargo.toml dependencies
<re_irc> "stm32h7xx-hal = {version = "0.11.0", features = ["stm32h743v", "rt"]}"
<re_irc> Don't I have to first download and build _ repo_ first? The reason I am asking is that I have removed this repo from my system and my standalone code still builds, even though I thought I am removing the crate from .cargo/registry/cache/
<re_irc> <olaoni> * builds for stm32h743,
<re_irc> <K900> Cargo will fetch it again if necessary
<re_irc> <olaoni> Cool thanks
<re_irc> <Clark Kozak> gauteh: Yeah the microbit display nonblocking example is a good example. I like this! Thank you so much
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
explore has joined #rust-embedded
Guest2 has quit [Ping timeout: 256 seconds]
ymwm_ has quit [Ping timeout: 256 seconds]
<re_irc> <adamgreig> hi room , meeting time again! we'll start in 5 minutes, agenda link coming in a sec
<re_irc> <adamgreig> agenda is, please add anything you'd like to announce or discuss :)
<re_irc> <heksa> I'm curious. How does this work? Do you do the Matrix voice/video call or just simultaneous present and chat?
<re_irc> <adamgreig> we all just chat here
<re_irc> <adamgreig> no audio/video component, typically (on very rare occasion such a thing is specially organised, usually for a specific team or discussion)
<re_irc> <adamgreig> ok, let's go! it's been quite a quiet week (not for me, I'm moving house and have barely touched a computer the last four days...)
<re_irc> <adamgreig> first announcement is that newam is now part of the cortex-m team 🎉
<re_irc> <adamgreig> that was also my only announcement, so if anyone else has anything to mention or that might be of interest please shout :)
<re_irc> <heksa> Thought I should put it out there that we've got a bunch of people working on RISC-V SoC hardware and software at our univ. including Rust. I'm hoping we can produce some outputs for RISC-V interrupts & PLIC things in the next year or two.
<re_irc> <adamgreig> cool, sounds good! please keep us updated :)
<re_irc> <adamgreig> for cortex-m, the PR swapping to the newly stable "asm" macro is merged, and a new PR prepping a semihosting release using it is open:
<re_irc> <adamgreig> after that, we can think about a release of cortex-m and cortex-m-rt using the new macros
<re_irc> <adamgreig> cortex-m will be 0.8 anyway, but not sure if cortex-m-rt should be a bump or not, since it's not technically a breaking change and we don't have any other breaking changes
<cr1901> My policy is to not bump if no reason
<cr1901> But once you do bump, bump to the same version number
<re_irc> <therealprof> Sounds bumpy. 😉
<re_irc> <adamgreig> it does include a big increase in MSRV, is the only reason I might consider 0.8
<re_irc> <adamgreig> but in practice it causes a lot of strife because the PACs all depend on cortex-m-rt directly
<re_irc> <dirbaio> PAC major bumps cause more strife because the singletons
<re_irc> <dirbaio> I'd avoid bumping maybe
<re_irc> <adamgreig> I think even without any singletons it would still be troublesome
<re_irc> <adamgreig> the HALs still depend on PACs, cortex-m-rt can't be used twice, so the end user crate can't update c-m-rt until their HAL does which can't until the PAC does, etc
<re_irc> <adamgreig> and zero point doing the semver hack for c-m-rt since then 0.7 users would have their msrv bumped anyway
<re_irc> <adamgreig> so yes, I'm inclined towards making it 0.7.2
<re_irc> <therealprof> Agreed.
<re_irc> <newam> in terms of user experience I think a 0.0.x bump would be less disruptive, the new "rust-version" field will _hopefully_ help resolve problems with people not yet on 1.59
<re_irc> <adamgreig> for those users on a new enough version of rust anyway :P
<re_irc> <adamgreig> ok, I'll prep a PR for that after 424
<re_irc> <adamgreig> I don't think there's been much activity on embedded-hal this week, anything to discuss there?
<re_irc> <therealprof> I thought I saw a few comments fly by but I was also distracted. 😅
<re_irc> <dirbaio> nothing from me, haven't had time to hack on it this week
<re_irc> <dirbaio> async spi is mostly OK pending some nits
<re_irc> <dirbaio> and I still want to give the bus/device idea on i2c a try
<re_irc> <burrbull> I've made some experiments with "OutputPort" yesterday
<re_irc> <burrbull> also remind about I'd want to have it before release
<re_irc> <adamgreig> 👍️ oh, yea, I'll see if I can find time to try that in the next day or two
<re_irc> <adamgreig> cool, anything else wg related?
<re_irc> <adamgreig> guess that's it for this week then, thanks everyone!
<re_irc> <dirbaio> that was one quiet meeting :D
<re_irc> <adamgreig> we'll have to cook up some contentious new design concept for next week :P
<re_irc> <dirbaio> RFC: deprecate "nb"
<re_irc> <dirbaio> 🔥
<re_irc> <adamgreig> 💀
<re_irc> <therealprof> 😀
<re_irc> <dirbaio> (I'm joking, just in case it's not obvious)
<re_irc> <adamgreig> sure you are
<re_irc> <dirbaio> maybe 5 years from now, when async traits are stable
<re_irc> <therealprof> Pretty sure deprecating "nb" will see a ton of support.
<re_irc> <burrbull> 5 years later: GATs is almost ready
<re_irc> <dirbaio> GAT, TAIT, async-fn-in-trait, async closures
<cr1901> tait?
<cr1901> type ascriptin in?
<re_irc> <dirbaio> type-alias-impl-trait
<cr1901> ahhh
<re_irc> <chrysn (> at least GATs will be stabilized before never :-)
<re_irc> <therealprof> Never say never unless you mean it! 😉
<re_irc> <therealprof> !
<re_irc> <therealprof> ... and I do mean it. 😀
<re_irc> <dirbaio> currently, to define an async trait, you need just GAT:
<re_irc> <dirbaio> TAIT is what allows you to do "type X = impl Future"
<re_irc> <dirbaio> so you can return the future from an "async fn" or an "async{}"
<re_irc> <dirbaio> you can avoid TAIT if you implement "Future" by hand, which sucks
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
<re_irc> <thejpster> Has anyone tried lapce?
<re_irc> <thejpster> I've been stuck in VS Code for work. Rust Analyzer is great, and Remote SSH support is brilliant (and very necessary for this piece of work) but it's never what I would call nippy. I did fire up Sublime Text 4 for another job, but VS Code has outclassed it now in terms of plugins.
<re_irc> <thejpster> But this looks really interesting.
<re_irc> <firefrommoonlight> No. What are your thoughts? IntelliJ Rust is outstanding as an editor, but it is so slow and memory intensive, I'm considering an alternative. Maybe
<re_irc> <firefrommoonlight> *It periodically locks up on my Surface Pro tablet etc. So frustrating!
<re_irc> <firefrommoonlight> Mostly OK on the desktop, but that's no excuse!
<re_irc> <firefrommoonlight> *Despite my lamenting about this, it's IMO so far above anything else I've tried, that I think it's unlikely I'll switch in the near future
<re_irc> <firefrommoonlight> * performance, its code introspection and refactoring are
<re_irc> <dirbaio> vscode is quite on par with intellij
<re_irc> <dirbaio> and less heavyweight I'd say
<re_irc> <firefrommoonlight> I use VsCode for 1-off files since IntelliJ's paradigm is project oriented. I respectfully disagree there
<re_irc> <firefrommoonlight> I've really tried to use it as a replacement, eg when out of town and on a laptop that intelliJ destroys
<re_irc> <dirbaio> what things do you find intellij is better? :o
<re_irc> <firefrommoonlight> But can never do it. It's not one thing; it's a slew of useful features IntelilJ can do related to understanding the language, how different project files work together etc
<re_irc> <dirbaio> rust-analyzer is shockingly good imo
<re_irc> <firefrommoonlight> Changing struct/var/module etc names. Finding the source of a given object. Catching errors before I compile
<re_irc> <firefrommoonlight> Moving things between files
<re_irc> <dirbaio> RA does all these
<re_irc> <dirbaio> hm, maybe not moving
<re_irc> <firefrommoonlight> AFAIK, VsCode/RA have no concept of a multi-file project
<re_irc> <firefrommoonlight> (Unless I'm missing something!)
<re_irc> <dirbaio> it finds Cargo.toml files as "top-level" crates, and parses the whole crate tree as if you compiled the top-level crate
<re_irc> <firefrommoonlight> *I guess that's not quite true
<re_irc> <dirbaio> so navigation, find references etc do work across files and across crates
<re_irc> <firefrommoonlight> *Experimenting now
<re_irc> <firefrommoonlight> Seems hit/miss
<re_irc> <firefrommoonlight> So, "Go to definition" is working here:
<re_irc> <firefrommoonlight> use crate::flight_ctrls::Rotor;
<re_irc> const DUTY_HIGH: u32 = crate::DSHOT_ARR * 3 / 4;
<re_irc> <firefrommoonlight> But not here:
<re_irc> <firefrommoonlight> directly below it
<re_irc> <dirbaio> 🤔
<re_irc> <dirbaio> it needs a bit of configuration if you mix embedded/non-embedded code in the same repo, or if you have cfg's (setting target, features)
<re_irc> rotor_timer_a.set_prescaler(DSHOT_PSC);
<re_irc> <firefrommoonlight> Not working here:
<re_irc> <firefrommoonlight> to find "set_prescaler" for example
<re_irc> <firefrommoonlight> in the main file
<re_irc> <firefrommoonlight> This is jsut within the same project; not even deps'
<re_irc> <firefrommoonlight> And it can't seem to find deps at all.
<re_irc> <firefrommoonlight> PyCharm/IntelliJ just work
<re_irc> <dirbaio> all that should definitely work
<re_irc> {
<re_irc> "editor.formatOnSave": true,
<re_irc> <dirbaio> try this in ".vscode/settings.json":
<re_irc> "rust-analyzer.assist.importEnforceGranularity": true,
<re_irc> <firefrommoonlight> I keep getting the feeling I'm missing something, given VsCode is popular with Rust, but I can never get it to work :/
<re_irc> <firefrommoonlight> Also, not sure how to have multiple projects open with it
<re_irc> <firefrommoonlight> (Again, I like it as a _single file_ editor)
<re_irc> <dirbaio> you can open multiple projects if you set multiple crates into "linkedProjects"
<re_irc> <dirbaio> or if you make a Cargo workspace and add that to "linkedProjects" instead of the individual crates
<re_irc> <dirbaio> you can open multiple cratesif you set multiple crates into "linkedProjects"
<re_irc> <firefrommoonlight> Thanks - I'll look into this stuff
<re_irc> <dirbaio> you can open multiple crates if you set multiple crates into "linkedProjects"
<re_irc> <firefrommoonlight> If I can get it sorted, will switch on teh laptop at leaset
<re_irc> <dirbaio> the only thing that doesn't work is opening multiple crates for different targets at the same time
<re_irc> <dirbaio> like, one for std and one for thumbv7
<re_irc> <dirbaio> you can do that with two ".code-workspace" files with different settings, you can open both in separate windows at the same time
<re_irc> <firefrommoonlight> *and re "less heavyweight than IntelliJ" Much so on my end!
<re_irc> <firefrommoonlight> IntelliJ is such a pig
<re_irc> <firefrommoonlight> Seems quite worse with teh rust Plugin than with its native Python caps btw
<re_irc> <dirbaio> also intellij still doesn't work fine with wayland/sway
<re_irc> <firefrommoonlight> *I'll go through all your tips here and see if I can get them working
ymwm_ has joined #rust-embedded
dne has quit [Read error: Connection reset by peer]
darknighte has quit [Read error: Connection reset by peer]
dne has joined #rust-embedded
darknighte has joined #rust-embedded
SanchayanMaity has quit [Read error: Connection reset by peer]
SanchayanMaity has joined #rust-embedded