<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.
<re_irc>
<@dirbaio:matrix.org> you can do it using a DelayUs directly
<re_irc>
<@dirbaio:matrix.org> like, if you need a delay between transactions while CS is deasserted,
<re_irc>
<@dirbaio:matrix.org> do one transaction, then do a delay, then do the other transaction
<re_irc>
<@dirbaio:matrix.org> * delay using the DelayUs trait,
<re_irc>
<@dirbaio:matrix.org> there's no need to build that into SPI
<re_irc>
<@tommygilligan:matrix.org> 👍️
<re_irc>
<@tommygilligan:matrix.org> thank you
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue3 has quit [Ping timeout: 240 seconds]
starblue3 has joined #rust-embedded
dgoodlad has joined #rust-embedded
dgoodlad has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dgoodlad has joined #rust-embedded
dgoodlad has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<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)?
<re_irc>
In the lib Tommy G linked a delay of only 50ns is required, so it feels wasteful to delay 1us.
<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...
<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?
<re_irc>
CC also
<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
<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
<re_irc>
<@romancardenas:matrix.org> Tests pass for al targets except riscv32i-unknown-none-elf, in which I get the following error:
<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
<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 :(
<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
<re_irc>
<@romancardenas:matrix.org> Tests pass for al targets except riscv32i-unknown-none-elf, in which I get the following error:
<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
<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 :(
<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.
<re_irc>
<@romancardenas:matrix.org> Tests pass for all targets except riscv32i-unknown-none-elf, in which I get the following error:
<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
<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 :(
starblue3 has quit [Ping timeout: 245 seconds]
<re_irc>
<@burrbull:matrix.org> Alternative is to change implemetation. Call "disable" on "set_off" and call "enable" on each "set_duty".
starblue3 has joined #rust-embedded
<re_irc>
<@rursprung:matrix.org> : you mean in the stm32f4xx-hal implementation itself? that's what i was wondering...
<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.
<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.
<re_irc>
which should build and do essentially the same thing if i'm right.
<re_irc>
not_abort:
<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?)
<re_irc>
<@onsdag:matrix.org> * away in memory,
<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.
<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...
<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.
<re_irc>
<@zuubek:matrix.org> * and
<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
<re_irc>
<@k900:conduit.0upti.me> So like, just do that?
<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.
<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
<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...
<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).
<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.
<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 :)
<re_irc>
<@romancardenas:matrix.org> : I will, thank you!
<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
<re_irc>
I'll keep plugging away. Thank you K900 and !
<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
<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)
<re_irc>
<@thejpster:matrix.org> has anyone here done any psoc6 stuff?
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<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?
<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.
<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
<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
<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)
<re_irc>
<@grantm11235:matrix.org> iirc, without a fliplink or a mpu, a stack overflow will just start corrupting statics without raising a fault
<re_irc>
<@jamesmunns:beeper.com> OH, RIGHT, stack grows that way
<re_irc>
<@jamesmunns:beeper.com> I take back my "maybe not" and now update to "totally could be" :D
<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.
<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.
<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
<re_irc>
<@xgroleau:matrix.org> * no fliplink since I'm using an nrf52 with a softdevice :/.
<re_irc>
<@jamesmunns:beeper.com> Do you have a debugger hooked up or some other way of getting this, or is it decently reproducible?
<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.
<re_irc>
<@xgroleau:matrix.org> The debugger is hooked up and it's not easily reproductable. Though the bug exists on two different devices
<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
<re_irc>
<@jamesmunns:beeper.com> ah no, in that case the info is zero, and the pc should point to your code.
<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
<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.
<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.
<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 :/
<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.
<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.
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]