<re_irc>
<@korken89:matrix.org> Does anyone know if there has been breaking changes in "cortex-m"? It seems that the "set_priority" now requires "Copy" for the "InterruptNumber" trait, and I noticed this as previously passing tests in RTIC started failing on this.
<re_irc>
Example error:
<re_irc>
error[E0277]: the trait bound `Interrupt: std::marker::Copy` is not satisfied
<re_irc>
--> ui/task-priority-too-high.rs:3:1
<re_irc>
|
<re_irc>
3 | #[rtic::app(device = lm3s6965)]
<re_irc>
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::marker::Copy` is not implemented for `Interrupt`
<re_irc>
|
<re_irc>
= note: required for `Interrupt` to implement `InterruptNumber`
<re_irc>
note: required by a bound in `cortex_m::peripheral::nvic::<impl NVIC>::set_priority`
<re_irc>
| ------------ required by a bound in this associated function
<re_irc>
| where
<re_irc>
| I: InterruptNumber,
<re_irc>
| ^^^^^^^^^^^^^^^ required by this bound in `cortex_m::peripheral::nvic::<impl NVIC>::set_priority`
<re_irc>
= note: this error originates in the attribute macro `rtic::app` (in Nightly builds, run with -Z macro-backtrace for more info)
<re_irc>
<@korken89:matrix.org> Hmm, this might be an error on our side - seems like an old version of "lm3s6965" is being used for some reason
<re_irc>
<@korken89:matrix.org> Yep that was it, there was a release that caused our patch to not be applied.
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@neodsp:matrix.org> Hey you all!
<re_irc>
I was already building static libraries from rust to use it in C programs a couple of times, but I just bumped into an issue when testing this for the first time with an arm cortex chip.
<re_irc>
To test I was generating a small demo program with an extern "C" demo function and the panic_halt panic handler. Compilation for "thumbv7em-none-eabihf" went fine and I get the static .a library.
<re_irc>
When I link to the library in the makefile of the daisy seed (stm32h750) demo projects with "LDFLAGS= -L./rusty/target/thumbv7em-none-eabihf/release -lrusty" it has a lot of undefined references like
<re_irc>
undefined reference to `_ebss'
<re_irc>
undefined reference to `_sbss'
<re_irc>
undefined reference to `_estack'
<re_irc>
Does anyone know if I have to do any additional steps when I want to build a static lib for microcontrollers?
<re_irc>
<@joelimgu_:matrix.org> neodsp: I has a similar problem, I asked on stack overflow about the best way to deal with it and I havent gotten a response. But I just solved it writing those functions myself in Rust, I took inspuration form the musl libc code: https://elixir.bootlin.com/musl/v1.2.4/source/src/math/scalbnl.c
m5zs7k has quit [Ping timeout: 264 seconds]
m5zs7k has joined #rust-embedded
<re_irc>
<@neodsp:matrix.org> : maybe this error is helping as well:
<re_irc>
"failed to merge target specific data of file ./rusty/target/thumbv7em-none-eabihf/release/librusty.a(compiler_builtins-05cbe9a05dd5869d.compiler_builtins.705396d58b434305-cgu.154.rcgu.o)"
<re_irc>
and
<re_irc>
" ./rusty/target/thumbv7em-none-eabihf/release/librusty.a(compiler_builtins-05cbe9a05dd5869d.compiler_builtins.705396d58b434305-cgu.172.rcgu.o) uses VFP register arguments, build/rusty-daisy.elf does not"
<re_irc>
<@joelimgu_:matrix.org> neodsp: No, its an unrelater error, it shouldt be a probel if you arent passing floats between Rust anc C, but try compiling the C with hard floats or rust without them
<re_irc>
<@joelimgu_:matrix.org> * unrelatederror, it shouldt be a problemif
<re_irc>
<@neodsp:matrix.org> : it is an audio process, so I am passing floats...
<re_irc>
<@neodsp:matrix.org> it is a function with a float*
<re_irc>
<@joelimgu_:matrix.org> neodsp: then yes, its a problem, but I dont get why its happening bc normally the **hf means hard-float...
<re_irc>
<@neodsp:matrix.org> : I will try if a function without floats is working
<re_irc>
<@joelimgu_:matrix.org> neodsp: For the float problem I dont have a response, for the undefined functions I just wrote them myself ant it solves it even if thers maybie a better solution
<re_irc>
<@neodsp:matrix.org> : okay a function without floats or for the same target without hf is not linking either..
<re_irc>
<@joelimgu_:matrix.org> neodsp: whats the lib youre compiling, librusty or rusty-daisy?
<re_irc>
<@neodsp:matrix.org> : librusty ist the rust static library, rusty-daisy is the one using the static lib.
<re_irc>
<@joelimgu_:matrix.org> neodsp: ok, then the problem is with rusty-daisy, are you compiling it too or qre you just using a prebuild object file?
<re_irc>
<@joelimgu_:matrix.org> Also, question is performance critical for you?
<re_irc>
<@neodsp:matrix.org> and added the ldflags to the makefile
<re_irc>
<@joelimgu_:matrix.org> neodsp: Does this flag appear when you call make? -mfloat-abi=hard
<re_irc>
<@joelimgu_:matrix.org> Also, if performance is not critical for you you can just use soft-floats compiling the rust lib with the target: thumbv7em-none-eabi
<re_irc>
<@neodsp:matrix.org> : this target was still leading to the undefined references..
<re_irc>
<@joelimgu_:matrix.org> neodsp: yes, but this are two unrelated problems. The undefined reference is, from what I could understand, bc rust expect some libs to be included wich gcc doesnt link. The unable to link error comes from the fact that you have rust using hard floats and C using soft floats wich are uncompatible
<re_irc>
<@joelimgu_:matrix.org> using the target thumbv7em-none-eabi will only solve the float problem
<re_irc>
<@joelimgu_:matrix.org> to solve the undefined functions ypu just write those functions in rust with #[no_mangle] and to see what they are supposed to do you can read the musl code
<re_irc>
<@neodsp:matrix.org> : Ah yeah the make is showing "arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard"
<re_irc>
<@joelimgu_:matrix.org> neodsp: then I dont know, it should be working at least for the float problem...
<re_irc>
<@joelimgu_:matrix.org> well, Ihave to go, I hope you can solve it! GL
<re_irc>
<@neodsp:matrix.org> : here you see the full console output:
<re_irc>
<@neodsp:matrix.org> problem is, it can't find daisy::DaisySeed::SetAudioBlockSize(unsigned int) as well which are functions from the daisy framework. And rust does not need to know about those functions right?
<re_irc>
<@firefrommoonlight:matrix.org> neodsp: Hey cross-post from RTIC chat. IMO very useful feature just added (in crates.io rel). Shared and Local can be pub, so you don't need to put init in the main module
<re_irc>
<@neodsp:matrix.org> : Okay the problem might be that I wasn't linking the rust compiler to the STM32H750IB_flash.lds file of the daisy board.
<re_irc>
<@neodsp:matrix.org> hahaha the problem was my makefile:
<re_irc>
had to go before the include statements :D
<re_irc>
Thanks for your help!
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
Socke has quit [Ping timeout: 246 seconds]
Socke has joined #rust-embedded
Socke has quit [Ping timeout: 260 seconds]
Socke has joined #rust-embedded
Socke has quit [Ping timeout: 244 seconds]
Socke has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hi @room , meeting time again! agenda's https://hackmd.io/UFLdzHhcSrSak4vvF_75BQ, please add anything you'd like to announce or discuss, we'll start in a few mins
<re_irc>
<@adamgreig:matrix.org> ok, let's start! no announcements from me this week, did anyone else have anything?
<re_irc>
<@adamgreig:matrix.org> ok, on with the agenda, "nb" has joined the ongoing transition to ghmq
<re_irc>
<@adamgreig:matrix.org> : thanks for updating the cortex-m-rt pr, I'll try and get that merged this evening, didn't spot any issues
<re_irc>
<@diondokter:matrix.org> Yeah, hope it's all good now!
<re_irc>
<@adamgreig:matrix.org> shame it turned out as complicated as it did, but the result seems nice
<re_irc>
<@diondokter:matrix.org> Better late and good than early and shoddy :)
<re_irc>
<@diondokter:matrix.org> I like the way it is now
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> the other pr we've had on the agenda for a while is https://github.com/rust-embedded/svd2rust/pull/723, i think is right and it probably needs slightly expanded safety docs, if anyone's got any ideas on that we could discuss now or drop on the pr thread
<re_irc>
<@adamgreig:matrix.org> the gist is _probably_ "only call if you are sure you will have exclusive access to the peripheral while you use the stolen copy, or perhaps if you're sure any non-exclusive access will be fine because it's to fields where it's ok, or otherwise if you're not convinced safety applies to concurrent mmio access anyway...."
<re_irc>
<@thejpster:matrix.org> parallel to this (don't block this PR for this idea), maybe we could update the Rust Embedded Book.
<re_irc>
<@thejpster:matrix.org> It talks a bit about why singletons are useful but we could maybe expand and explain when they are also not useful and why you might use steal.
<re_irc>
<@thejpster:matrix.org> Also it could talk about HAL-level singletons vs PAC-level singletons.
<re_irc>
<@adamgreig:matrix.org> agreed, though if we're leaning away from pac-level singletons anyway perhaps it can say "pacs _used_ to have singletons..."
<re_irc>
<@thejpster:matrix.org> some PACs won't be updated for a while.
<re_irc>
<@thejpster:matrix.org> but sure.
<re_irc>
<@adamgreig:matrix.org> yea, I guess it can talk about the history and what some PACs will still be doing
<re_irc>
<@adamgreig:matrix.org> onto critical-section, we were hoping to gather a list of implementations and possibly some use examples to include in the docs for the next update
<re_irc>
<@adamgreig:matrix.org> what's out there? there's cortex-m, riscv, ...
<re_irc>
<@thejpster:matrix.org> in what docs, the critical-section docs?
<re_irc>
<@adamgreig:matrix.org> rp2040-hal
<re_irc>
<@jannic:matrix.org> rp2040-hal has an impl using the rp2040 specific spinlocks to provide multi-core safety
<re_irc>
<@adamgreig:matrix.org> : yea
<re_irc>
<@adamgreig:matrix.org> does one of the esp crates provide one?
<re_irc>
<@adamgreig:matrix.org> svd2rust uses it, so all the recently generated PACs do
<re_irc>
<@adamgreig:matrix.org> (or rather, svd2rust generates code that uses it)
<re_irc>
<@adamgreig:matrix.org> it looks like esp-idf-hal does indeed provide an impl though
<re_irc>
<@jannic:matrix.org> Well the GameBoy one is _perhaps_ a little bit too simplistic. Or does that chip doesn't have any concurrency at all, not even interrupts?
<re_irc>
<@thejpster:matrix.org> can we offer some co-maintaners?
<re_irc>
<@thejpster:matrix.org> Or should we ask if it can be moved? To .... /rust-embedded? Or is /rust-embedded-community better?
<re_irc>
<@therealprof:matrix.org> "embedded-dma" support for heapless? 😅
<re_irc>
<@thejpster:matrix.org> Are "stack-based liballoc-alike containers" within REWG's remit?
<re_irc>
<@therealprof:matrix.org> I think that sounds more like a community project.
<re_irc>
<@adamgreig:matrix.org> it's another thing where if we had a libs team it would be perfect, heh
<re_irc>
<@adamgreig:matrix.org> it's not so different to like embedded-alloc and such, so I wouldn't be against it moving to the wg, but not sure which team it would be under
<re_irc>
<@adamgreig:matrix.org> also no problem with it going to r-e-c
<re_irc>
<@thejpster:matrix.org> REWG tends to own things when types are used across a crate's external API and we want to avoid splitting the ecosystem
<re_irc>
<@thejpster:matrix.org> maybe people don't use heapless types across APIs (instead there's either some "fn store(&mut self, stuff: T)" or "fn store(&mut self, &[T])")
<re_irc>
<@adamgreig:matrix.org> and architecture things like cortex-m, c-m-rt, riscv, and tools like svd2rust, itm, etc
<re_irc>
<@adamgreig:matrix.org> but yea, it's not really a shared thing that needs to be wg to try and stop ecosystem splits
<re_irc>
<@adamgreig:matrix.org> that said perhaps if it was in such a position people could use heapless types in their public apis more happily
<re_irc>
<@thejpster:matrix.org> Ah, I see is also a maintainer
<re_irc>
<@therealprof:matrix.org> Not sure crates being owned by japaric has ever stopped people from using them, probably rather the opposite. 😅
<re_irc>
<@korken89:matrix.org> Ah yeah, not active maintainer though. I don't have the time unfortunately
<re_irc>
<@korken89:matrix.org> Not sure if japaric plan to come back to it as well
<re_irc>
<@thejpster:matrix.org> who should interested volunteers speak to in the first instance?
<re_irc>
<@korken89:matrix.org> I think I have full rights, so I think either works
<cr1901>
I know japaric is fine, but I wish he'd just say it or come back briefly lol
<re_irc>
<@korken89:matrix.org> I can check when I'm home, at the gym now :)
* cr1901
set an alarm for the meeting, and forgot ._.
Socke has quit [Ping timeout: 245 seconds]
<re_irc>
<@thejpster:matrix.org> cr1901: we work at the same company and even I don't get to say hi all that often :/
<cr1901>
Hmmm :(
<re_irc>
<@adamgreig:matrix.org> if that's all, let's finish the meeting here, thanks everyone!
Socke has joined #rust-embedded
Socke has quit [Ping timeout: 244 seconds]
Socke has joined #rust-embedded
Socke has quit [Ping timeout: 245 seconds]
Socke has joined #rust-embedded
Socke has quit [Ping timeout: 245 seconds]
Socke has joined #rust-embedded
Socke has quit [Ping timeout: 258 seconds]
Socke has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> couldn't make it to the meeting, was on a ✈️
<re_irc>
<@dirbaio:matrix.org> I wanted to propose releasing "embedded-hal v1.0-rc1" and co :P
<re_irc>
<@dirbaio:matrix.org> because there's no blockers left now, are there?
<re_irc>
<@dirbaio:matrix.org> - there's the migration guide, but we don't _need_ it to be done before the RC (?)
<re_irc>
<@dirbaio:matrix.org> - there's async stuff requiring "#[feature]". It's almost guaranteed that AFIT won't see breaking changes before stabilization. Perhaps it's fine to have it in a 1.0, stating "the only breaking change we'll do is removing "#[feature]"?
<re_irc>
<@dirbaio:matrix.org> * "#[feature(..)]". It's almost guaranteed that AFIT won't see breaking changes before stabilization. Perhaps it's fine to have it in a 1.0, stating "the only breaking change we'll do is removing "#[feature(..)]"?
<re_irc>
<@dirbaio:matrix.org> (the alternative is to release RC for everything, then later release final 1.0 for non-async stuff and wait for stable AFIT for async)
<re_irc>
<@bugadani:matrix.org> : Removing the feature will be a huge leap in MSRV, and it is also technically not required. The feature can just turn into a no-op silently, but the associated MSRV change is breaking anyway.
<re_irc>
<@bugadani:matrix.org> : Just keep in mind that a feature removal is also a MSRV bump, and an MSRV bump is a breaking change, too.
<re_irc>
<@dirbaio:matrix.org> : my reasoning is it changes the crate from "works on nightly" to "works on stable 1.xx+"
<re_irc>
<@dirbaio:matrix.org> if you're using nightly, you're OK with breaking changes forced by rustc
<re_irc>
<@dirbaio:matrix.org> * opting in to
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@dirbaio:matrix.org> and rustc forces removing the "#[feature]" annotations when the feature is stabilized (not immediately, it usually warns for a while and then errors later)
<re_irc>
<@diondokter:matrix.org> : What if we say msrv is the future stable rust version that can compile it. Any nightly version that supports it is bonus.
<re_irc>
Then it's not a breaking change
<re_irc>
<@diondokter:matrix.org> : This vibe really
<re_irc>
<@bugadani:matrix.org> : dang it I was thinking about "#[cfg(feature =)]". Yeah if a crate was working on nightly, then a transition to stable is probably fine. That would be the first time that crate gets an msrv
<re_irc>
<@bugadani:matrix.org> * nightly only,
<re_irc>
<@dirbaio:matrix.org> : hahaha that's a very nice way to put it
<re_irc>
<@dirbaio:matrix.org> so, going from "works on today's nightly" to "works on future stable" requries a change that will break today's nightly (removing "#[feature(...)]")
<re_irc>
<@dirbaio:matrix.org> but today's nightly was never actually supported by the MSRV! :D
<re_irc>
<@dirbaio:matrix.org> so
<re_irc>
<@dirbaio:matrix.org> ¯\_(ツ)_/¯
<re_irc>
<@bugadani:matrix.org> : I'm trying to poke a hole into the logic but can't 😅 the xtensa toolchain is in a weird place where it's branched off from nightly, has nightly features and is considered stable, but even there this is fine