<re_irc>
<yruama_lairba> henrik_alser: i was searching something more like the second
<re_irc>
<yruama_lairba> thnaks, it try it now
<re_irc>
<justacec> Lumpio-: Yea... I got a kick out of that.
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
jackneillll has joined #rust-embedded
jackneilll has quit [Ping timeout: 260 seconds]
skunkjoe has joined #rust-embedded
skunkjoe has quit [Ping timeout: 240 seconds]
<re_irc>
<justacec> I am a new user to probe-run. Is it typical that it takes 30% of the CPU and kicks the fan up? Or do I just have something configured wrong?
<re_irc>
<justacec> invoked via "probe-run --chip STM32WLE5JCIx target/thumbv7m-none-eabi/debug/Firmware"
<re_irc>
<justacec> (wait I should ask that in the probe-rs channel)
<re_irc>
<justacec> disreguard
<re_irc>
<korken89> justacec: probe-run is not developed by probe-rs, probe-run only uses probe-rs as a library
<re_irc>
<korken89> Maybe make an issue on their issue tracker
<re_irc>
<justacec> Got it. Thanks.
Guest2 has joined #rust-embedded
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
stephe has joined #rust-embedded
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 272 seconds]
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
Amadiro has quit [Quit: Leaving]
skunkjoe has joined #rust-embedded
skunkjoe has quit [Ping timeout: 272 seconds]
<re_irc>
<yruama_lairba> hello, hi have a question on how to correctly represent a situation. I did a system where a task and a DMA may access to the same buffer. While it's not desirable, i don't really care about data corruption, and i wondered if there is a correct way to represent this kind of situation ?
<re_irc>
<ryan-summers> IMO: You should think carefully about why you think data corruption is fine in your use case. I wouldn't try to intentionally work around Rust's safety rules - there's a reason memory ownership is such a powerful tool
<re_irc>
<henrik_alser> yruama_lairba: The most widely used approach is using some kind of Transfer struct that owns the buffer and the peripheral, what hal do you use?
<re_irc>
<ryan-summers> I think what they're saying is that they want to have the DMA own some memory buffer, but also want to access it from the higher level app at the same time
<re_irc>
<ryan-summers> But that sort of violates Rust's ownership model on memory, so obviously anything where there's two mutable owners of the buffer would always have to be surrounded in "unsafe"
<re_irc>
<yruama_lairba> the data are actually audio data, so corrupting them can just be seen as noise
<re_irc>
<ryan-summers> -sort of
<re_irc>
<ryan-summers> I still wouldn't say that's not a bug. But if it's a bug you're intentional about and okay with, you can always use unsafe to conjure references to the buffers. I just highly recommend not doing that because it's such a foot gun
<re_irc>
<yruama_lairba> and i don't use hal for that because it just didn't exist at the time i writed this code
<re_irc>
<ryan-summers> Check out the DMA ownership semantics of the H7 HAL if you want a reference DMA implementation. You should never really access the buffer whenever DMA might be using it
<re_irc>
<chrysn (@chrysn:matrix.org)> I'm with ryan on "be careful"; you can limit the harm you're risking by not unsafely conjuring a mutable reference to the whole memory, but only using a mutable pointer (to a slice of that memory) and write through the pointer.
<re_irc>
<ryan-summers> chrysn: Yes, this. I'm pretty sure creating a new slice by unsafely conjuring a reference to other memory breaks safe Rust's rules. So keep it all unsafe
<re_irc>
<yruama_lairba> chrysn: yes, i was thinking about an objet doing voltatile access to the buffer to reduce side effects
<re_irc>
<ryan-summers> I still think you're throwing away a lot of value by doing that
<re_irc>
<henrik_alser> What chip are you on?
<re_irc>
<yruama_lairba> the situtatiion i describe doesn't happen in normal situation, it just may happen sometime
<re_irc>
<yruama_lairba> using stm32F411
<re_irc>
<yruama_lairba> in fact, in theory, this situation never happen if the task meets a timing guarantee. But i can't always ensure this guarantee.
<re_irc>
<henrik_alser> The stm32f4xx-hal has an api for safe DMA
<re_irc>
<henrik_alser> Is it i2s over spi or sai?
<re_irc>
<yruama_lairba> i think i could use double buffering feature of DMA to strictly comply with rust rules, but not meeting time requirment will still making noise :)
<re_irc>
<yruama_lairba> duplex I2s over spi
<re_irc>
<henrik_alser> What is the source of audio data?
<re_irc>
<yruama_lairba> there currently no I2s hal handling I2ext
<re_irc>
<ryan-summers> We use double buffering for pretty much this exact same thing in Stabilizer, and we can guarantee timing is met, but it's as simple as not unwrapping a Result indicating error if you failed to meet timing I believe
<re_irc>
<yruama_lairba> and last time i watched to dma hal (six month ago) it's wasn't possible to do cycling dma
<re_irc>
<ryan-summers> The H7 HAL supports it, not sure about the F4 though
<re_irc>
<yruama_lairba> i remenber one thing that may impossible to represent safely in a generic way. i use 2 DMA transfert one the same buffer
<re_irc>
<ryan-summers> You can do it "pseudo safely" where you detect if you violated safety semantics afterwards and panic
<re_irc>
<ryan-summers> I think the H7 also does something interesting in double buffered mode where the addr pointer of the DMA is poisoned while the user is accessing the buffer
<re_irc>
<ryan-summers> So the DMA hits a hard fault exception if the buffer switches before the user is done with it
<re_irc>
<ryan-summers> There's a small amount of overhead as a result (two writes of the DMA ADDR pointer register), but you get safety guarantees from it
<re_irc>
<yruama_lairba> but in think it anyway not possible to have 2 DMA transfert working on the same buffer with a generic HAL ?
<re_irc>
<ryan-summers> That's already unsafe if both DMA channels own the buffer. That violates rust's ownership semantics
<re_irc>
<ryan-summers> Unless they're both immutable borrows
<re_irc>
<ryan-summers> But having two DMAs writing to the same memory never sounds like an intended action
<re_irc>
<yruama_lairba> lol, i fact, i did something very complex to describe from safety point of view :p
<re_irc>
<ryan-summers> I think you should take a careful look at your design. It sounds like there's a large potential for undefined behavior as a result
<re_irc>
<yruama_lairba> my 2 DMA channels work on the same buffer, but there are synchronised So they never write at the same memory
<re_irc>
<yruama_lairba> the synchronisation it done throught hardware signal
<re_irc>
<henrik_alser> yruama_lairba: why do you need it like that?
<re_irc>
<yruama_lairba> not a requirement, it's just a conveninet and optimized way to do inplace processing
<re_irc>
<yruama_lairba> infact, even "inplace" is not a requirement, i just realize i could do in this way to reduce amount of used memory
<re_irc>
Using the instructions in the website above I can now run probe-run and see rprintln("Hello, World") print the Hello, World message, the next thing that I would like to solve is how do I go about debugging the code with "stepi and next" gdb command?
<re_irc>
<olaoni> Code did not drop into a debug session
<re_irc>
<ryan-summers> Did you read how to use "cargo-embed"? It uses config files and profiles etc. This is all documented on the crates page for it and the repo has some example config files: https://crates.io/crates/cargo-embed
<re_irc>
<olaoni> okay thanks
<re_irc>
<ryan-summers> There's specifically an option that goes in the TOML file to enable the GDB server
<re_irc>
<ryan-summers> Once you get that going, it will spin up a gdb-server for your code after the flash step. You'll then need to run "gdb-multiarch" with the appropriate commands and connect to the server that cargo-embed spins up
<re_irc>
<olaoni> cool thanks. I always use gdb-multiarch for debugging
<re_irc>
<ryan-summers> You can add the appropriate gdb-multiarch call signature to ".cargo/config" so you automatically get the ELF path supplied to the call signature. That also lets you provide some gdb command file to pre-run to connect to the server
<re_irc>
<ryan-summers> So then the workflow becomes:
<re_irc>
cargo run // <-- Executes the gdb-multiarch command specified in .cargo/config
<re_irc>
# In separate shell
<re_irc>
cargo embed // <-- Starts the GDB server if your profile has it enabled
<re_irc>
<olaoni> ryan-summers: Thanks
<re_irc>
<ryan-summers> You can probably write some run script to call from ".cargo/config" that automatically runs "cargo-embed" as a background process before starting the gdb client. I've just never cared enough to get it all going, although I had a very similar setup years ago using MSP430 and msp-debug
Rondom has quit [*.net *.split]
cr1901 has quit [*.net *.split]
seds has quit [*.net *.split]
<re_irc>
<olaoni> ryan-summers: thanks
seds has joined #rust-embedded
Rondom has joined #rust-embedded
cr1901 has joined #rust-embedded
Abhishek_ has joined #rust-embedded
<re_irc>
<korken89> I generally write an cargo xtask command for that
<re_irc>
<korken89> A shell script would probably work just as well though in this case
<re_irc>
<ryan-summers> Yeah, it's basically a spinup (background), wait, launch client, then finally catch exit and kill the server
<re_irc>
<korken89> Yep
<re_irc>
<ryan-summers> Ooh, XTask does look really nice for this though
<re_irc>
<ryan-summers> Helps with portability
<re_irc>
<korken89> Yeah, it sort of keeps everything within one thing
<re_irc>
<korken89> I like the concept
<re_irc>
<ctron (@ctron:dentrassi.de)> does anyone know if using "picoprobe" should work with probe-rs tooling?
<re_irc>
<Noah> ctron: nope it does not work :) They use a non-standard for communication with the host I believe
<re_irc>
<romen> Hi, does anyone know if there are active projects trying to port RTIC to RISC-V? I found this issue (https://github.com/rtic-rs/rfcs/issues/47) but it hasn't seen any update in the past year
<re_irc>
<bradleyharden> 9names, yes! That's it. I think it was in a slightly different format when I read it, but it looks very familiar
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
gsalazar has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
gsalazar has quit [Ping timeout: 240 seconds]
gsalazar has joined #rust-embedded
skunkjoe has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc>
<firefrommoonlight> yruama_lairba: Make sure they don't access the buffer at the same time. How to set this up depends on details
skunkjoe has quit [Ping timeout: 250 seconds]
Guest2 has quit [Quit: Client closed]
<re_irc>
<olaoni> I am trying to build the blinky project standalone for the stm32h743 nucleo without having to add utilities folder to my project. if I remove the following lines