danielb[m] has quit [Quit: Idle timeout reached: 172800s]
<mameluc[m]>
<zeenix[m]> "The last error is from probe-rs" <- strange that it doesnt connect. are all your jumpers in the original factory configuration?
<mameluc[m]>
mameluc[m]: sometimes I have had luck spamming the reset button too but that is kind of glitchy and mostly just relevant if there is bad fw on the device. this nucleo is fresh from the box?
pcs38 has joined #rust-embedded
<zeenix[m]>
<mameluc[m]> "strange that it doesnt connect..." <- Yeah
<zeenix[m]>
<mameluc[m]> "sometimes I have had luck..." <- Yup
<zeenix[m]>
zeenix[m]: Perhaps there are some diffs with the latest (version 2)
<zeenix[m]>
zeenix[m]: Reading the error from probe-rs, I thought I just need to somehow make one if the algorithms the default or choose one on the probe-rs cmdline
<zeenix[m]>
<mameluc[m]> "20250316_141154_4458608986223533..." <- yours is a C1, mine is C2
<mameluc[m]>
zeenix[m]: what made it work?
<zeenix[m]>
mameluc[m]: oh, forgot to metion the important bit: editted the file to mark only the `cm4` as the default flasher
<zeenix[m]>
zeenix[m]: `default: false` had to be set for other 2
<mameluc[m]>
zeenix[m]: ah
<mameluc[m]>
mameluc[m]: in the beginning I never got it working so I used stm32wle as "chip". you did it the proper way
<zeenix[m]>
mameluc[m]: but one of the commands you pasted here, did first enable probe-rs to even talk to the chip so thanks so much for that 🙏
* zeenix[m]
will document this for the next person :)
<mameluc[m]>
zeenix[m]: good. feel free to join Rust LoRa/LoRaWAN for any lora-rs questions
<zeenix[m]>
mameluc[m]: oh thanks. I was told that there is a channel for lora-rs but wasn't able to find it
<mameluc[m]>
zeenix[m]: it started as all things rust + lora but then we put all we had under lora-rs so now the name is confusing :D
sroemer has quit [Quit: WeeChat 4.4.3]
sroemer has joined #rust-embedded
U007D[m] has joined #rust-embedded
<U007D[m]>
Hi, everyone.
<U007D[m]>
Staying completely within the Rust build system (i.e. no Bash scripts or makefiles, etc.), is there a way to set the target triple based on the `cargo` feature the user has selected without using `build.rs`?
<danielb[m]>
not to my knowledge but you can create an alias for commands like cargo build_board_a
<U007D[m]>
danielb[m]: Thanks. I'm hoping I was missing some workaround, since Cargo's conditional compilation capabilities are otherwise quite powerful.
<U007D[m]>
* Thanks. I'm hoping I'm missing some workaround, since Cargo's conditional compilation capabilities are otherwise quite powerful.
<U007D[m]>
* Thanks. I'm hoping I'm missing some workaround, since Cargo's conditional compilation capabilities are otherwise quite powerful. In embedded at least, this seems like useful capability.
<U007D[m]>
> Note that the environment variables here are intended for global environment variables like CC and such, it is not possible to use this for environment variables like TARGET that Cargo sets for build scripts. The environment variables in use are those received by cargo invocations, not those received by the executable of the build script.
<U007D[m]>
I can't be the only person trying to build a platform-agnostic solution... Are there *any* solutions to this within the `cargo` build system (`build.rs` included)?
<danielb[m]>
you can set the build target in .cargo/config.toml, but that's not automatic so you can end up with a mismatched target and target-feature. We use an xtask in esp-hal tooling to set it for our examples/tests, but users can't really opt into that for their projects, not easily at least
<U007D[m]>
s/'/`/, s/` -> `/`->`/, s/`./\`./
<U007D[m]>
s/'/`/, s/` -> `/`->`/
<U007D[m]>
danielb[m]: I currently have a `.cargo/config.toml` with its `[build]` table's `target` set (fixed) to `thumbv8m.main-none-eabihf`. Are you suggesting `build.rs` write a new `.cargo.config.toml` on compile with the `target` set appropriately to the currently selected feature? If so:
<U007D[m]>
1) how would they get out of sync?
<U007D[m]>
2) will `cargo` pick up this change in the middle of a compilation?
<U007D[m]>
* I currently have a `.cargo/config.toml` with its `[build]` table's `target` set (fixed) to `thumbv8m.main-none-eabihf`. Are you suggesting `build.rs` write a new `.cargo.config.toml` on compile with the `target` set appropriately to the currently selected feature? If so:
<U007D[m]>
1. how would they get out of sync?
<U007D[m]>
2. will `cargo` pick up this change in the middle of a compilation (after `build.rs` but before `lib.rs`?
<U007D[m]>
* I currently have a `.cargo/config.toml` with its `[build]` table's `target` set (fixed) to `thumbv8m.main-none-eabihf`. Are you suggesting `build.rs` write a new `.cargo.config.toml` on compile with the `target` set appropriately to the currently selected feature? If so:
<U007D[m]>
1. how would they get out of sync?
<U007D[m]>
2. will `cargo` pick up this change in the middle of a compilation (after `build.rs` but before `lib.rs`)?
<danielb[m]>
I am most definitely not suggesting a build.rs to modify the config file.
<danielb[m]>
* I am most definitely not suggesting a build.rs to modify the config file.
<danielb[m]>
I'm not even sure if that would work, or if by that point cargo has the target set in stone
<U007D[m]>
I did explore using conditionals in .cargo/config.toml, but found that [build.'cfg(feature = "board_a")] is definitely not supported in .cargo/config.toml.
<U007D[m]>
* I did explore using conditionals in .cargo/config.toml, but found that [build.'cfg(feature = "board_a")'] is definitely not supported in .cargo/config.toml`.
<U007D[m]>
* I did explore using conditionals in .cargo/config.toml, but found that [build.'cfg(feature = "board_a")'] is definitely not supported in .cargo/config.toml\.
<U007D[m]>
* I did explore using conditionals in .cargo/config.toml, but found that [build.'cfg(feature = "board_a")'] is definitely not supported in .cargo/config.toml.
<U007D[m]>
* I did explore using conditionals in .cargo/config.toml, but found that conditionals (e.g. [build.'cfg(feature = "board_a")']) are not supported in .cargo/config.toml.
<U007D[m]>
So before I do down this path, is the consensus that external scripting is the only way to set the target triple based on cargo feature?
<danielb[m]>
¯\_(ツ)_/¯ the user can do it manually, too
<danielb[m]>
your HAL can error if the target doesn't match
<U007D[m]>
Understood. I'm trying to bake all the tribal knowledge necessary to build into the build system itself--harder to write, but easier to use...
<U007D[m]>
* Understood. I'm trying to bake as much tribal knowledge to build as I. can into the build system itself--harder for me to write, but easier to use...
<U007D[m]>
* Understood. I'm trying to bake as much tribal knowledge to build as I. can into the build system itself--harder for me to write, but easier for anyone to use...
<U007D[m]>
* Understood. I'm trying to bake as much tribal knowledge to build as I can into the build system itself--harder for me to write, but easier for anyone to use...
<U007D[m]>
Thank you--I appreciate your help, even if I didn't hear what I was hoping to hear! 😁
<JamesMunns[m]>
@U007D one thing to note conceptually *why* the build-rs can't affect things like targets:
<JamesMunns[m]>
The build-rs for your final app doesn't run until AFTER all deps have already been compiled, which means it can't impact any compilation steps prior to that.
<JamesMunns[m]>
So yeah, the usual recs here are using something like xtask to do some pre-build scripting.
<JamesMunns[m]>
However, my personal preference is to instead move as much common logic to a lib crate, and have completely separate and very thin bin crates for each of your targets
<JamesMunns[m]>
In this case, common might have some features for tuning things, but those can be set by the bin crates
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
yeah the general idea is to turn your application into a library
<i509vcb[m]>
You should be able to use the type system to make this work out pretty well
<JamesMunns[m]>
yep, usually my rule of thumb is:
<JamesMunns[m]>
* use features and one bin crate when the TARGET is the same, but FEATURES change (for example different PCB revs, or board variants with different hw enablement)
<JamesMunns[m]>
* use separate bin crates and a common lib crate when the MCU and/or architectures differ enough you will want different targets, linker scripts, etc.
<JamesMunns[m]>
I find the latter is a reasonable pattern if you want to do simulated testing, for example running some integration tests in CI, with a "fake" board. you'll end up with your `common` crate mostly generic over embedded-hal or similar traits, which makes "mocking" them easier as well.
<JamesMunns[m]>
* latter is also a reasonable
pcs38 has joined #rust-embedded
<thejpster[m]>
Neotron-OS has binary crates called flash0802, flash0002 and flash1002 - representing the top four hex digits of the load address. The sources are basically a one-liner jumping to the lib. The build.rs sets up a different linker script depending on the binary name (which implies that it runs once per crate).
dav1d has quit [Quit: Ping timeout (120 seconds)]
dav1d has joined #rust-embedded
<U007D[m]>
<JamesMunns[m]> "@U007D one thing to note..." <- That makes sense, when you point it out, thanks.
<U007D[m]>
<JamesMunns[m]> "However, my personal preference..." <- Interesting. I do something like this for all my `std` work, but representing `#[no_std]` hardware abstraction this way makes a lot of sense too--thanks for this!
<U007D[m]>
Thanks, all--James Munns' suggestion should work perfectly for what I am trying to do... Thanks James Munns and 👋!
correctalex[m] has joined #rust-embedded
<correctalex[m]>
Hi folks - not sure if this is the best place to ask, but I'm relatively new to Rust. I have a project where I'm using rtic as executor, and embassy for most other things (mainly, embassy-stm32 as HAL). I have a configured embassy-time to use one of the available hardware timers, and using the generic-queue-* feature, since I'm not using the embassy executor. Now, I have fun problems with e.g. i2c transactions (on two different
<correctalex[m]>
i2c buses) from two different RTIC tasks, where they keep running into timeouts. However, if I only run one rtic task with one of the two i2c buses, everything's fine. It feels like something's going awry with the embassy-time timeout wakeups, maybe because of the way rtic's async executor works. Any hints?
<correctalex[m]>
<correctalex[m]> "Hi folks - not sure if this is..." <- I should probably point out that I'm using the async i2c implementation/traits (with timeouts enabled within embassy-stm32, which is what ends up using embassy-time).
<correctalex[m]>
<correctalex[m]> "I should probably point out that..." <- I did consider whether a way to go here is to somehow implement an embassy-time-driver that uses rtic-monotonics underneath, but that seems like a hell of a rabbit hole, especially considering I'm new to this all.
madb has joined #rust-embedded
wassasin[m] has joined #rust-embedded
<wassasin[m]>
<correctalex[m]> "I did consider whether a way..." <- Just to check, are you using the embassy-stm32 "rt" feature? Waht interrupts did you assign to RTIC to use for the tasks?
<wassasin[m]>
wassasin[m]: I think it is quite simple to make a embassy time-driver implementation that uses rtic monotonics underneath
<correctalex[m]>
wassasin[m]: I'm not using the "rt" feature. Should I?
<wassasin[m]>
correctalex[m]: Yes, for sure. time-driver needs the interrupts to be bound
<correctalex[m]>
wassasin[m]: The tasks are all software tasks, so no dispatcher interrupt (all thread-level).
<wassasin[m]>
correctalex[m]: It does not use embassy-executor, just interrupts
<wassasin[m]>
wassasin[m]: Then RTIC uses the same interrupt level for all tasks
<correctalex[m]>
correctalex[m]: So if it's enabled by default, that ought to have worked, no?
<wassasin[m]>
correctalex[m]: Yes
<correctalex[m]>
wassasin[m]: It's not like embassy-time futures don't wake, it's that they seem to wake... sporadically.
<wassasin[m]>
correctalex[m]: They can also be awoken by polling the futures
<wassasin[m]>
wassasin[m]: So if another interrupt wakes rtic, all futures can be polled
<wassasin[m]>
wassasin[m]: At this stage I would get a debugger and add a watchpoint on TIM3()
<wassasin[m]>
s/watchpoint/breakpoint/
<correctalex[m]>
wassasin[m]: My mental model here, which might well be wrong, is that if a task is suspended awaiting an i2c transaction, then either the i2c irq (or the corresponding DMA channel, whatever), or the timer irq will mark it to be resumed. I assume rtic itself has a WFI when it runs out of things to do at thread level, and then, when the WFI completes, checks all the suspended tasks to see if any of them can be resumed.
<correctalex[m]>
So I'm pretty puzzled as to why this doesn't work.
<correctalex[m]>
correctalex[m]: Maybe an interesting observation - changing embassy-time's tick rate to run faster makes the problems worse.
<wassasin[m]>
correctalex[m]: Sounds like the TIM3 interrupt is working then
<correctalex[m]>
wassasin[m]: It's definitely firing, as timeouts are happening.
<correctalex[m]>
correctalex[m]: It's just that the tasks don't seem to get resumed properly/at the right time.
<correctalex[m]>
correctalex[m]: https://pastebin.mozilla.org/EEDRaGxN -- don't judge it too harshly, it's my first bit of Rust. The issue here is that when both the intake & exhaust tasks are running, neither ends up working properly/resuming at the right time. As it happens, the intake I2C bus doesn't have anything connected, so is expected to just keep failing because of timeouts.
<correctalex[m]>
correctalex[m]: The defmt prints for the outer loop of read_sensors also pop up every 2 seconds or so, implying the two tasks aren't really interleaved, even though they both should be yielding to each other as they await... stuff.
Kert[m] has joined #rust-embedded
<Kert[m]>
correctalex[m]: would trying a different time driver help isolate it ? I wrote a simple standalone systick based timer a few days ago - obviously using systick permanently is going to be costly in terms of interrupt overhead
<Kert[m]>
For debugging, i basically inserted atomic counters in places to figure out what was happening and when
<Kert[m]>
What you mentioned above - wrapping rtic monotonics in an embassy-timer doesn't sound _too complex_ either
<correctalex[m]>
correctalex[m]: Maybe I'll go down the route of trying to write a rtic-monotonics based embassy-time-driver. But it really feels like I'm misunderstanding how the async runtimes work.
<wassasin[m]>
correctalex[m]: Concurrency can only happen across await points
<wassasin[m]>
wassasin[m]: There is not real threading
<correctalex[m]>
wassasin[m]: Sure - but all of these have awaits
<wassasin[m]>
s/not/no/
<wassasin[m]>
correctalex[m]: Is this blocking? "crate::KLIPPER_TRANSPORT.receive"
<correctalex[m]>
wassasin[m]: It effectively calls into those various klipper_commands. But really, nothing's being sent over USB-CDC-ACM, so I don't think that's even being called.
<correctalex[m]>
correctalex[m]: I can comment it out, just in case.
<wassasin[m]>
correctalex[m]: Because you take a lock on the app_state whilst you are doing that
<correctalex[m]>
wassasin[m]: Commented it out, but same thing.
<correctalex[m]>
correctalex[m]: Is there a good way to debug the underlying async runtime?
<wassasin[m]>
correctalex[m]: GDB I guess
<wassasin[m]>
wassasin[m]: For now I recommend putting the i2c tasks in a higher priority software task
<correctalex[m]>
wassasin[m]: Well, somewhat interesting. I've set both of them to priority 1 using some usart irq as dispatcher -- all I see from the various defmt prints now are the ones belonging to those tasks.
<wassasin[m]>
correctalex[m]: rtic-monotic on TIM2 and embassy-time on TIM3 should be able to co-exist just fine
<correctalex[m]>
wassasin[m]: As in, they don't seem to be yielding properly to the lower-priority pulse-counter-task
<wassasin[m]>
correctalex[m]: That's a nice datapoint, probably something is busy-looping
<wassasin[m]>
wassasin[m]: I've got to go, but good luck!