01:25 <re_irc> <@tommygilligan:matrix.org> thank you for the new release! <3 noticed the new delay operation for SPI trait and thought it might be useful for something i was using. https://gitlab.com/jspngh/rfid-rs/-/issues/15#note_1457816080 . does it make sense for embedded-hal to also provide de-asserted delays? not sure how many devices out there use this but if most of the work has already been done then it might be a trivial addition.

01:28 <re_irc> <@dirbaio:matrix.org> you can do it using a DelayUs directly

01:28 <re_irc> <@dirbaio:matrix.org> like, if you need a delay between transactions while CS is deasserted,

01:28 <re_irc> <@dirbaio:matrix.org> do one transaction, then do a delay, then do the other transaction

01:28 <re_irc> <@dirbaio:matrix.org> * delay using the DelayUs trait,

01:29 <re_irc> <@dirbaio:matrix.org> there's no need to build that into SPI

01:29 <re_irc> <@tommygilligan:matrix.org> 👍️

01:29 <re_irc> <@tommygilligan:matrix.org> thank you

07:06 <re_irc> <@jspn:matrix.org> : To piggyback on this, does anyone have a good way to delay less than 1us (especially in a driver crate)?

07:06 <re_irc> In the lib Tommy G linked a delay of only 50ns is required, so it feels wasteful to delay 1us.

