00:12 <kpcyrd[m]> ah, apparently I can just use critical_section::Mutex::get_mut without needing to activate the critical section myself

00:37 <thejpster[m]> to answer my own question, _stext is a PROVIDE(...) so you can over-ride it. Which is exactly what I need to do.

00:37 <thejpster[m]> No idea why __stext is also defined. It seems to be unused.

00:38 <thejpster[m]> A little bit of "INSERT AFTER .vector_table" and we're all good.

01:46 <adamgreig[m]> thejpster: it was added in https://github.com/rust-embedded/cortex-m/commit/bf99836c09e6e5cab058fed4ffe38b9c3f8282b0 with "This commit also adds and exposes a few more stable address start/end symbols (__[se]uninit, __stext, __srodata) that are usefull for debugging and hooking into."

07:31 <danielb[m]> <M9names[m]> "my guess was 50% too high. guess..." <- technically "500 at least" isn't **wrong**

10:31 <Ralph[m]> is this a good approach for updating to the latest RC? i thought i'd give it a try, but i'm a bit unsure about whether this is really idiomatic rust?

10:31 <Ralph[m]> https://github.com/stm32-rs/stm32f4xx-hal/pull/715

10:36 <Lumpio-> I wonder what a practical use case for "ToggleableOutputPin" is

10:41 <JamesMunns[m]> bitbanged 1wire or i2c?

10:42 <JamesMunns[m]> oh no, that's not like an InputOutputPin

10:42 <JamesMunns[m]> it's just stateful?

10:43 <JamesMunns[m]> Yeah then I dunno why ToggleableOutputPin and StatefulOutputPin aren't the same :p

10:43 <JamesMunns[m]> I guess most OutputPins will just impl all three traits

10:45 <Lumpio-> I don't see why fn toggle() is not just a method on StatefulOutputPin, could even have a default impl

10:49 <M9names[m]> i guess it's theoretically possible to have an output pin that you can't read the current state of, but you can set a toggle flag in hardware

10:53 <Lumpio-> Very theoretically.

10:53 <Lumpio-> I would like to have a word with whoever designed that hardware

10:57 <vollbrecht[m]> the only think logical for me here would be, if some hardware has a direct toggle hardware pin capability's. In other words one don't need to read the state of the register one just can toggle. Not every set of hardware can do that. But i suspect that is lost anyway in the abstraction and people just implement the functionality in software

11:00 <Lumpio-> idk just struck me as a weird thing to have in a general HAL for the one bizarre chip out there where you can toggle but not read the state of the pin

11:01 <Lumpio-> I'd just have put it as a method with a default impl on StatefulOutputPin

11:01 <vollbrecht[m]> Lumpio-: i mean it in a way that you can have that in one instruction, obviously there should be no hardware where you cant read the state - or its really niche :D

11:02 <vollbrecht[m]> but yeah from a hal perspective its wired

11:02 <M9names[m]> would a default impl interfere with a chip where you can toggle the pin without reading the current state?

11:02 <Lumpio-> No, because a default impl can be overridden to use the "more efficient" method if the hardware supports it

11:03 <Lumpio-> Same answer for vollbrecht[m]

11:07 <Lumpio-> I guess I'll open an issue to see if smarter people can come up with an explanation for having it

13:30 <johannes[m]> Hi, I'd like to use [`lora-phy`](https://github.com/lora-rs/lora-rs/tree/main/lora-phy) with `RTIC` but `lora-phy` seems to require an async HAL. Are there any async HALs for the `stm32wl55` or will I have to implement the required `embedded_hal_async` traits myself?

13:38 <explodingwaffle1> <johannes[m]> "Hi, I'd like to use [`lora-phy`]..." <- you can use the embassy-stm32 HAL with rtic

14:42 <johannes[m]> Ah, I was not aware of that. I'll try that, thanks.

14:46 <firefrommoonligh> FYSA, I am un-asyncing lora-phy

14:47 <firefrommoonligh> But it doesn't work yet... or more likely I forgot to wire something up on the test board.

14:52 <johannes[m]> <firefrommoonligh> "FYSA, I am un-asyncing lora-phy" <- Is that published anywhere?

14:54 <firefrommoonligh> No. I'll publish it if it works or if I can make it generic

14:54 <firefrommoonligh> I can send you the codes if you'd like, but I think not worth it until I get it working

14:55 <firefrommoonligh> RN i can't even do a successful register read...

15:00 <firefrommoonligh> Mode 0, 10Mhz SPI clock... hmm

15:07 <johannes[m]> hmm I will try getting the embassy HAL to work with RTIC and if that does not work I'll just use stm32wlxx-hal to replicate the lora-phy functionality

19:13 <spinfast[m]> <firefrommoonligh> "FYSA, I am un-asyncing lora-phy" <- What inspired that?

