emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
Socke has quit [Ping timeout: 256 seconds]
Socke has joined #rust-embedded
<re_irc> <@lachlansneff:matrix.org> What would be a reasonable way to have a rust embedded application on an stm32f1 restart itself if it wants to?
<Darius> NVIC_SystemReset()? (or the rust equivalent)
<Darius> or you can watchdog yourself I guess
<re_irc> <@lachlansneff:matrix.org> Looks like the equivalent to that function isn’t available, so I guess I’ll go the watchdog with 0 delay route
<Darius> well you could do what that function does pretty easily I think
<re_irc> <@lachlansneff:matrix.org> Oh, thank you for finding that
<re_irc> <@lachlansneff:matrix.org> I should’ve looked in cortex_m
<Darius> you're welcome
gsalazar has joined #rust-embedded
gsalazar_ has joined #rust-embedded
gsalazar_ has quit [Client Quit]
gsalazar_ has joined #rust-embedded
gsalazar_ has quit [Remote host closed the connection]
gsalazar has quit [Ping timeout: 250 seconds]
<re_irc> <@therealprof:matrix.org> irc_libera_cr1901:psion.agg.io: Sounded like a great conversation... Unfortunately for element users this was just a monologue...
<re_irc> <@9names:matrix.org> at least it's accessible in the logs. i wonder why it didn't all come through?
<re_irc> <@jamesmunns:beeper.com> Lachlan Sneff: just confirming, SCB sys_reset is exactly the way to go
sheb has joined #rust-embedded
<re_irc> <@sirhcel:matrix.org> Does anyone know of a `Pwm`/`PwmPin` implementation which uses an "odd" number of bits for its maximum duty cycle? For example for 12 bit duty resolution?
<re_irc> <@sirhcel:matrix.org> I'm working on a pwm driver for esp32 which offers variable duty cycle resolution as a tradeoff to maximum pwm speed. I'm reasoning about which way to go:
<re_irc> <@sirhcel:matrix.org> - Define `Duty` to be `u32`, `get_max_duty` to always return `u32::MAX` and internally scale the values down to the actual resolution. This makes duty-cycle representation independent of the driver configuration but then there are ranges of duty-cycle values producing the same output.
<re_irc> <@sirhcel:matrix.org> - Make `get_max_duty` dependent on the currently selected resolution. This makes the duty-cycle configuration dependent and users need to be aware of this but each value actually gives a different output.
<re_irc> <@sirhcel:matrix.org> For me, the latter has the drawback that `set_duty` in e-h 0.2 does not provide a return type to indicate a duty-cycle out of bounds and i can't find documentation about the expected behavior in this case: for example to saturate or to panic.
xnor has quit [Quit: WeeChat 3.4]
xnor has joined #rust-embedded
<cr1901> Amanieu: Back to working on msp430 asm... how might I be able to inject asm_suffix into an asm! macro?: https://github.com/pftbest/msp430-atomic/blob/master/src/lib.rs#L633-L634
<Amanieu> concat!()
<cr1901> oh concat does work in asm!
<cr1901> I think what I tried was format! for some reason I don't remember and then assumed concat! wouldn't work either
<cr1901> I have one piece of deployed code that uses msp430-atomic, so that needs to look reasonable before I have _any_ confidence that I did the port right
<cr1901> Amanieu: Can asm! macro be used to enforce a compiler fence? https://github.com/rust-embedded/msp430/blob/master/src/asm.rs#L19 1/2
<cr1901> Yes I know this should be upstream in LLVM. It's not, and it's a loooong story
<Amanieu> Yes it can.
<Amanieu> Does the compiler fence in core::sync::atomic not work?
<cr1901> No, it doesn't for msp430... lemme find the relevant issue
tafama has quit [Quit: ZNC - https://znc.in]
<cr1901> Context: asl is the msp430 llvm maintainer, and he works on the C side of things
<cr1901> Oh wait, you're already tagged on this issue :P
tafa has joined #rust-embedded
<Amanieu> Yea I remember it now.
<cr1901> At some point, single_threaded: true will be enabled, and I'll get awygle to help me submit the patch
<cr1901> (ask forgiveness not permission)
<cr1901> But asm!("") is sufficient for a compiler fence?
<cr1901> >By default the compiler will assume that inline assembly can read or write any memory address that is accessible to it (e.g. through a pointer passed as an operand, or a global). Ahhh here we go
<cr1901> that should be a fence
<Amanieu> Yea, as long as you don't use the nomem/readonly options which restrict what the asm! can access.
<re_irc> <@adamgreig:matrix.org> Can you use core::sync::atomic::compiler_fence or is it not there on msp?
<Amanieu> \o/
<cr1901> I will have to test, but from a careful glance, "this looks correct"
<cr1901> "save the status reg, disable ints, if status reg indicated ints were prev enabled, reenable ints after critical section"
inara has quit [Quit: Leaving]
inara has joined #rust-embedded
<cr1901> Amanieu: And now we get to the hard part/where I'm not totally sure. Btw, I pushed the rust branch if you want to take a glance
<cr1901> https://github.com/pftbest/msp430-atomic/blob/master/src/lib.rs#L633-L634 So, I converted this to asm!, suffix and all, but Idk how to specify the reg class as dependent on the suffix
<cr1901> What does it mean for a register of class "reg" (16-bits) to take an operand that's 8-bits? It's legal, but does that mean "all 16-bits are considered unusable for allocation in the asm expr even if only the bottom part is used"?
<Amanieu> It means the upper 8 bits have undefined values.
<Amanieu> I had a look at your branch, I don't think you should have rX and rXb as separate registers. If I understand correctly they work in a similar way to ax vs al on x86.
<cr1901> There is no "rXb" you can specify in an msp430 insn or assembly syntax. Byte/word operation is part of the opcode itself
<cr1901> i.e. I can't do mov r2b, r5b. It's "mov.b r2, r5"
<Amanieu> Then I don't see what the problem is. Just do that.
<cr1901> Well, for add and add.b, the semantics are different. add carries out of the 16-bit and add.b carries out of the 8-bit
<Amanieu> Sure, but it's up to the user of the asm! to figure out what semantics they want and use the proper instruction suffix.
<cr1901> (Honestly, I'm not sure if it _makes_ a difference)
<cr1901> With the semantics of add I gave you, is it okay to pass a class of reg (16-bit) to add.b?
<cr1901> I don't _think_ there's a problem, but I'm not 100% sure
<cr1901> Maybe there's something I'm missing and I just want to be careful :P
<Amanieu> Sure, in the end what happens is that the compiler pastes "r5" into the {} placeholder and passes the result to the assembler.
<cr1901> ahhh okay, lemme do the conversion, test my firmware to confirm it works, then I can refine the asm! support :)
<cr1901> (Should I still get rid of the byte class, since those registers don't actually exist?)
<cr1901> The rXb stuff is an LLVM thing
<cr1901> So I just copied it to make sure Rust knew about what LLVM knows about
<Amanieu> Yea that's just an LLVM thing. You'll need to handle it in the llvm lowering though.
<Amanieu> If an i8 operand is used with an explicit register then you need to use the "rXb" name for the llvm constraint instead of "rX"
<cr1901> I think I already do handle that, but I still have to add tests, so we'll see if it breaks
<Amanieu> See some of the cases at the top of reg_to_llvm().
<Amanieu> But then again, I'm not sure if it is required.
<cr1901> Btw, I could look this up, but if you know offhand, is there a shortcut from x.py to run only a single compiler crate's tests?
<cr1901> Instead of everything
<Amanieu> For the tests, you need to test all combinations (reg/i8, reg/i16, "r5"/i8, "r5"/i16)
<Amanieu> ./x.py test src/test/assembly
<cr1901> oh
<cr1901> that's easy
<cr1901> (I meant to put reg_byte I think)
<Amanieu> Also do update the unstable book in src/doc/unstable-book/src/language-features/asm-experimental-arch.md
<cr1901> Will do
<cr1901> If I am using a reg as a pointer, then it is technically an in(reg), correct?
<Amanieu> Yes
<cr1901> Okay, I need to fix my deployed firmware to compile with other changes I made. Taking a break to eat, then I will test the firmware. If it works, then we celebrate. If not, I figure out what's wrong :D
<cr1901> I was _just_ about to make a bunch of breaking changes to msp430 crate ecosystem. What's one more w/ new asm :P?
<Amanieu> Isn't that a fixing change rather than a breaking one? :P
<cr1901> Fair point :D
sheb has quit [Quit: Leaving]
<cr1901> Well, testing is going to have to wait... svd2rust changed so much since I last generated crates with it that I have no clue how to make my firmware typecheck anymore
<cr1901> (Why the hell does each register have a separate Reader now instead of being generic over crate::R?!?!)
<cr1901> Okay compiled, finally... ugh!
<cr1901> Amanieu: This'll be a good stopping point for tonight. I found something that doesn't look right in the new assembly (probably a typo on my end)
<cr1901> so I want to flesh out my mistakes I can find before bothering to test the firmware
<cr1901> Yep, it's a typo alright
<cr1901> Amanieu: Also, FWIW... rust asm pessimizes by binary by around 2.5%... i.e. 50 bytes :P. Some opt opportunities lost to register shuffling
<Amanieu> :O