08:44 <re_irc> <@rursprung:matrix.org> : i just tested the new "SetDutyCycle" API of e-h 1 which you introduced a while ago (https://github.com/rust-embedded/embedded-hal/pull/430) (thanks again for that!) with an STM32 for the first time (with my small project (https://github.com/rursprung/tb6612fng-rs/pull/18)) and noticed that you have removed (or rather: not re-added) the "enable" and "disable" methods from the trait. however, without this the PWM channel...

08:44 <re_irc> ... is never enabled in stm32f4xx-hal (see the API implementation (https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/timer/hal_1.rs#L36-L46)).

08:44 <re_irc> what is the intention here? should i now call it in the non-generic part of the code (which has it as an STM32 variable and thus can call "enable" on it) or should stm32f4xx-hal call "enable" implicitly?

08:44 <re_irc> CC also

09:19 <re_irc> <@romancardenas:matrix.org> Hi again! I'd like to ask for help for an issue with "riscv-rt". I am trying to use inline assembly instead of blobs. I took a look to "esp-riscv-rt" and the original assembly code in "riscv-rt" and I think my implementation looks OK: https://github.com/rust-embedded/riscv-rt/tree/global_asm

09:20 <re_irc> <@romancardenas:matrix.org> You can find the inline assembly in "src/asm.rs" and the generated assembly code for different targets in "asm". I couldn't find any issue

09:21 <re_irc> <@romancardenas:matrix.org> However, when testing this version with a real target, I get a linker error. I set up the CI to capture this issue: https://github.com/rust-embedded/riscv-rt/actions/runs/5473634656

09:23 <re_irc> <@romancardenas:matrix.org> Tests pass for al targets except riscv32i-unknown-none-elf, in which I get the following error:

09:23 <re_irc> note: rust-lld: error: riscv_rt.ac96fd92-cgu.6:(.init+0x94): relocation R_RISCV_BRANCH out of range: 2212 is not in [-2048, 2047]; references abort

09:23 <re_irc> I get a similar error if I try to build any example for the a HiFive1 board, and I don't know how to debug this :(

09:25 <re_irc> <@romancardenas:matrix.org> You can find the inline assembly in "src/asm.rs" and the generated assembly code for different targets in the "asm/" folder (including the original assembly code in the current version of "risv-rt"). I couldn't find any issue

09:26 <re_irc> <@romancardenas:matrix.org> Tests pass for al targets except riscv32i-unknown-none-elf, in which I get the following error:

09:26 <re_irc> note: rust-lld: error: riscv_rt.ac96fd92-cgu.6:(.init+0x94): relocation R_RISCV_BRANCH out of range: 2212 is not in [-2048, 2047]; references abort

09:26 <re_irc> I get a similar error if I try to build any example for the a HiFive1 board (riscv32imac-unknown-none-elf), and I don't know how to debug this :(

09:50 <re_irc> <@burrbull:matrix.org> : I think you could use inherent "enable" method of "PwmChannel" in user code and then use "set_on/off" from "SetDutyCycle" trait.

09:53 <re_irc> <@romancardenas:matrix.org> Tests pass for all targets except riscv32i-unknown-none-elf, in which I get the following error:

09:53 <re_irc> note: rust-lld: error: riscv_rt.ac96fd92-cgu.6:(.init+0x94): relocation R_RISCV_BRANCH out of range: 2212 is not in [-2048, 2047]; references abort

09:53 <re_irc> I get a similar error if I try to build any example for the a HiFive1 board (riscv32imac-unknown-none-elf), and I don't know how to debug this :(

09:56 <re_irc> <@burrbull:matrix.org> Alternative is to change implemetation. Call "disable" on "set_off" and call "enable" on each "set_duty".

10:00 <re_irc> <@rursprung:matrix.org> : you mean in the stm32f4xx-hal implementation itself? that's what i was wondering...

10:00 <re_irc> in my use-case i don't need to disable/enable it again after initially enabling it once (i.e. i can easily enable it), however other use-cases might be different here.

10:00 <re_irc> i have now temporarily moved the "enable" call to the setup procedure (not part of the library), however i'm holding off on pushing this for now (i'm anyway waiting for the embedded-hal-mock dependency which first needs to bump to the new alpha release and add a mock for the new API) until it's clear what the intention with this API design is.

12:44 <re_irc> <@onsdag:matrix.org> : i think the error points to this line https://github.com/rust-embedded/riscv-rt/blob/ba1b499a7a252466528d6d6d8889633680d1dfc0/src/asm.rs#L95C23-L95C23 , and would imply you're branching out of range. you can verify this by replacing it with something like

12:44 <re_irc> bleu t2, t0, not_abort

12:44 <re_irc> jr t0

12:44 <re_irc> la t0, abort

12:44 <re_irc> which should build and do essentially the same thing if i'm right.

12:44 <re_irc> not_abort:

12:46 <re_irc> <@onsdag:matrix.org> if that's the case the abort routine is too far away, so the real way to fix it would be to place it closer (maybe in the same section?)

12:48 <re_irc> <@onsdag:matrix.org> * away in memory,

14:19 <re_irc> <@romancardenas:matrix.org> : thanks so much! Your patch did the trick. I'll play around with it and try what you suggested about moving abort to the same section.

14:34 <re_irc> <@zuubek:matrix.org> *Going beyond main.rs?*

14:34 <re_irc> Hi folks, as an embedded developer who's worked with C for many years I am having a hard time grasping how to build firmware in Rust without dumping everything in the main.rs file. I love what the community has done, the what the HAL provides but I have this mental block on how to actually build a non-trivial FW example. I understand that there are frameworks like RTIC and Embassy which can simplify this type of development but I am trying to...

14:34 <re_irc> ... build my knowledge from the basics before I tackle more complex frameworks. Every example I run across online either throws everything in main.rs, and if they don't then they are almost always using one of the above mentioned frameworks. Does anyone here have any advice for a beginner (in Rust) regarding how to structure a baremetal FW in rust? An example or two which I could read to understand would be very helpful.

14:36 <re_irc> <@zuubek:matrix.org> * and

14:36 <re_irc> <@k900:conduit.0upti.me> I don't think there's a major difference between how you'd split code in C and how you'd do it in Rust, honestly

14:36 <re_irc> <@k900:conduit.0upti.me> So like, just do that?

14:38 <re_irc> <@juliand:fehler-in-der-matrix.de> : https://github.com/nviennot/turbo-resin/tree/main this is often referred to as an example of a bigger embedded project in Rust. Maybe that's interesting for you.

14:39 <re_irc> <@onsdag:matrix.org> : i felt extra productive today so i whipped up a fix via the linker script and moving the abort loop closer that leaves the old branch intact. made a PR, so have a look

14:44 <re_irc> <@rursprung:matrix.org> i try to split things along "natural" boundaries, just like i'd do for any software (i come from the enterprise software world): e.g. if i have several drivers which i need and they don't exist yet then i'll build them as separate crates (presuming that it's hardware available on the market i'll just publish it to github & crates.io for everyone to use) and pull those in. then any logic goes into its dedicated libraries...

14:44 <re_irc> ... (either standalone libraries if it's something which makes sense to re-use also outside of the project or otherwise it's just a module within the main project; refactoring from a module into a dedicated library is however of course also always possible later and starting with a module might be faster).

14:44 <re_irc> the nice thing about rust is that you get abstractions like embedded-hal (https://crates.io/crates/embedded-hal), so i try to write most (or all) of the "business logic" against that rather than a specific hardware crate. this gives me the freedom to later port it more easily to other hardware.

14:45 <re_irc> disclaimer: i haven't done a lot of embedded development yet. but i have more than a decade of experience in designing & splitting (very, very) large software :)

14:46 <re_irc> <@romancardenas:matrix.org> : I will, thank you!

14:52 <re_irc> <@zuubek:matrix.org> Fair enough, I think its just my ignorance. I'm the type of person to learn by example and just haven't come across any decent examples yet

14:52 <re_irc> I'll keep plugging away. Thank you K900 and !

15:42 <re_irc> <@rursprung:matrix.org> if you want a small example which is however far from perfect (i had to time-box it and take some shortcuts; with this being a small project for university it was throw-away code anyway - except for the libraries which i created in the process and have published separately) you can have a glance at this: https://github.com/rursprung/robotcar1

15:42 <re_irc> (i'm not completely happy with the split as it is, i do think that the separation of concern could've been done much, much better. but there's a trade-off to be done and obviously that's not the same here as for a long-lived well-staffed software with the necessary $$$ behind it)

15:43 <re_irc> <@thejpster:matrix.org> has anyone here done any psoc6 stuff?

17:15 <re_irc> <@xgroleau:matrix.org> I'm getting an hard fault on cortex-m that skipped the panic handler and the UFSR has the UNDEFINSTR enabled and HFSR has the FORCED enabled. Are those signs of a stack overflow?

17:30 <re_irc> <@jamesmunns:beeper.com> probably hard to diagnose from just that (can you read the stack pointer?), I think a stack overflow would cause some other fault (bus error?), but maybe my memory is wrong. I think interrupt has a good post about diagnosing hardfaults somewhere.

17:30 <re_irc> There are some things that will generate UDFs, like generally UB type things, or if you have panic-immediately-abort set, or if your panic handler emits a UDF instruction

17:30 <re_irc> <@jamesmunns:beeper.com> hardware wise, it could be an issue reading flash, like if you have an external flash chip, or an internal flash with the wrong number of wait states

17:31 <re_irc> <@jamesmunns:beeper.com> (but don't take this as "definitely not a stack overflow", it's been a while since I had to diagnose this, and if your chip doesn't emit some other hard fault on an access violation outside of RAM, I could see it loading bad data and causing something to go haywire)

17:32 <re_irc> <@grantm11235:matrix.org> iirc, without a fliplink or a mpu, a stack overflow will just start corrupting statics without raising a fault

17:32 <re_irc> <@jamesmunns:beeper.com> OH, RIGHT, stack grows that way

17:32 <re_irc> <@jamesmunns:beeper.com> I take back my "maybe not" and now update to "totally could be" :D

17:33 <re_irc> <@jamesmunns:beeper.com> the other stuff I mentioned could be problems too, but corrupted statics can totally make things go haywire in unpredictable ways that could show up as undefined instructions.

17:36 <re_irc> <@jamesmunns:beeper.com> https://interrupt.memfault.com/blog/cortex-m-hardfault-debug is also always a good read.

17:36 <re_irc> <@xgroleau:matrix.org> Thanks for the pointers (no pun intended). And yea no fliplink since I'm using an nrf52 with a softdevice. Also the PC is 0 in the exception frame for some reason and the LR points to 0xE000EDF8, which is the DebugCoreDataRegister. Not sure why it's pointing there.

17:36 <re_irc> I don't have a lot of unsafe code but I am using external C libraries so I'll try to verify both

17:37 <re_irc> <@xgroleau:matrix.org> * no fliplink since I'm using an nrf52 with a softdevice :/.

17:38 <re_irc> <@jamesmunns:beeper.com> Do you have a debugger hooked up or some other way of getting this, or is it decently reproducible?

17:44 <re_irc> <@jamesmunns:beeper.com> Also depending on what you are doing with a debugger attached, IIRC the SoftDevice gets REAL MAD about certain debugging operations as an anti-reverse-engineering measure.

17:44 <re_irc> https://github.com/embassy-rs/nrf-softdevice also lists some practical limitations and things that will cause hard faults.

17:47 <re_irc> <@jamesmunns:beeper.com> https://github.com/embassy-rs/nrf-softdevice/issues/45#issuecomment-766396832 maybe sounds interesting

17:47 <re_irc> <@xgroleau:matrix.org> The debugger is hooked up and it's not easily reproductable. Though the bug exists on two different devices

17:48 <re_irc> <@xgroleau:matrix.org> I doubt it's the softdevice itself since the bug occurs when the device is not connected to a debugger

17:48 <re_irc> <@jamesmunns:beeper.com> ah no, in that case the info is zero, and the pc should point to your code.

17:48 <re_irc> <@xgroleau:matrix.org> The debugger is hooked up right now and it's not easily reproductable. Though the bug exists on two different devices

17:49 <re_irc> <@jamesmunns:beeper.com> > If your SoftDevice is hardfaulting on enable and you think you have everything right, make sure to go back and do a full chip erase or recover, and reflash the SoftDevice again. A few bytes of empty space after the SoftDevice are required to be 0xFF, but might not be if the softdevice was flashed over an existing binary.

17:49 <re_irc> Is the only other "immediately relevant sounding" thing I've seen so far. Not sure if you're using the "nrf-softdevice" crate or not.

17:51 <re_irc> <@jamesmunns:beeper.com> But I'll stop guessing now. I might suggest dropping by the embassy room, since dirbaio has a ton of nrf52 experience (a lot more than me), but good luck :/

17:51 <re_irc> <@xgroleau:matrix.org> Yep I'm using the "nrf-softdevice" crate. I'll try to do a full erase and run again and check if the hardfault still occurs and if so if it's the same cause.

17:52 <re_irc> <@xgroleau:matrix.org> Thanks! First time in 2 years that we have a hardfault, much better our old C codebase, but they are always a pain to diagnose and fix whatever the language.