<re_irc>
<@sparky:matrix.possumlodge.me> anyone able to let me know how well things like BT LE work for hub and spoke style network setups and how well supported such things are in the rust ecosystem in general? hoping to have a bunch of remote sensors feed into a hub that then passes it along to a big old database for storage, and not sure if the built in wifi or bt support is better for such a thing cause im not at all used to either in the context of...
<re_irc>
... embedded devices trying to be low power consuming
<re_irc>
<@korken89:matrix.org> Does anyone know why ".sqrt()" does not work for "thumbv7em-none-eabihf"? It has the hardware support, but for some reason I get the error that ".sqrt()" does not exist for "f32".
<re_irc>
<@diondokter:matrix.org> Yeah, this has been annoying me for ages
<re_irc>
<@korken89:matrix.org> Ah it's not just me then having this issue
<re_irc>
<@diondokter:matrix.org> A lot of the float functions don't work. I believe there's something in the compiler intrinsics that needs to be configured
<re_irc>
<@korken89:matrix.org> I guess I have to use "asm!" then to get access to "sqrt"?
<re_irc>
<@diondokter:matrix.org> Options:
<re_irc>
- Statically link libm
<re_irc>
- Use something like micromath
<re_irc>
- Something asm yeah
<re_irc>
<@diondokter:matrix.org> libm is likely the better than writing asm
<re_irc>
<@korken89:matrix.org> Alright, thanks for the help!
<re_irc>
<@korken89:matrix.org> Oh, it has support for the intrinsics?
<re_irc>
<@diondokter:matrix.org> I don't quite remember what the deal was...
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
<@larunite:matrix.org> Hello! Just wondering - what is the best mechanism for putting buffers and things in specific memory regions? Is it just linker scripts?
<re_irc>
<@jamesmunns:beeper.com> : You can do things like "#[link_section = "..."]" on statics
<re_irc>
<@jamesmunns:beeper.com> So you'd put something like that in ".data.your_specific_kind", or ".fancy_section.specific_kind", then make sure you have that in your linker script as well
<re_irc>
<@larunite:matrix.org> Ah! That makes it easier
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hi @room, meeting time again! agenda is https://hackmd.io/PD3-SJoZTfykus4Ve6-2Kg, please add anything you'd like to announce or discuss and we'll kick off in 5 min
<re_irc>
<@thejpster:matrix.org> yo
<re_irc>
<@thejpster:matrix.org> I am still at work and need to cycle home, but I'll leave you a note in the agenda and catch up with you in 20.
<re_irc>
<@thejpster:matrix.org> uh, hackmd is dead
<re_irc>
<@thejpster:matrix.org> "OFFLINE"
<re_irc>
<@almindor:matrix.org> yeah same
<re_irc>
<@thejpster:matrix.org> OK, well the note is: Jan-Erik is about to mail you all to say that we just had a meeting and the Launching Pad Representative on the Rust Council is down to a short-list of one. Me.
<re_irc>
<@adamgreig:matrix.org> at least that'd simplify voting :P
<re_irc>
<@almindor:matrix.org> BDFL
<re_irc>
<@thejpster:matrix.org> No vote - it's consensus based. I think I just need literally every member of every constituent group to not object to me.
<re_irc>
<@adamgreig:matrix.org> OK, let's start. hackmd does seem dead so I'll stick links etc into the chat as we go
<re_irc>
<@thejpster:matrix.org> ttfn
<re_irc>
<@therealprof:matrix.org> : Hm, I'm in..
<re_irc>
<@therealprof:matrix.org> * in...
<re_irc>
<@adamgreig:matrix.org> yea, I'm in, but everyone else has dropped off and I can't connect from a new window or load old ones either
<re_irc>
<@adamgreig:matrix.org> only announcement from me was that rust 1.70 is due out on Thurs, did anyone else have any?
<re_irc>
<@therealprof:matrix.org> Not from me.
<re_irc>
<@adamgreig:matrix.org> yes, 1.69's era was short lived 🥲
<re_irc>
<@adamgreig:matrix.org> OK, next up, our ongoing bors issue, I've since migrated stm32-rs/stm32-rs to github merge queue without incident and so might try and tackle c-m or something next and write up a brief note about it, but seems more or less fine so far
<re_irc>
<@adamgreig:matrix.org> does anyone else has any further comments about the bors/ghmq etc stuff?
<re_irc>
<@romancardenas:matrix.org> I have a question regarding trying and staging. Are those branches needed anymore?
<re_irc>
<@adamgreig:matrix.org> nope, they were bors-specific and can be deleted
<re_irc>
<@adamgreig:matrix.org> there's no replacement for 'try' at the moment sadly
<re_irc>
<@adamgreig:matrix.org> , are you around / did you want to chat about this?
<re_irc>
<@adamgreig:matrix.org> the PR author's using this system for their book and has got a few translations going using it as an example we could look at
<re_irc>
<@adamgreig:matrix.org> last meeting we didn't really reach a conclusion on whether to merge I don't think; I think you wanted to wait and see if translators volunteer to use the new system before merging it?
<re_irc>
<@adamgreig:matrix.org> my hesitation with that is that I think it's a big ask to get someone to put effort into a new system that we haven't even merged yet, whereas if we merge the foundation for it then it may be easier for people to contribute
<re_irc>
<@adamgreig:matrix.org> but, sadly none of my foreign languages are even close to being enough to help with translations, so I don't have a ton of insight here
<re_irc>
<@therealprof:matrix.org> It's a chicken and egg problem...
<re_irc>
<@adamgreig:matrix.org> yea - but we can easily click merge if we think that will help, since someone's already put in the effort of most of the framework
<re_irc>
<@adamgreig:matrix.org> I think there's a few bits and pieces left like automating pofile generation and stuff?
<re_irc>
<@therealprof:matrix.org> Yeah, I think at least the mechanism would need to be feature complete.
<re_irc>
<@therealprof:matrix.org> Since English is still the main language at least we wouldn't lose anything.
<re_irc>
<@therealprof:matrix.org> Once we go that route tracing back is going to be a ton of work.
<re_irc>
<@adamgreig:matrix.org> as in, extracting translated markdown for a separate repo per project?
<re_irc>
<@adamgreig:matrix.org> * language?
<re_irc>
<@therealprof:matrix.org> The whole mechanism is a roundtrip mechanism. To use it we need to change the structure of the whole repo and put the new rendering and roundtripping mechanisms in place.
<re_irc>
<@shakencodes:matrix.org> : When are you planning on capturing the Postcard CRC functionality into a labeled version? I am using it off of the GitHub change-set ID for a while and it is working well! (Yes, I just want a prettier Cargo.toml file...)
<re_irc>
<@therealprof:matrix.org> Parts of that are still missing, so if we merge the PR, then we still need to put in some more work in to get back to the current state.
<re_irc>
<@adamgreig:matrix.org> do you have a rough idea of what's missing?
<re_irc>
<@shakencodes:matrix.org> : That makes sense. And no worries. It is working fine off the change-set based dependency.
<re_irc>
<@therealprof:matrix.org> It was mentioned in some comment. IIRC the extraction of the PO templates is missing, the automatic merging of the files and the rendering of the documents. Probably a nice languange selection and I think we'll need to revisit the publishing mechanism to the official Rust documentation, too.
<re_irc>
<@therealprof:matrix.org> : Hm?
<re_irc>
<@adamgreig:matrix.org> hmm, yea, the publishing through to the official docs probably complicates things. we should check how they handle translations too I guess
<re_irc>
<@diondokter:matrix.org> Yes, thinks the trampoline should be removed entirely
<re_irc>
<@diondokter:matrix.org> I think
<re_irc>
<@adamgreig:matrix.org> I can see the appeal, but that'd be a breaking change version of c-m-rt, and we don't have any other breaking changes in mind, so I don't think there's any reason to want to do it right away
<re_irc>
<@adamgreig:matrix.org> I feel like making it optional is a good starting point and could be published right away in a point release
<re_irc>
<@diondokter:matrix.org> Technically it's a breaking change for anyone that both uses the trampoline and has default-features = false at the same time
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@adamgreig:matrix.org> well, what I was about to say is that almost every PAC depends on cortex-m-rt too, without default-features=false, so probably most people are gonna have the feature enabled regardless
<re_irc>
<@diondokter:matrix.org> Now, there were no default features before, so I don't know why anyone would have that
<re_irc>
<@adamgreig:matrix.org> maybe we should call the feature naked-hardfault, make it non-default, and when enabled it causes the trampline to be skipped 😬
<re_irc>
<@diondokter:matrix.org> I don't know what's best...
<re_irc>
<@adamgreig:matrix.org> if it's a default feature I think no one will be able to disable it (due to PACs) until at least a new PAC release _and_ all the PACs are convinced to add default-features=false
<re_irc>
<@jamesmunns:beeper.com> : (happy to follow up after the meeting, I can release it this week, no blockers)
<re_irc>
<@diondokter:matrix.org> : Ah right
<re_irc>
<@adamgreig:matrix.org> if you reword the feature name so it's still a "positive feature" but not default, like the other recent features to control zero-init-ram, set-sp, set-vtor, etc, then no one will have behaviour change until they enable it, so...
<re_irc>
<@adamgreig:matrix.org> the only reason to not obviously do that is it does feel more like a "negative feature" :p
<re_irc>
<@diondokter:matrix.org> Another alternative Dario suggested is to add an option to the macro. He mentions it in the PR
<re_irc>
<@diondokter:matrix.org> Then no feature flag is required
<re_irc>
<@adamgreig:matrix.org> ah indeed, that could work?
<re_irc>
<@thejpster:matrix.org> I prefer to avoid feature flags where possible
<re_irc>
<@adamgreig:matrix.org> I think the trampoline asm would still get emitted into the final binary maybe, but not used?
<re_irc>
<@diondokter:matrix.org> It could, but it would move almost all hardfault code into the macro
<re_irc>
<@adamgreig:matrix.org> perhaps its emission could be controlled by the macro too
<re_irc>
<@diondokter:matrix.org> Yeah, so you'd have something like "#[exception(trampoline = true)]"
<re_irc>
<@adamgreig:matrix.org> could it be a new separate macro that emits like NakedHardFault or whatever?
<re_irc>
<@diondokter:matrix.org> Currently the hardfault uses the normal exception macro
<re_irc>
<@adamgreig:matrix.org> ah, yea
<re_irc>
<@diondokter:matrix.org> Then if you omit the trampoline param, it'd default to true
<re_irc>
<@adamgreig:matrix.org> a little annoying to have to special-case the exception macro to handle this, but I'm not sure how bad it would be in practice
<re_irc>
<@adamgreig:matrix.org> you already sort of special case the handling for the current PR I guess
<re_irc>
<@diondokter:matrix.org> The macro is already special-cased for hardfault because of the trampoline anyways
<re_irc>
<@adamgreig:matrix.org> so could you just change that "if cfg!(feature = "hardfault-trampoline")" to be more like "if trampline", and grab trampline earlier in the macro?
<re_irc>
<@diondokter:matrix.org> Yeah
<re_irc>
<@diondokter:matrix.org> And pull the global_asm! in as well
<re_irc>
<@adamgreig:matrix.org> ideally make it a compile error to specify trampline for exceptions that aren't hardfault
<re_irc>
<@diondokter:matrix.org> Yeah, fair and doable
<re_irc>
<@adamgreig:matrix.org> I don't _love_ having the global_asm be emitted into the user's crate by the macro but probably better than having it always emitted even when unused
<re_irc>
<@diondokter:matrix.org> If everybody is ok with pulling in all trampoline code into the macro, I could change the PR to do that
<re_irc>
<@diondokter:matrix.org> So that's the big question right now I think
<re_irc>
<@adamgreig:matrix.org> what else would need to be in the macro and won't just get removed by the optimiser?
<re_irc>
<@adamgreig:matrix.org> all the stuff on ExceptionFrame should be fine, so just the global_asm?
<re_irc>
<@diondokter:matrix.org> I think only the default hardfault handler
<re_irc>
<@diondokter:matrix.org> +and global asm
<re_irc>
<@adamgreig:matrix.org> does the default handler need to change?
<re_irc>
<@diondokter:matrix.org> I think I could get around that
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@adamgreig:matrix.org> kinda tricky if the trampline asm is removed then what points to the default handler
<re_irc>
<@adamgreig:matrix.org> do you wanna have a brief investigation into how it might look? I'm still not totally averse to a non-default feature to enable skipping the trampline either, but an argument to the macro does have advantages
<re_irc>
<@diondokter:matrix.org> Yeah you need _something_ to populate the vector table with
<re_irc>
<@diondokter:matrix.org> Sure, I'll draft something in a comment in the PR
<re_irc>
<@adamgreig:matrix.org> the "exception" macro might never get called, so the default state has to do something or other, but the same mechanism we use to use the provided default could probably work instead
<re_irc>
<@adamgreig:matrix.org> thanks
<re_irc>
<@adamgreig:matrix.org> , did you want to discuss your point further?
<re_irc>
<@adamgreig:matrix.org> if not, the other thing I wanted to solicit some feedback on is https://github.com/rust-embedded/svd2rust/pull/717 which is a proposal for per-peripheral "steal()" in svd2rust
<re_irc>
<@adamgreig:matrix.org> notably it _doesn't_ mark all peripherals as taken, which means you could unsafely "steal()" one first and then still safely "take()" them all afterwards, whereas currently if you "steal()" the whole "Peripherals" it does get marked as taken
<re_irc>
<@adamgreig:matrix.org> though this PR could also set "taken=true" without really losing anything, avoiding that problem, just unfortunately adding a write to a static every time it's used
<re_irc>
<@thejpster:matrix.org> Nothing to add. Just for you all to note.
<re_irc>
<@adamgreig:matrix.org> are you still happy to do it if you're selected?
<re_irc>
<@thejpster:matrix.org> Yup
<re_irc>
<@therealprof:matrix.org> : Still no opinion about that idea.
<re_irc>
<@thejpster:matrix.org> I don’t love the steal thing above. I get why they want to. I’m just not sure.
<re_irc>
<@thejpster:matrix.org> If you want to poke a peripheral you don’t own, I feel like you should do it with raw pointers.
<cr1901>
I don't think it's worth the extra code that has to modify the Option that takes the peripherlas for _each_ Peripheral
<cr1901>
(Unless the per peripheral steal is a wrapper over Peripherals::steal()
<re_irc>
<@adamgreig:matrix.org> the nuisance with the raw pointers is they give you a RegisterBlock but not the actual peripheral struct
<re_irc>
<@adamgreig:matrix.org> cr1901: it's just a function on the peripheral struct that returns a new copy of the peripheral struct
<re_irc>
<@adamgreig:matrix.org> so no change to "Peripherals", the big container struct
<re_irc>
<@thejpster:matrix.org> Good. Because anything that takes the peripheral struct can assume it owns it.
<re_irc>
<@adamgreig:matrix.org> well, you can always unsafely transmute "()" into a peripheral struct if you want one
<cr1901>
But shouldn't stealing a peripheral modify the Option<> singleton that Peripherals::take/steal modifies?
<re_irc>
<@adamgreig:matrix.org> so something taking a peripheral struct can only assume it owns it in the context of no unsafe code doing otherwise, which is still true with "unsafe steal()"
<re_irc>
<@adamgreig:matrix.org> cr1901: that's not an option, it's a global boolean, and yea, that's the question
<re_irc>
<@adamgreig:matrix.org> if it doesn't modify it, you could unsafely steal and then later safely take, but it could also just set it to true just like the existing global steal() does
<re_irc>
<@adamgreig:matrix.org> but... if you've already unsafely used steal(), the sin is committed, it doesn't seem that important whether take() later works or not
<re_irc>
<@thejpster:matrix.org> I don’t like the big steal() either and adding smaller steals() doesn’t make it better.
<cr1901>
I absolutely think it should modify the boolean in addition to returning a copy of the peripheral struct
<re_irc>
<@adamgreig:matrix.org> fair, the argument for the new small steal is just "big steal is a little more annoying to write out, let's make it slightly more convenient", so
<re_irc>
<@adamgreig:matrix.org> like, currently you can write "let uart = Peripherals::steal().UART1", and instead you could write "let uart = Uart1::steal()", if I understand it right
<re_irc>
<@therealprof:matrix.org> Still prefer "conjure" rather than "steal", but hey... 😄
<cr1901>
I think Peripheral unsafety should go all through Peripheral::steal/conjure/whatever
<re_irc>
<@therealprof:matrix.org> "take" one peripheral, get another for free, it's a steal!
<cr1901>
not though a per peripheral struct
<re_irc>
<@thejpster:matrix.org> Stealing is bad and we should discourage it. Or move to a model where there is no ownership implied.
<cr1901>
Ehhh, my experience is you need steal for some things
<re_irc>
<@thejpster:matrix.org> But don’t have ownership and work around it. That’s like casting yourself an &mut.
<re_irc>
<@thejpster:matrix.org> cr1901: things you couldn’t do with raw pointers?
<cr1901>
Not sure
<cr1901>
Didn't think to try b/c "raw pointers bad" :P
<re_irc>
<@thejpster:matrix.org> Like, there’s no steal function for a CriticalSection.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : Seems to me like if you need to steal all your peripherals something is wrong with your code anyway. And using unsafe functions do fix what is likely just a bad design... probably not good to encourage this
<re_irc>
<@thejpster:matrix.org> But people might say “I just wanna touch the thing and I can’t take a lock right now…”
<re_irc>
<@adamgreig:matrix.org> nice analogy
<re_irc>
<@adamgreig:matrix.org> OK, that's all we have time for this week, thanks everyone!
<re_irc>
<@jannic:matrix.org> Hah, missed it with near perfect timing :-)
<re_irc>
<@adamgreig:matrix.org> my cat has apparently learnt when 7pm meetings finish and has done a smelly poo within minutes of the end for a few meetings in a row now, her timing is almost as good as yours :P
<re_irc>
<@thejpster:matrix.org> Does anyone remember the “you wouldn’t steal a car” anti piracy adverts?
<re_irc>
<@adamgreig:matrix.org> of course :D
<cr1901>
download a car*, but yes
<re_irc>
<@adamgreig:matrix.org> well, only the IT crowd ones...
<re_irc>
<@thejpster:matrix.org> Too hard on my phone
<re_irc>
<@CyReVolt:matrix.org> : Another option might be high interest rates.
<re_irc>
<@CyReVolt:matrix.org> Jokes aside - having run into issues with peripherals and ownership many times, I am thinking that there could be helpers to ensure ownership instead of enforcing it initially.
<re_irc>
Like, traits with default implementations or whatever that can wrap any peripheral, and with that, I would support the per-peripheral ownership model. I can think of a concept of "being ready to own", which is where such a mechanism would come into play.
<re_irc>
<@dirbaio:matrix.org> : if we don't want to do a breaking change, then IMO it makes more sense to make it a macro arg: "#[exception(trampoline = false/true)]", defaulting to true so it's backward-compatible
<re_irc>
<@dirbaio:matrix.org> so the crate that defines the handler also decides whether there's trampoline or not
<re_irc>
<@dirbaio:matrix.org> vs with a Cargo feature, it can be influenced by any random crate
<re_irc>
<@dirbaio:matrix.org> this is my wishlist of cortex-m-rt changes:
<re_irc>
- add support for multiple pre_inits
<re_irc>
- remove current trampoline (breaking)
<re_irc>
- remove static mut transform (no one is using it, really). (breaking)
<re_irc>
- add an opt-in trampoline that allows access to ALL regs, not just r0-r3
<re_irc>
- add pre_main (runs before main, but after ram init, so it's not UB to use Rust) (perhaps add support for c++-style ctors, then use that to register pre_mains)
<re_irc>
<@dirbaio:matrix.org> just a collection of random stuff I think it'd be cool to have
<re_irc>
<@dirbaio:matrix.org> multiple pre_init/pre_mains are useful so you can freely use them from libs without worrying about taking it away from the user
<re_irc>
<@thejpster:matrix.org> I guess that’s basically just “guarantee main calls this function before anything the user gets to write”. Which solves the “What if one global touches a not-yet-initialised global”
<re_irc>
<@dirbaio:matrix.org> yeah..
<re_irc>
<@dirbaio:matrix.org> one use case is initializing hardware-related things that must be done before main to be sound
<re_irc>
<@dirbaio:matrix.org> the spinlock thing in rp-hal for example :)
<re_irc>
<@dirbaio:matrix.org> to be douns, it has to be done the very first thing on boot, before the user can use the lib
<re_irc>
<@dirbaio:matrix.org> but then the user can try to use the lib from _their_ pre_main, hmmm
<re_irc>
<@dirbaio:matrix.org> maybe registering a pre_main would have to be unsafe
tafama has joined #rust-embedded
Shell- has joined #rust-embedded
re_irc_ has joined #rust-embedded
loki_val has joined #rust-embedded
Shell- is now known as Shell
Shell has quit [Killed (copper.libera.chat (Nickname regained by services))]
inara` has joined #rust-embedded
crabbedhaloablut has quit [*.net *.split]
tafa has quit [*.net *.split]
re_irc has quit [*.net *.split]
inara has quit [*.net *.split]
re_irc_ is now known as re_irc
dc740 has quit [Remote host closed the connection]