05:18 <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?

05:38 <Darius> NVIC_SystemReset()? (or the rust equivalent)

05:39 <Darius> https://stackoverflow.com/questions/25121107/nvic-systemreset-not-working-for-stm32f4

05:39 <Darius> or you can watchdog yourself I guess

06:54 <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

06:55 <Darius> well you could do what that function does pretty easily I think

07:06 <Darius> https://github.com/rust-embedded/cortex-m/blob/master/src/peripheral/scb.rs has sys_reset()

07:11 <re_irc> <@lachlansneff:matrix.org> Oh, thank you for finding that

07:12 <re_irc> <@lachlansneff:matrix.org> I should’ve looked in cortex_m

07:15 <Darius> you're welcome

10:27 <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...

10:45 <re_irc> <@9names:matrix.org> at least it's accessible in the logs. i wonder why it didn't all come through?

11:18 <re_irc> <@jamesmunns:beeper.com> Lachlan Sneff: just confirming, SCB sys_reset is exactly the way to go

12:31 <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?

12:40 <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:

12:40 <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.

12:40 <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.

12:45 <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.

18:46 <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

18:46 <Amanieu> concat!()

18:46 <cr1901> oh concat does work in asm!

18:48 <cr1901> I think what I tried was format! for some reason I don't remember and then assumed concat! wouldn't work either

18:51 <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

19:19 <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

19:20 <cr1901> Yes I know this should be upstream in LLVM. It's not, and it's a loooong story

19:20 <Amanieu> Yes it can.

19:20 <Amanieu> Does the compiler fence in core::sync::atomic not work?

19:21 <cr1901> No, it doesn't for msp430... lemme find the relevant issue

19:22 <cr1901> Amanieu: https://github.com/rust-lang/compiler-builtins/issues/441#issuecomment-976747050 Start here

19:22 <cr1901> Context: asl is the msp430 llvm maintainer, and he works on the C side of things

19:23 <cr1901> Oh wait, you're already tagged on this issue :P

19:23 <Amanieu> Yea I remember it now.

19:24 <cr1901> At some point, single_threaded: true will be enabled, and I'll get awygle to help me submit the patch

19:24 <cr1901> (ask forgiveness not permission)

19:25 <cr1901> But asm!("") is sufficient for a compiler fence?

19:27 <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

19:27 <cr1901> that should be a fence

19:27 <Amanieu> Yea, as long as you don't use the nomem/readonly options which restrict what the asm! can access.

19:52 <re_irc> <@adamgreig:matrix.org> Can you use core::sync::atomic::compiler_fence or is it not there on msp?

19:52 <cr1901> Amanieu: Well, the easy code is working :D http://gopher.wdj-consulting.com:70/paste/50b49926-b4d7-4d90-9646-6e3a9b2847a9.txt (Original Rust: https://github.com/rust-embedded/msp430/blob/master/src/interrupt.rs#L48-L67) :D

19:54 <Amanieu> \o/

19:54 <cr1901> I will have to test, but from a careful glance, "this looks correct"

19:55 <cr1901> "save the status reg, disable ints, if status reg indicated ints were prev enabled, reenable ints after critical section"

20:16 <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

20:17 <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

20:18 <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"?

20:19 <Amanieu> It means the upper 8 bits have undefined values.

20:20 <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.

20:21 <cr1901> There is no "rXb" you can specify in an msp430 insn or assembly syntax. Byte/word operation is part of the opcode itself

20:21 <cr1901> i.e. I can't do mov r2b, r5b. It's "mov.b r2, r5"

20:21 <Amanieu> Then I don't see what the problem is. Just do that.

20:22 <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

20:22 <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.

20:22 <cr1901> (Honestly, I'm not sure if it _makes_ a difference)

20:23 <cr1901> With the semantics of add I gave you, is it okay to pass a class of reg (16-bit) to add.b?

20:23 <cr1901> I don't _think_ there's a problem, but I'm not 100% sure

20:24 <cr1901> Maybe there's something I'm missing and I just want to be careful :P

20:24 <Amanieu> Sure, in the end what happens is that the compiler pastes "r5" into the {} placeholder and passes the result to the assembler.

20:25 <cr1901> ahhh okay, lemme do the conversion, test my firmware to confirm it works, then I can refine the asm! support :)

20:26 <cr1901> (Should I still get rid of the byte class, since those registers don't actually exist?)

20:26 <cr1901> The rXb stuff is an LLVM thing

20:26 <cr1901> So I just copied it to make sure Rust knew about what LLVM knows about

20:27 <Amanieu> Yea that's just an LLVM thing. You'll need to handle it in the llvm lowering though.

20:28 <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"

20:29 <cr1901> I think I already do handle that, but I still have to add tests, so we'll see if it breaks

20:29 <Amanieu> See some of the cases at the top of reg_to_llvm().

20:30 <Amanieu> But then again, I'm not sure if it is required.

20:30 <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?

20:30 <cr1901> Instead of everything

20:30 <Amanieu> For the tests, you need to test all combinations (reg/i8, reg/i16, "r5"/i8, "r5"/i16)

20:31 <Amanieu> ./x.py test src/test/assembly

20:31 <cr1901> oh

20:31 <cr1901> that's easy

20:34 <cr1901> https://github.com/cr1901/rust/commit/9ac972ef320fc7a59be030652a74e9cca9ea4891#diff-48bf61643e43c6de2657a3044b9955cc94984ccb27af100e0f4681a8611bca06R61-R71 Hmmm, I think this was a typo

20:34 <cr1901> (I meant to put reg_byte I think)

20:41 <Amanieu> Also do update the unstable book in src/doc/unstable-book/src/language-features/asm-experimental-arch.md

20:41 <cr1901> Will do

20:42 <cr1901> If I am using a reg as a pointer, then it is technically an in(reg), correct?

20:43 <Amanieu> Yes

20:45 <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

20:46 <cr1901> I was _just_ about to make a bunch of breaking changes to msp430 crate ecosystem. What's one more w/ new asm :P?

20:50 <Amanieu> Isn't that a fixing change rather than a breaking one? :P

21:05 <cr1901> Fair point :D

22:45 <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

22:45 <cr1901> (Why the hell does each register have a separate Reader now instead of being generic over crate::R?!?!)

23:30 <cr1901> Okay compiled, finally... ugh!

23:41 <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)

23:42 <cr1901> so I want to flesh out my mistakes I can find before bothering to test the firmware

23:44 <cr1901> Yep, it's a typo alright

23:59 <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

23:59 <Amanieu> :O