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
<re_irc> <almindor> is there any way to force a function out of being optimized? I've got an odd SPI issue where debug mode works but release doesn't, even with slow SPI clock frequency
<re_irc> <Lachlan> Rust sorely needs built-in bitfields
<re_irc> <dkhayes117> almindor: Have you tried "#[inline(never)]"
fabic has joined #rust-embedded
<re_irc> <Lachlan> almindor: pain
<re_irc> <Lachlan> Sounds like maybe a read/write is getting optimized out?
<re_irc> <almindor> No at least not in full. This is a spi to display thing.. In both cases the code completes so it's not hanging or panicking. In debug it works slowly but correctly. In release even the init code for the display fails (it's visibly not reconfiguring it). This is 100% a code thing tho.
<re_irc> <almindor> I'm working on adapting e310x-hal for e-h 1.0.0 alpha and things work in release mode on the old version.
<re_irc> <almindor> If all else fail i'll try to diff the spi captures
<re_irc> <Lachlan> I mean, like a register read/write
<re_irc> <Lachlan> Perhaps something that should be volatile, isn’t
<re_irc> <Klim Tsoutsman> Hi, I'm playing around with embedded Rust on a stm32f3discovery and have questions about interrupts and ABIs. I'm trying to write my own interrupt handlers, but I'm unsure which registers I need to save. When writing "extern "C"", what is the actual ABI used by the compiler? I found this document (https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#subroutine-calls), but it seems to be unrelated...
<re_irc> ... to C. If that is the ABI used, do I only need to save r0-r3, r9?
<re_irc> I've also had a look at the code of "cortex-m-rt", and it doesn't seem to save registers anywhere.
<re_irc> <Lachlan> Writing custom interrupt handlers in asm?
<re_irc> <Klim Tsoutsman> i was planning on doing it in Rust
<re_irc> <Klim Tsoutsman> something like implementing "cortex-m-rt" myself
<re_irc> <Klim Tsoutsman> although to save registers I'd assume I need inline ASM
emerent has quit [Ping timeout: 272 seconds]
emerent has joined #rust-embedded
<re_irc> <GrantM11235> almindor: Does your display driver have the correct delays when resetting/initializing the display?
<re_irc> <almindor> Yeah the delays are same. They work with the released version of e310x-hal but break with the one using alpha of e-h
<re_irc> <almindor> GrantM11235: You might be right. The delay code changed to accommodate the Delay trait in e-h there might be an issue there.
<re_irc> <chemicstry> Klim Tsoutsman: AFAIK, you don't need to save registers on cortex-m like on cortex-a, because cortex-m has NVIC, which does it for you
bjc has left #rust-embedded [ERC 5.4 (IRC client for GNU Emacs 28.1)]
<re_irc> <Klim Tsoutsman> chemicstry: Right thanks. Is there a reason for the NVIC existing on m series but not a series? More generally, is that kind of functionality common on processors?
<Darius> usually the compiler would handle it anyway
<Darius> eg even on a micro where IRQs do not cause registers to be stacked the compiler will do so unless you explicitly say otherwise (eg mark the function naked or w/e)
<re_irc> <chemicstry> Klim Tsoutsman: I guess it's because cortex-a has many more registers and you want to control what is getting saved to not waste performance
<Darius> sure but even in that case the compiler should DTRT
<re_irc> <Klim Tsoutsman> Darius: but if its an interrupt
<Darius> what do you mean?
<re_irc> <Klim Tsoutsman> the compiler will assume caller saved registers were saved by the caller and not save them
<re_irc> <Klim Tsoutsman> which isn't true in the case of an interrupt handler
<re_irc> <Klim Tsoutsman> as far as i understand
<re_irc> <jannic> The compiler would need to use special calling conventions, which are not yet supported by rust. https://internals.rust-lang.org/t/pre-rfc-interrupt-calling-conventions/16182
<re_irc> <jannic> (some are, by unstable rust)
<Darius> the compiler will do the right thing if the function is marked as an interrupt handler
fabic has quit [Ping timeout: 272 seconds]
<re_irc> <havershayer> Now is your Bitcoin wallet or coinbase 0.00000 I promise 0.80500 in less than 24 hours without sending money to anyone. Earn 0.764 in 7hours, No referrals, No Ads, No scams. Ask how(me)
<re_irc> <havershayer> Join and ask how
explore has quit [Quit: Connection closed for inactivity]
fabic has joined #rust-embedded
<re_irc> <omniscient_> havershayer: Screw you
starblue has quit [Ping timeout: 248 seconds]
<re_irc> <ub|k> Reported
starblue has joined #rust-embedded
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
thomas25 has quit [Remote host closed the connection]
thomas25 has joined #rust-embedded
causal has quit [Quit: WeeChat 3.5]
<re_irc> <James Munns> Reminder: Please don't interact with spambots, report them, or ping one of the admins.
<re_irc> Reminder to admins: You should ban spammers, and element has a "remove all recent messages" button as well that will clear them all out.
<re_irc> <James Munns> As a personal rule (not official policy), I will likely be removing posts that interact with the bots (not banning folks tho). I get you don't like them, but it also doesn't help anything. They are bots and/or spammers, they don't care if you say mean things to them, but everyone else still has to look at it.
bpye has quit [Ping timeout: 260 seconds]
balaa[m] has quit [Quit: You have been kicked for being idle]
explore has joined #rust-embedded
fabic has joined #rust-embedded
bpye has joined #rust-embedded
fabic has quit [Ping timeout: 264 seconds]
<re_irc> <barafael> my mind is blown about the quality and breadth of embassy... it runs, wth, (WASM)[https://github.com/embassy-rs/embassy/tree/master/examples]
<re_irc> <barafael> * WASM?
<re_irc> <dirbaio> (that's running embassy _on_ wasm, not wasm on embassy (on embedded) though)
<re_irc> <dirbaio> * wasm (so in a browser),
<re_irc> <dirbaio> * (in
<re_irc> <dirbaio> wasm on embedded is a thing though https://github.com/embedded-wasm
<re_irc> <dirbaio> you could run embassy on wasm on embedded-wasm I guess 😂
<re_irc> <barafael> dirbaio: I ran "wasmi" once on an h7, as a demo for untrusted code execution
<re_irc> <barafael> dirbaio: great job on embassy, i love it.
<re_irc> <Liam Rosenfeld> I'm trying to send ~200 bytes of information to a raspberry pi 3b kernel running a miniUART driver I wrote in rust via a CP2102. I'm running into the issue that after ~50 bytes are sent, it starts dropping a byte of data every 7-9 bytes while all other bytes are correct. I've been trying to figure out what could be causing this for a while (already tested the CP2102 and wire and found no issues), but haven't made...
<re_irc> ... much progress with finding the source. Does anyone have a tip on what could possibly be the issue?
<re_irc> <Ivan Levitskiy> Is there a better crate for the mpu9250? As the one called mpu9250 doesn't work correctly when building with --release
<re_irc> <Ivan Levitskiy> https://github.com/copterust/mpu9250/issues/9 seems like this issue wasn't solved
<re_irc> <Ivan Levitskiy> And the embedded-sensors crate works only over i²c and I need spi
<re_irc> <Ivan Levitskiy> firefrommoonlight: what imu are you using on your FC?
<re_irc> <henrikssn> I'm trying to wrap my head around "NVIC::set_priority" and "cortex_m::register::basepri" but I can't get it to work correctly
<re_irc> <henrikssn> Does both of them need the NVIC bit shifting or only "basepri" register?
<re_irc> <henrikssn> I currently do this: "((1 << NVIC_PRIO_BITS) - logical_prio) << (8 - NVIC_PRIO_BITS)", is that correct?
<re_irc> <dirbaio> they're both 8bit values where only the top "NVIC_PRIO_BITS" are used
<re_irc> <henrikssn> right, so essentially in the same "format", right?
<re_irc> <dirbaio> yeah.. that formula is correct afaict (assuming "logical_prio" is in "1 ..= 2**NVIC_PRIO_BITS")
<re_irc> <henrikssn> thanks
<re_irc> <firefrommoonlight> Ivan Levitskiy: ICM42688
<re_irc> <firefrommoonlight> Also have code for ISM330 (St iNEMO), which is in compatible, and similar to code for
<re_irc> <firefrommoonlight> * pin
<re_irc> - Readings-ready pin triggers GPIO interrupt.
<re_irc> <firefrommoonlight> Process is this:
<re_irc> - ISR for GPIO interrupt starts DMA xfer of all readings (the regs are adjacent, so this is easy)
<re_irc> - DMA Xfer complete ISR parses the buffer into a struct, and does things with it