<Noah[m]>
<mohdrais[m]> "How to bypass probe-rs?" <- what do you mean? :)
M9names[m] has joined #rust-embedded
<M9names[m]>
You can flash code directly by converting your elf file to uf2 if you don't want to use a debugger, no need to use a specific IDE.
<M9names[m]>
I still recommend using probe-rs while developing new code though, because it's the most reliable way to deal with panics. There are other strategies, but they are harder to use and can fail on some types of errors
<M9names[m]>
(they gave additional context when asking on discord, they want to program a pico W)
<M9names[m]>
general process is listed under "Loading a UF2 over USB"
IlPalazzo-ojiisa has joined #rust-embedded
tamme[m] has joined #rust-embedded
<tamme[m]>
Hey I recently finished my work on a PR to the ina219 crate. It started out as just adding a way to configure the chip, but ended up more like a rewrite of the driver. I would love any feedback, especially about API design/docs and my build.rs to generate both blocking and sync driver: https://github.com/scttnlsn/ina219/pull/3
xerpi[m] has joined #rust-embedded
<xerpi[m]>
When I receive the UART interrupt I read all the data available and push it to the queue. Then I want to wake-up the lower-priority software task to start processing.
<xerpi[m]>
Hi! I'm writing an STM32 based RTIC project that uses `heapless::spsc` to pass commands from an UART interrupt handler to a lower priority RTIC software task for later execution.
<xerpi[m]>
Would it be a good idea to spawn the task with `handler::spawn().ok()` (since _An attempt to spawn an already spawned task (running) task will result in an error_)? For example, it could happen that while the lower-priority SW task is running a new UART interrupt comes and it preempts the handler so calling `spawn()` again would result in an error.
<dirbaio[m]>
You probably want to use an async channel instead of heapless's
<xerpi[m]>
I was thinking that since my queue has a single consumer and a single producer it would probably be more performant to use an SPSC rather than a MPSC
<dirbaio[m]>
It doesn't make much of a difference in practice
<xerpi[m]>
Thank you very much, I'll use an async channel then! 😄
<dirbaio[m]>
heapless's is spsc because it does smart lockfree stuff with atomics
<dirbaio[m]>
But if you're then doing an async spawn anyway after, that uses critical section mutexes anyanyway
<dirbaio[m]>
Vs the rtic-sync async channel uses mutexes in the first place for the channel, which allows mpsc "for free"
<xerpi[m]>
I see, so using heapless + spawn would be doing atomic/critical "stuff" twice
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
JamesMunns[m] has quit [Quit: Idle timeout reached: 172800s]
cesnel[m] has quit [Quit: Idle timeout reached: 172800s]