19:36 <dirbaio[m]> <spinfast[m]> "What inspired that?" <- he doesn't like async

19:37 <spinfast[m]> hah, well I haven't tried debugging any async rust code in embedded yet, but I imagine that not being very pleasant

19:38 <spinfast[m]> then again having the async stuff generate state machines for running things semi-concurrently seems appealing

19:41 <spinfast[m]> its not like rtos scheduled threads is free of this problem either... but the debuggers can be made aware of thread stacks and such, can gdb be made aware of async tasks like that in some manner?

19:42 <spinfast[m]> like could you step through an async task as if it were a thread in gdb? that would make the debugging aspect maybe less annoying perhaps

19:43 <JamesMunns[m]> It's possible, with tooling: https://cliffle.com/blog/lildb/

19:43 <spinfast[m]> thats neat

19:44 <dirbaio[m]> async single-stepping mostly works with probe-rs

19:44 <JamesMunns[m]> There are also options like defmt and tracing (the unreleased v0.2 branch does not require an allocator), as well that are not gdb based

19:44 <dirbaio[m]> it breaks down if the binary is build with optimizations, but so does non-async single-stepping

19:45 <JamesMunns[m]> fwiw: I've found LTO breaks GDB a lot more than regular optimizations do

19:46 <JamesMunns[m]> GDB works pretty well with no lto and opt z/3 in my experience

19:46 <dirbaio[m]> async singlestepping doesn't work with gdb, but that's more like gdb's fault rather than async's

19:46 <dirbaio[m]> * doesn't work well with gdb,

19:47 <JamesMunns[m]> I suspect LLVM lto just does a bad job preserving debug transformations, error guess/opinion tho

19:47 <dirbaio[m]> I haven't found debugging to be an issue with async, no

19:47 <JamesMunns[m]> s/error/wild/

19:47 <dirbaio[m]> I use print-based debugging most of the time though:D

19:47 <dirbaio[m]> * time though :D

19:48 <dirbaio[m]> * so I haven't

20:21 <dngrsspookyvisio> can you do tracing spans with defmt? that could be useful for untangling async logs

20:25 <JamesMunns[m]> Not out of the box. You could probably fork tracing to used defmts interning machinery instead tho

20:25 <JamesMunns[m]> s/used/use/

20:31 <dngrsspookyvisio> I'll just throw this on the big pile of "projects I'll surely get to someday"

23:21 <rmsyn[m]> I'm working on a bare-metal example program on a risc-v board, and having big trouble getting even the most basic program to actually run. I've hooked up a debugger, and the program appears to get stuck in `_start` and `_abs_start` without ever entering `main`. I'm using `riscv-rt` for startup code

23:22 <rmsyn[m]> here is a link to the example program: <https://github.com/rmsyn/jh71xx-hal-examples/blob/main/src/blinky.rs>

23:22 <rmsyn[m]> it's just meant to blink an LED off and on

23:23 <rmsyn[m]> am I doing anything obviously wrong here?

23:24 <rmsyn[m]> have tried enabling/disabling GPIO interrupts (the line with `ioirq` setting), but the program doesn't even appear to enter `main`

23:26 <rmsyn[m]> for more context, I'm running this program on the board via u-boot `go` in `s-mode`

23:28 <Darius> if it is stuck in start then I woudl check the linker file is correct

23:29 <rmsyn[m]> alright, this is the linker script: <https://github.com/rmsyn/jh71xx-hal-examples/blob/main/memory.x>

23:29 <rmsyn[m]> the `RAM` `ORIGIN` address is the `loadaddr` address in u-boot

23:30 <rmsyn[m]> does that sound correct?

23:30 <Darius> do you hve any working code to start frm?

23:31 <rmsyn[m]> u-boot and opensbi, nothing in rust

23:31 <rmsyn[m]> this `blinky` program is meant to be the most bare bones thing to get visible output that code is running on the board

23:32 <rmsyn[m]> `oreboot` has support for the board I'm working on, but I have yet to get it to run properly

23:36 <Darius> might be worth digging into why

23:36 <Darius> I would alos check to make sure the resulting file has sensible value for where things are located

23:37 <rmsyn[m]> couldn't get the `oreboot` build to go correctly because it relies on private/local clones of public repos to build u-boot style headers

23:38 <rmsyn[m]> even swapping out those tools with equivalents / reverting to the public versions, couldn't get the binary to boot

23:39 <rmsyn[m]> might be worth further debugging, but it's a more complex program

23:39 <rmsyn[m]> trying to get a minimum bare-metal program to run on the board

23:47 <rmsyn[m]> here is a disassembly of the resulting binary with debug symbols: <https://github.com/rmsyn/jh71xx-hal-examples/blob/main/disasm.S>

23:47 <rmsyn[m]> *partial disassembly