<ian_rees[m]>
anyone here tried using AI tools for embedded Rust?
tschundler has quit [Ping timeout: 248 seconds]
tschundler has joined #rust-embedded
rafael[m] has joined #rust-embedded
<rafael[m]>
<ian_rees[m]> "anyone here tried using AI tools..." <- me. Quite happy with GitHub Copilot in Agent Mode using Claude Sonnet 4 for model. Good experience with Cline using same model.
<rafael[m]>
Hi, has anybody experienced flashing rp2350 via bootsel mode not working? I can flash using probe-rs with my development board and it all works fine, but when I use elf2uf2-rs and manually bootsel & copy onto the target board the copied uf2 just stays in the folder, nothing happens and nothing gets flashed. The target board can be flash-nuked with the same process, so copying uf2 to it works in general. So it appears it must be my
<rafael[m]>
uf2....? The target board has no debug connector (without awkward soldering) so I cannot easily just try probe-rs there to see more. In my code I have reduced clock speed and core voltage quite a lot, am I just hitting the target boards specific limits?
M9names[m] has joined #rust-embedded
<M9names[m]>
don't use elf2uf2-rs, use picotool
<M9names[m]>
elf2uf2-rs hasn't been updated to support rp2350
<M9names[m]>
at least, no released version of it supports rp2350 (open PR, hasn't been merged)
<firefrommoonligh>
I recommend not using the Esp-Hal as something for new people; it's mostly undocumented. I agree with your reasoning on manufacturer support, but from a practical perspective, it's not there. Some day?
<firefrommoonligh>
s/./,/, s/Some/and/, s/day?/the currently-most-prolific maintainer is of the opinion that maintaining examples is impossible./
<diondokter[m]>
Ah hmmm, it appears stdout in a proc macro is forwarded to the console when compiling. That's good!
<diondokter[m]>
I might just do one compile_error! with 'there were errors' and then print all errors to stdout
richardeoin has quit [Ping timeout: 252 seconds]
sroemer has quit [Quit: WeeChat 4.5.2]
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has quit [Quit: Idle timeout reached: 172800s]
jason-kairos[m] has quit [Quit: Idle timeout reached: 172800s]
JamesSizeland[m] has quit [Quit: Idle timeout reached: 172800s]
richardeoin has joined #rust-embedded
Hallo124 has quit [Remote host closed the connection]
Hallo124 has joined #rust-embedded
<thalesfragoso[m]>
<diondokter[m]> "Ah hmmm, it appears stdout in..." <- > <@diondokter:matrix.org> Ah hmmm, it appears stdout in a proc macro is forwarded to the console when compiling. That's good!
<thalesfragoso[m]>
> I might just do one compile_error! with 'there were errors' and then print all errors to stdout
<thalesfragoso[m]>
In proc-macros you usually want to emit the error AND the wrong source. That way you have a better LSP experience.
<thalesfragoso[m]>
You can easily find examples of that, e.g. tokio::main
<thalesfragoso[m]>
Although I think your particular macro isn't supposed to be used with a lot of rust code, so it might not apply to you.
<diondokter[m]>
Yeah, there's no Rust input
<diondokter[m]>
But it does generate a lot of Rust. I can of course still generate the Rust that I can so it lowers the amount of other errors
<thalesfragoso[m]>
Hmm, not sure if it will make things better in this case...
<thalesfragoso[m]>
But worth trying.
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]