<re_irc>
<@thalesfragoso:matrix.org> Otherwise, using RefCell here and there is mostly unnoticed
troth has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> The problem arises when I want to store all elements (i2c, drivers). Then the values are moved and the references get invalid.
sauce has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> thalesfragoso:matrix.org: You can't have the drivers own a `&mut MyI2cBus` either unless you want to recreate each driver every time
Foxyloxy has quit [Ping timeout: 256 seconds]
<re_irc>
<@dirbaio:matrix.org> grantm11235:matrix.org: I think thalesfragoso means take the &mut at every driver operation
<re_irc>
<@sourcebox:matrix.org> Exactly.
<re_irc>
<@thalesfragoso:matrix.org> sourcebox:matrix.org: Do you mean moving all to the same place ? I.e. self-referential ?
<re_irc>
<@sourcebox:matrix.org> Yes.
<re_irc>
<@thalesfragoso:matrix.org> I would really avoid that
<re_irc>
<@thalesfragoso:matrix.org> And `static mut` won't really help with self-referential stuff
<re_irc>
<@thalesfragoso:matrix.org> Pretty much the same thing as a &'a RefCell, since you will probably need a &mut in the end
<re_irc>
<@thalesfragoso:matrix.org> The only plus os that you don't have an 'a everywhere
<re_irc>
<@thalesfragoso:matrix.org> I don't think you can put a RefCell on a forever though
<re_irc>
<@dirbaio:matrix.org> thalesfragoso:matrix.org: ofc you can lol
<re_irc>
<@dirbaio:matrix.org> also with refcell you can still run into self-referential problems if you want to put the i2c and the drivers in the same struct
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: Don't you need it to be Sync ?
<re_irc>
<@dirbaio:matrix.org> No, it's only accessible by the thread that .put() it there
<re_irc>
<@thalesfragoso:matrix.org> Or no, of course, it only gives it once
<re_irc>
<@dirbaio:matrix.org> (unless you steal from it, but that's unsafe)
<re_irc>
<@thalesfragoso:matrix.org> Yeah, not sure why I thought it was a static instead of a static mut, heh
sheb has quit [Ping timeout: 240 seconds]
<re_irc>
<@sourcebox:matrix.org> My overall concern is: I will manage to get it work somehow, but it's for sure that I will never understand it again when I have a look at it later.
<re_irc>
<@grantm11235:matrix.org> You will also need to impl the i2c traits for `&'a RefCell<impl I2cTraits>`
<re_irc>
<@thalesfragoso:matrix.org> Just run from self-referential, don't try to put everything at the same place if there are references
<re_irc>
<@thalesfragoso:matrix.org> You will never be able to do self-referential with references
<re_irc>
<@thalesfragoso:matrix.org> Doing with raw pointers is possible, but really sad to make it safe
<re_irc>
<@dirbaio:matrix.org> pfffft, just use `Pin` and lots and lots of `unsafe` ☠️
<re_irc>
<@thalesfragoso:matrix.org> Yeah, even with Pin, you need raw potatoes
<re_irc>
<@sourcebox:matrix.org> Therefore I made the I2C static so I can put references to it.
<re_irc>
<@thalesfragoso:matrix.org> I mean pointers
<re_irc>
<@dirbaio:matrix.org> raw potatoes 🤣
<re_irc>
<@dirbaio:matrix.org> 🥔
<re_irc>
<@thalesfragoso:matrix.org> sourcebox:matrix.org: Even if it's static, it isn't in the same struct, so not sure why static is helping you
<re_irc>
<@thalesfragoso:matrix.org> At most it gets rid of 'a
<re_irc>
<@sourcebox:matrix.org> But I need more than one &mut and that doesn't work,
<re_irc>
<@thalesfragoso:matrix.org> sourcebox:matrix.org: That doesn't work even with static mut, I mean, you can get it, but it's insta-UB
<re_irc>
<@grantm11235:matrix.org> type Error = T::Error;
<re_irc>
<@dirbaio:matrix.org> that might work for i2c, but it'll interact badly with SPI chipselects
<re_irc>
<@grantm11235:matrix.org> Yeah, just for i2c I mean
<re_irc>
<@dirbaio:matrix.org> I'd say it's better to leave it for external crates then? like shared-bus
<re_irc>
<@firefrommoonlight:matrix.org> grantm11235:matrix.org: Or just don't do it
<re_irc>
<@sourcebox:matrix.org> static RefCell does also not work because it's not Sync.
<re_irc>
<@dirbaio:matrix.org> `static Forever<RefCell<YourSpi>>` does work
<re_irc>
<@sourcebox:matrix.org> Is there any solution without external dependencies?
<re_irc>
<@dirbaio:matrix.org> `static mut MaybeUninit<RefCell<YourSpi>>` does work too, but you have to use unsafe just once, to init it in main
<re_irc>
<@dirbaio:matrix.org> use unsafe to init it and get the `&'static RefCell<YourSpi>`
<re_irc>
<@dirbaio:matrix.org> once you've done that, no more unsafe is needed, just share the `&'static RefCell<YourSpi>`
<re_irc>
<@dirbaio:matrix.org> you could also make it static with `Box::leak` but that requires alloc
<re_irc>
<@dirbaio:matrix.org> if you're using alloc you could also use `Rc<RefCell<YourSpi>>`
<re_irc>
<@dirbaio:matrix.org> or maybe copypaste `Forever` into your project, it's tiny
<re_irc>
<@james.acres:matrix.org> I'm about to embark on learning embedded with Rust. I settled on an stm32f407 discovery board and just received it, but saw that the book is being rewritten for microbit v2. Is it worth swapping it out before beginning?
<re_irc>
<@adamgreig:matrix.org> the original book is written for an f3 discovery board which won't be a perfect match for your f4 either anyway; having the exact right hardware might make things easier so you don't have to work out how to modify it for what you're running, and the f407 will probably be useful/interesting in the future as it's fairly powerful
<re_irc>
<@adamgreig:matrix.org> but, I wouldn't feel obliged to get a micro:bit either, you could try skimming through the books to get a feel for it? the old book is still valid
<re_irc>
<@adamgreig:matrix.org> in case you missed it, the new book is previewable on https://agg.io/u/discovery/microbit while we finish reviewing/merging
<re_irc>
<@james.acres:matrix.org> thanks Adam. I think I'll try and power through it to get the f407 up and running with the examples or whatever I can make as an equivalent given different peripherals
<re_irc>
<@adamgreig:matrix.org> the stmf407 is a super classic microcontroller and the stm32f4xx-hal (https://github.com/stm32-rs/stm32f4xx-hal) has a lot of examples for using it
<re_irc>
<@james.acres:matrix.org> Oh nice! Thanks, I'll refer to these, too. Thanks for the help
sheb has joined #rust-embedded
sheb has quit [Remote host closed the connection]
sheb has joined #rust-embedded
<re_irc>
<@antonok:antonok.com> This was announced today; might be interesting to folks here: https://oxide.computer/blog/hubris-and-humility. The folks at Oxide are building out a new embedded OS framework and debugging system with some unique ideas
<re_irc>
<@firefrommoonlight:matrix.org> I look forward to giving it a try if I do something complicated enough
<re_irc>
<@firefrommoonlight:matrix.org> My current projects aren't... ambitious? enough to warrant any sort of OS beyond what you can do with RTIC, for example
<re_irc>
<@antonok:antonok.com> I was actually going to give a shot at getting it running on an STM32F401 blackpill board. I've been using RTIC so far and I'm curious to see how things map over
<re_irc>
<@firefrommoonlight:matrix.org> I'm curious to see examples etc
<re_irc>
<@antonok:antonok.com> also, fwiw they have a #hubris slack channel at osfw.slack.com that was shared at the Open Source Firmware Conference today
<re_irc>
<@grantm11235:matrix.org> Would it be easier to move resources into interrupts if they were represented using closures?
<re_irc>
<@grantm11235:matrix.org> Oops, the closure needs to be `Send`, not `Sync`. Still works tho
<re_irc>
<@dirbaio:matrix.org> you could do a simpler version without the "scope" thing
<re_irc>
<@dirbaio:matrix.org> I think you'd need `feature(type_alias_impl_trait)` and maybe some macro magic to store the closure in a `static` though
<re_irc>
<@dirbaio:matrix.org> is it UB to transmute between `[u8; 16]` and `GenericArray<u8, U16>`?
<re_irc>
<@dirbaio:matrix.org> and between `&mut [u8; 16]` and `&mut GenericArray<u8, U16>`?
<re_irc>
<@jamesmunns:beeper.com> AFAIK, no, they should be guaranteed to be the same
<re_irc>
<@jamesmunns:beeper.com> I think I used to do that in bbqueue
<re_irc>
<@dirbaio:matrix.org> first one I believe so, but the second one seems a bit more cursed 🤔
<re_irc>
<@jamesmunns:beeper.com> though maybe it was inside of a MaybeUninit
<re_irc>
<@jamesmunns:beeper.com> How come?
<re_irc>
<@jamesmunns:beeper.com> Though doesn't GenericArray have some "from" methods that do exactly that?
<re_irc>
<@jamesmunns:beeper.com> They might be hidden behind some cursed trait interace
<re_irc>
<@jamesmunns:beeper.com> I feel like I've used that before for some of the RustCrypto stuff
<re_irc>
<@dirbaio:matrix.org> I haven't found a way to convert between `[u8; 16]` and `GenericArray<u8, U16>` without `.unwrap()` :S
<re_irc>
<@dirbaio:matrix.org> they probably get optimized away, but still, ugh
<re_irc>
<@jamesmunns:beeper.com> Lemme see if I can find where I used it
<re_irc>
<@dirbaio:matrix.org> and `.encrypt_block()` needs a `&mut GenericArray<u8, U16>` anyway >_<
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@tmplt:matrix.org> therealprof:matrix.org: Yes: ITM instumentation/extension packet arbitration at least. Making it easy to catch the `cortex_m::iprint("arbitrary message/payload"`" on the host side. This is non-trivial according to the spec.
<re_irc>
<@tmplt:matrix.org> adamgreig: I'm neutral on whether it ends up in the WG or not. I'll maintain it either way.
<re_irc>
<@tmplt:matrix.org> But I'll gladly take the `itm` crate name so that there is no confusion for end-users on what crate to use.
<re_irc>
<@tmplt:matrix.org> What are the downsides to keeping it in the WG? That I need someone else in the cortex-m team to sign off my PRs?
<re_irc>
<@tmplt:matrix.org> I can foresee some changes in the close future (be it to error enum granularity or better function names, more logical iterators, etc) that I'd prefer to release quickly. If the crate were to join the WG it may then be better to wait for the eventual v1.0.0 release, or do so if the crate becomes a somewhat common dependency.
<re_irc>
<@tmplt:matrix.org> At the moment that would hinge on the future popularity of `cargo-rtic-scope` and if some API is added to `probe-rs` that makes the library a hard dependency.
dcz_ has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> tmplt:matrix.org: Yes, no self-approval of PRs and all bigger decisions are subject to discussion and potentially voting.
<re_irc>
<@therealprof:matrix.org> (Of course also the WG best practises and requirements as well as the CoC do apply as well)
<re_irc>
<@therealprof:matrix.org> Not trying to sound negative here, just listing the implications. 😅 Depending on where you're standing some or even alll of the above might be viewed as a positive thing. And of course as a WG project is has the full backing of the team and good standing with the upstream Rust project.
dreamcat4 has joined #rust-embedded
<re_irc>
<@tmplt:matrix.org> therealprof:matrix.org: Best approach from my standpoint would be to replace the `itm` crate for now and keep it out of the WG until it has stabilized a bit. This would be Q1 next year at the earliest. After that we can resume the discussion on whether to move it to the WG.
troth has quit [Ping timeout: 256 seconds]
troth has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> tmplt: Can you open an RFC for that?
<re_irc>
<@sourcebox:matrix.org> dirbaio:matrix.org: I'm playing around with this now. I'd like to use a `RefCell<T>` but with static `RefCell<Option<T>>` is required because of the init. Is there a way to avoid that?
troth has joined #rust-embedded
<re_irc>
<@ryan-summers:matrix.org> You could wrap it in `MaybeUninit` or use const-fn inits
<re_irc>
<@sourcebox:matrix.org> I'm trying `MaybeUninit` currently. Still fighting how to use it.
<re_irc>
<@bugadani:matrix.org> lazy_static might also be something to look at?
<re_irc>
<@sourcebox:matrix.org> bugadani:matrix.org: Design goal is to minimize dependencies.
<re_irc>
<@bugadani:matrix.org> ctrl-c, ctrl-v 😅
<re_irc>
<@jamesmunns:beeper.com> sourcebox:matrix.org: Can I ask why?
<re_irc>
<@sourcebox:matrix.org> If I have `MaybeUninit<RefCell<T>>`, how do I get access to the RefCell.
<re_irc>
<@jamesmunns:beeper.com> I find a lot of people coming from other languages (esp. C and C++) try to do that, but it's a little atypical for Rust. Instead, we try to make sure that re-usable parts are contained and shared in crates.
<re_irc>
<@sourcebox:matrix.org> jamesmunns:beeper.com: Yes, but I try to avoid to have dependencies of small things that can be done directly in the code by the core library. There is also a security-related part on this.
<re_irc>
<@sourcebox:matrix.org> Supply-chain attacks are popular these days.
<re_irc>
<@jamesmunns:beeper.com> > I try to avoid to have dependencies of small things that can be done directly in the code by the core library
<re_irc>
<@jamesmunns:beeper.com> Rust's core library is pretty minimal, and especially doesn't try to touch anything related directly to embedded
<re_irc>
<@jamesmunns:beeper.com> > There is also a security-related part on this
<re_irc>
<@jamesmunns:beeper.com> That's fair, but Rust packages are also entirely source-based (which means you can audit them), you can pin versions or commit your lock file (so versions never change unless you manually update them), package integrity is checked with SHA-256 sums, stored in the lock file , and dead code is eliminated.
<re_irc>
<@jamesmunns:beeper.com> Especially for `unsafe` abstractions, I would highly recommend sticking with popular, well-audited crates.
<re_irc>
<@jamesmunns:beeper.com> but hey, I can't tell you to do or not do something, but sometimes it's useful to re-calibrate expectations when you are in a new environment.
<re_irc>
<@sourcebox:matrix.org> The essence is that noone will ever be able to audit the whole dependency tree.
<re_irc>
<@firefrommoonlight:matrix.org> I've been traumatized by both the Python package index and NPM. It could happen here too!!
<re_irc>
<@firefrommoonlight:matrix.org> (James' point about pinning versions and auditing, combined with careful selection of which deps you need mitigates this)
<re_irc>
<@jamesmunns:beeper.com> Yes, however all of those exploits are prevented by:
<re_irc>
<@jamesmunns:beeper.com> 1. auditing your dependencies, and don't use ones too big to audit
<re_irc>
<@jamesmunns:beeper.com> 2. pinning your dependencies
<re_irc>
<@jamesmunns:beeper.com> Especially in embedded, your tree is FAR less large and complex.
<re_irc>
<@firefrommoonlight:matrix.org> So, a key way to deal with this is to only use deps that have a small number of sub-deps
<re_irc>
<@firefrommoonlight:matrix.org> You get into trouble when *your dependencies have too many dependencies*
<re_irc>
<@firefrommoonlight:matrix.org> So, building a dependency graph only a few layers deep is fine
<re_irc>
<@sourcebox:matrix.org> Nevertheless reducing the number of dependecies is something I don't regard as a mistake.
<re_irc>
<@firefrommoonlight:matrix.org> But if one of the branches gets too long, you get into trouble
<re_irc>
<@jamesmunns:beeper.com> Take my advice for what you paid for it, but I think you will find you'll hit diminishing returns if you eschew dependencies entirely.
<re_irc>
<@jamesmunns:beeper.com> Anyway, good luck with your exploration. Just my $0.02.
<re_irc>
<@firefrommoonlight:matrix.org> It's a tradeoff, but I'm more of sourcebox's mindset
<re_irc>
<@jamesmunns:beeper.com> Like I said, you're welcome to do as you like. I'm not a consultant anymore, so who am I to be advising anyway :)
<re_irc>
<@firefrommoonlight:matrix.org> This is all heavily in subjectivity land
<re_irc>
<@firefrommoonlight:matrix.org> Ultimately there is no right answer!
<re_irc>
<@firefrommoonlight:matrix.org> Ie, I'm not "anti-dependency" or anything, but I agree with sourcebox that you should carefully consider if you need each dep
<re_irc>
<@firefrommoonlight:matrix.org> And recognize that the downsides to adding deps are subtle, and emergent as you add more
<re_irc>
<@sourcebox:matrix.org> The problem is, that the Rust package management is of course built with the best intentions in mind, but you can't imagine how creative people can get when they see a chance to abuse something for profit.
<re_irc>
<@firefrommoonlight:matrix.org> Security concerns aside, they can add headaches with changing APIs, DSLs, and mutual incompatibility
<re_irc>
<@firefrommoonlight:matrix.org> And the workarounds for their limitations might be comparable to or greater than not using them
<re_irc>
<@bugadani:matrix.org> Technically you can hide exploits in the standard library as well, and you can't even pin the version of that.
<re_irc>
<@sourcebox:matrix.org> BTW: the Rust ecosystem is also one of the main reasons I'm trying to get into it. It's only about keeping it reasonable managable.
<re_irc>
<@jannic:matrix.org> LOL, the discussion reminded me of `cargo-crev`, which intends to help solving the code review issue for dependencies. However, `cargo install cargo-crev` starts with downloading and compiling 439 dependencies :-)
<re_irc>
<@sourcebox:matrix.org> I do C++ embedded for a living and try to convince colleagues to have a look into Rust. Dependency hell is of those things that they don't like.
<re_irc>
<@sourcebox:matrix.org> therealprof:matrix.org: Tools like this are really needed and can improve security a lot.
<re_irc>
<@sourcebox:matrix.org> But I think with Rust becoming more and more popular there is a limit of what can be reviewed in an aceptable time period.
<re_irc>
<@bugadani:matrix.org> I'm pretty sure developing everything from scratch takes more effort, especially when security is important.
<re_irc>
<@sourcebox:matrix.org> There is no need to redo everything from scratch, it's more about reducing dependencies by having the essential parts in fewer crates.
<re_irc>
<@sourcebox:matrix.org> E.g. the `num-traits` crate has so many dependents that I'm asking myself if having the stuff in the core library would not make sense.
<re_irc>
<@sourcebox:matrix.org> According to crates.io 1795 crates use `num-traits`.
<re_irc>
<@bugadani:matrix.org> what do you mean? num-traits literally has a single optional dependency
<re_irc>
<@sourcebox:matrix.org> The other way around.
<re_irc>
<@bugadani:matrix.org> oh, dependents, sorry, my bad
<re_irc>
<@bugadani:matrix.org> I promise I can read, most of the time
<re_irc>
<@grantm11235:matrix.org> sourcebox:matrix.org: Once something is in the core library, you basically can't make breaking changes to it anymore
<re_irc>
<@sourcebox:matrix.org> There's also another aspect: with C++, you basically learn the language, STL is not of much use for embedded anyway. With Rust, you have to learn a lot more in addition to get something running.
<re_irc>
<@grantm11235:matrix.org> The only breaking change that `num-traits` has had is adding an `std` feature (which wouldn't be needed if it was in the standard library), but the point remains that they *could* release a new breaking version if they needed to.
<re_irc>
<@sourcebox:matrix.org> My personal goal is to be able to get some small project running with Rust during next year. I'm not sure if I manage to do this yet.
<re_irc>
<@firefrommoonlight:matrix.org> AdamGrieg told me what a register was a year ago, and now I'm selling stuff
<re_irc>
<@firefrommoonlight:matrix.org> This is entirely doable
<re_irc>
<@sourcebox:matrix.org> For me, it's currently a bit frustrating and I often think that I'm too stupid for it.
<re_irc>
<@sourcebox:matrix.org> One of my main problems is that the architecture I'm used to in C++ does not translate to Rust and I don't find the corresponding alternatives.
<re_irc>
<@firefrommoonlight:matrix.org> Feel free to ask Qs etc or post your project requirements
<re_irc>
<@sourcebox:matrix.org> Most of the examples I found on the web are quite simple and fall apart when it comes to real world situations.
<re_irc>
<@firefrommoonlight:matrix.org> I've noticed the same
<re_irc>
<@firefrommoonlight:matrix.org> I think the root cause is the OSS rust embedded community is v small
<re_irc>
<@sourcebox:matrix.org> E.g. in C++ I'm used to have class `Board` which is in fact a container for everything that I can access on it, like buttons, LEDs, flash chip.
<re_irc>
<@firefrommoonlight:matrix.org> You could make a struct Board if you want. Not the approach I use, but doable
<re_irc>
<@sourcebox:matrix.org> This board class in C++ is a static singleton, so there is no problem with referencing the members
<re_irc>
<@firefrommoonlight:matrix.org> A common convention with OSS Rust embedded is peripheral structs that handle initialization, config, operations etc using fields and methods
<re_irc>
<@firefrommoonlight:matrix.org> You don't have to use that, but it's worth trying
<re_irc>
<@sourcebox:matrix.org> The projects I usually work on have a lot of buttons, leds and other stuff, so I think it makes sense to group that.
<re_irc>
<@firefrommoonlight:matrix.org> So, you have a variable for each peripheral you use, and these live statically, with some sort of guard like a Mutex or the RTIC framework
<re_irc>
<@firefrommoonlight:matrix.org> Would representing the buttons etc as struct fields work?
<re_irc>
<@sourcebox:matrix.org> For LEDs, I often put them into an array, so I can iterate over them.
<re_irc>
<@firefrommoonlight:matrix.org> Hmm... I haven't used Rust arrays for things beyond numbers
<re_irc>
<@firefrommoonlight:matrix.org> But ... I think you could do the same thing here (?)
<re_irc>
<@firefrommoonlight:matrix.org> In practice, I usually handle button operations directly as interrupt sources, but that isn't appropriate for all uses
<re_irc>
<@sourcebox:matrix.org> E.g. with LEDs, when you have a matrix with 10+ of them and these are used to illuminate buttons, you sometimes want to make them blink. And they should blink in sync, otherwise the user will go crazy.
<re_irc>
<@firefrommoonlight:matrix.org> Use a hardware timer for that
<re_irc>
<@firefrommoonlight:matrix.org> How you create these abstractions is up to you, and depends on the details of your project
<re_irc>
<@sourcebox:matrix.org> We are talking about lots of LEDs and buttons. More than you have timers.
<re_irc>
<@sourcebox:matrix.org> Sometimes even using DMA to provide soft pwm for individual brightness control.
<re_irc>
<@firefrommoonlight:matrix.org> So, in this case, you might have a state of which buttons are active. Maybe an atomic integer that represents each LED as a bit. Or some abstraction. Then you have a timer ISR that toggles all LEDs marked active when it runs
<re_irc>
<@firefrommoonlight:matrix.org> If you are trying to sync the LEDs as you said, you only need/want 1 timer
<re_irc>
<@sourcebox:matrix.org> For this I don't use timers and ISRs at all. This is because I reserve these things for the really important parts.
<re_irc>
<@firefrommoonlight:matrix.org> Systick then
<re_irc>
<@firefrommoonlight:matrix.org> Or pick a MCU with more timers
<re_irc>
<@sourcebox:matrix.org> Yes, SysTick-
<re_irc>
<@firefrommoonlight:matrix.org> Or cleverly use the timers for multiple things
<re_irc>
<@sourcebox:matrix.org> LED blinking is not something that has to be precise, so driving it depending on SysTick is more than enough for this purpose.
<re_irc>
<@jamesmunns:beeper.com> they are a guided walk-through of non-trivial projects, from scratch.
<re_irc>
<@firefrommoonlight:matrix.org> That looks cool
<re_irc>
<@jamesmunns:beeper.com> I'd also suggest that if you try to "write C++ in Rust", you are likely to run into an impedance mismatch. We definitely do things differently in Rust! But the way we do things are (generally) pretty well documented, either in code, or in written materials, like https://docs.rust-embedded.org/
<re_irc>
<@sourcebox:matrix.org> James Munns: I already had a quick look into some of your stuff.
<re_irc>
<@jamesmunns:beeper.com> Hopefully you don't mean my personal stuff, because that's hopelessly complex and undocumented :)
<re_irc>
<@jamesmunns:beeper.com> Though Ferrous' stuff is generally pretty good!
<re_irc>
<@sourcebox:matrix.org> I am aware that trying to write Rust like C++ is not the way to go.
<re_irc>
<@sourcebox:matrix.org> My C++ stuff is not the must advanced thing ever. It just works, mainly because the compiler does not do any checks and I'm self-disciplined enough to keep it in a managable state.
<re_irc>
<@sourcebox:matrix.org> So I'm trying to find out how to do it better in Rust. This is where I struggle.
<re_irc>
<@sourcebox:matrix.org> Besides of trying to get into embedded with Rust, I'm also doing some GUI apps like this: https://github.com/sourcebox/dfu-buddy
<re_irc>
<@firefrommoonlight:matrix.org> You are likely already familiar with most of the concepts
<re_irc>
<@sourcebox:matrix.org> I have to say that these GUI stuff is way more easy to do than embedded, even with less knowledge.
<re_irc>
<@sourcebox:matrix.org> firefrommoonlight:matrix.org: I read this article and found it very good. It is one of the best articles describing the current state.
<re_irc>
<@firefrommoonlight:matrix.org> I appreciate the feedback
<re_irc>
<@sourcebox:matrix.org> It was the first article I found that I can forward to someone who is interested to know where we currently are.
<re_irc>
<@sourcebox:matrix.org> James Munns: As I said, in C++ I usually use a board class with members representing the components on the board. Is this concept reasonable in Rust too?
<re_irc>
<@jamesmunns:beeper.com> It's reasonable, but generally not as a global singleton
<re_irc>
<@jamesmunns:beeper.com> Well, not stored at global/static scope
<re_irc>
<@jamesmunns:beeper.com> but rather created as part of your initialization code, and passed around as necessary
<re_irc>
<@sourcebox:matrix.org> Ok, in `main` I do a `Board::take()` like with peripherals.
<re_irc>
<@jamesmunns:beeper.com> Yeah, something like that!
<re_irc>
<@jamesmunns:beeper.com> I think the dwm1001 crate does that, let me find you an example
<re_irc>
<@jamesmunns:beeper.com> In general, you would want to use atomics for the tracking variable, or ensure you are using a critical section for that.
<re_irc>
<@jamesmunns:beeper.com> That code is unsafe because it contains a potential data race.
<re_irc>
<@jamesmunns:beeper.com> You could have an interrupt call it between line 3 and 7, which would allow you to obtain two copies of the board.
<re_irc>
<@sourcebox:matrix.org> But it's called only once at the start of main().
<re_irc>
<@jamesmunns:beeper.com> Rust doesn't like "it's safe if you hold it right"
<re_irc>
<@bugadani:matrix.org> if it's only called once, you don't need any of the runtime checks
<re_irc>
<@sourcebox:matrix.org> i know.
<re_irc>
<@jamesmunns:beeper.com> In general: mutable statics are something to avoid entirely
<re_irc>
<@sourcebox:matrix.org> BTW: this code is taken from some example, I think it was an official one.
<re_irc>
<@jamesmunns:beeper.com> If you link me to that example, I will fix it.
<re_irc>
<@jamesmunns:beeper.com> (assuming you are not using a thumbv6 target, which has no atomics, in which case, you might want the `atomic-polyfill` crate)
<re_irc>
<@sourcebox:matrix.org> I don't find the source of it anymore, but this seems to be the least important problem in my code.
<re_irc>
<@sourcebox:matrix.org> With this approach, the board variable is not static. This means, that any reference to a member inside is not possible.
<re_irc>
<@sourcebox:matrix.org> I mean from inside it.
<re_irc>
<@jamesmunns:beeper.com> You can have references, just not `'static` references.
<re_irc>
<@jamesmunns:beeper.com> Do you mean a self-referential struct?
<re_irc>
<@sourcebox:matrix.org> Yes.
<re_irc>
<@jamesmunns:beeper.com> In general, Rust doesn't do self-referential structs, as all types are trivially move-able, which would invalidate the self-reference
<re_irc>
<@bugadani:matrix.org> For the other cases, you have Pin
<re_irc>
<@jamesmunns:beeper.com> I don't believe Pin allows you to have self-referential structs, either.
<re_irc>
<@bugadani:matrix.org> no but at least you can have pointers and be sure they will be valid
<re_irc>
<@jamesmunns:beeper.com> sourcebox in general, it can be very useful to "break apart" large structs like that, for exactly this reason.
<re_irc>
<@sourcebox:matrix.org> Ok, inside my board class I have an LED as member. This LED needs to have a reference to a driver (shift register). Where should this driver live?
<re_irc>
<@firefrommoonlight:matrix.org> jamesmunns:beeper.com: I don't agree with this
<re_irc>
<@jamesmunns:beeper.com> firefrommoonlight:matrix.org: You do you, but I'd go so far to say that mutable statics should be removed from the language.
<re_irc>
<@jamesmunns:beeper.com> they are almost universally a foot gun
<re_irc>
<@ryan-summers:matrix.org> I mean, they're necessary to build safe abstractions around... but otherwise, I agree
<re_irc>
<@jamesmunns:beeper.com> You should almost always use something like UnsafeCell, or something similar that makes it more clear that there will be spooky action at a distance
<re_irc>
<@firefrommoonlight:matrix.org> I don't know how else you expect to do things like circular DMA
<re_irc>
<@dirbaio:matrix.org> I don't agree with removing `static mut`. The proposed alternatives like `RacyCell` are equally ultra-unsafe.
<re_irc>
<@jamesmunns:beeper.com> At least they properly use UnsafeCell, which makes it clear to the optimizer that it can trust nothing, and is less likely to emit UB from correct-looking unsafe code
<re_irc>
<@jamesmunns:beeper.com> sourcebox:matrix.org: You might consider having your driver own the shift register, taking a (mutable) reference on actions, or use an abstraction like `shared-bus` to safely share it between all LEDs.
<re_irc>
<@dirbaio:matrix.org> `static mut` already has an "implied" UnsafeCell kinda
<re_irc>
<@dirbaio:matrix.org> there's literally zero instances where a code using `static mut` is incorrect but the equivalent code using `RacyCell` is correct
<re_irc>
<@dirbaio:matrix.org> they're both the same
<re_irc>
<@sourcebox:matrix.org> The LED takes something that implements OutputPin, whatever that is. And this thing has to have a mutable reference to the shift register.
<re_irc>
<@jamesmunns:beeper.com> sourcebox:matrix.org: OutputPin is a trait (like an interface, or more like a Concept in modern C++)
<re_irc>
<@sourcebox:matrix.org> So the shift register has to live somewhere. This is where I started some hours ago.
<re_irc>
<@bugadani:matrix.org> sourcebox: you might want to invert your design, create a led driver that wraps the register and pass Led objects to it when you want to do something
<re_irc>
<@bugadani:matrix.org> in this case, leds wouldn't implement OutputPin at all
<re_irc>
<@dirbaio:matrix.org> sourcebox:matrix.org: you stick the shift register driver in a `static` like I told you yesterday
<re_irc>
<@dirbaio:matrix.org> either using unsafe `static mut`/`UnsafeCell` directly, or using a safe wrapper like `Forever`
<re_irc>
<@dirbaio:matrix.org> this gives you a `&static` that you can then use from everywhere without self-referential struct issues
<re_irc>
<@sourcebox:matrix.org> I regard it as benefit of using traits that you then can pass anything. If the LED is connected directly to a pin on the MCU or using a shift register doesn't matter.
<re_irc>
<@sourcebox:matrix.org> dirbaio:matrix.org: This is what I tried todo before the discussion went into another direction.
<re_irc>
<@sourcebox:matrix.org> Thanks, at least this seems to compile.
<re_irc>
<@sourcebox:matrix.org> Overall, I like this solution. With the following code I can setup 2 LEDs, one with direct MCU connection, the other via the shift register:
<re_irc>
<@sourcebox:matrix.org> ```rust
<re_irc>
<@sourcebox:matrix.org> let led1_pin = gpioa
<re_irc>
<@sourcebox:matrix.org> James Munns: you suggested to use AtomicBool for the BOARD_TAKEN variable. I changed that now. What's the deal with the Ordering options here?
<re_irc>
<@firefrommoonlight:matrix.org> Not super intuitive. Same as with C++ if you've used atomics there
<re_irc>
<@sourcebox:matrix.org> Isn't bool on Cortex-M atomic anyway?
<re_irc>
<@dirbaio:matrix.org> reads and writes are atomic up to 32bits
<re_irc>
<@dirbaio:matrix.org> but a read-modify-write is not
<re_irc>
<@sourcebox:matrix.org> And AtomicU64 does not exist for Cortex-M.
<re_irc>
<@dirbaio:matrix.org> if you want atomic read-modify-write you have to use AtomicBool
<re_irc>
<@sourcebox:matrix.org> I only need load() and store()
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<@firefrommoonlight:matrix.org> You can use Acquire and Release as a default for those
<re_irc>
<@dirbaio:matrix.org> if you want a TAKEN flag
<re_irc>
<@dirbaio:matrix.org> if you only use load/store you can have main thread racing with an interrupt and both may succeed in taking the thing
<re_irc>
<@dirbaio:matrix.org> you need the whole "read TAKEN, check it's false, write true" to be atomic
<re_irc>
<@firefrommoonlight:matrix.org> Yea. The compare_exchange etc methods help there
<re_irc>
<@sourcebox:matrix.org> I see.
<re_irc>
<@firefrommoonlight:matrix.org> The intent is you minimize the number of atomic operations for a given task. Ideally 1
<re_irc>
<@sourcebox:matrix.org> In practice it can't happen. But since I want to do it correctly...
<re_irc>
<@firefrommoonlight:matrix.org> So something else doesn't happen between your load and store etc
<re_irc>
<@firefrommoonlight:matrix.org> The atomic stuff is a bit unintuitive, but IMO worth it as a default for global primitives
<re_irc>
<@bugadani:matrix.org> If you are fine with unsafe code (which in general, should be avoided as much as possible), you can always make your initializer unsafe, slap a "SAFETY: only ever call this once" comment on it and be done with it.
<re_irc>
<@dirbaio:matrix.org> you probably want SeqCst
<re_irc>
<@dirbaio:matrix.org> or maybe AcqRel
<re_irc>
<@dirbaio:matrix.org> I *think* Relaxed can still race? but not sure
<re_irc>
<@dirbaio:matrix.org> or maybe not because it's still atomic
<re_irc>
<@bugadani:matrix.org> much simpler to store(true, Ordering::Relaxed)
<re_irc>
<@bugadani:matrix.org> you only have a false->true transition, not the other way around, so you can keep writing true
<re_irc>
<@sourcebox:matrix.org> bugadani:matrix.org: That looks good.
<re_irc>
<@jannic:matrix.org> > I *think* Relaxed can still race? but not sure
<re_irc>
<@jannic:matrix.org> Should be fine in this case. The access itself is still atomic, so no race. But the ordering related to other operations is not defined. So you need stricter ordering if you want to make sure some operations done by another thread are already visible. In this case, all you care about it that exactly one thread enters the protected block, so ordering doesn't matter.
<re_irc>
<@firefrommoonlight:matrix.org> Overall, it's important to consider what concurrency problems, (race conditions etc) can occur based on your code. It's not always obvious, and gets tougher with more complex code.
<re_irc>
<@firefrommoonlight:matrix.org> Eg what interrupts, cores, DMA actions have access to what items
<re_irc>
<@dkhayes117:matrix.org> Does anyone know of any eSIM modules, or ever worked with them?
<re_irc>
<@dkhayes117:matrix.org> Aka eUICC
<re_irc>
<@sourcebox:matrix.org> firefrommoonlight:matrix.org: I agree. Had some hard fights with these things in the past ;-)