ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <willeml> "[00, 00, 03, 20, e1, 01, 00, 90]"
<re_irc> <willeml> which matches the .bin file
<re_irc> <adamgreig> what happens if you change L12 so the pointer is "*const u32" instead of "*const u8"?
<re_irc> <willeml> "[20030000, 900001e1, 900014e1, 900050cd, 900014e1, 900014e1, 900014e1, 00000000]"
<re_irc> <adamgreig> huh.....
<re_irc> <adamgreig> seems weird that that gets the right values but a few lines later reading the same memory address returns all 0x88888888
<re_irc> <willeml> Oh that's interesting, now that I am using const u32 it freezes, then crashes before it can print the next code parts and gives an an error saying reset and device halted by user
<re_irc> <willeml> And running it again, it's just hanging
<re_irc> <adamgreig> is it possible the qspi is being accessed too fast?
<re_irc> <willeml> It could be, I don't have clocks configured
<re_irc> <willeml> Same result with clocks configured, so either it's not that or I did the clocks wrong...
<re_irc> <GrantM11235> willeml: Is there UB here? You are derefing raw pointers while the slice is still alive
<re_irc> <adamgreig> I guess you could "ptr::read_volatile(0x9000_0000 as *const u32)" if you wanted to be sure but the slice can be dead by then
<re_irc> <willeml> Instead of "core::slice::from_raw_parts"?
<re_irc> <adamgreig> instead of the derefs on 27/28
<re_irc> <adamgreig> but I would try and get that single stepping going and see if it gives you any better clues
<re_irc> <adamgreig> if nothing else you should be able to see the exact instruction and register state that causes it to fault
<re_irc> <GrantM11235> It should be enough to just drop the slice after you print it
<re_irc> <willeml> Even with a drop, it freezes
<re_irc> <willeml> Ill try to figure out getting gdb running
<re_irc> <adamgreig> should just need "[default.gdb] enabled=true" in "Embed.toml"
<re_irc> <adamgreig> then run "arm-none-eabi-gdb" and "target remote localhost:1337"
<re_irc> <willeml> Can I leave rtt on?
<re_irc> <adamgreig> one way to find out :P
<re_irc> <willeml> Haha, looks like yes
fabic has joined #rust-embedded
<re_irc> <willeml> Got gdb running, and figured out how to get it to read the elf file so I can see code too
<re_irc> <willeml> Seems to get stuck at "while sbss < ebss" (before main is run)
<re_irc> <willeml> Oh, it just takes a REALLY long time time to initialize ram...
<re_irc> <adamgreig> you can set a breakpoint at the call to bootload
<re_irc> <adamgreig> unless it's initialising ram inside your code in flash, in which case it's booted OK at least
<re_irc> <adamgreig> ("break main.rs:32" or similar)
<re_irc> <willeml> Oh thanks, that worked
<re_irc> <willeml> Is there a way to re run the program from cargo embed without having to quit and re-run?
<re_irc> <adamgreig> you can disable flashing, or from gdb you can "run" to restart from 0
<re_irc> <adamgreig> I mean, you can tell cargo-embed to not flash for a given profile, like "[default.flashing] enabled=false"
<re_irc> <adamgreig> or just "run" in gdb should restart from the beginning
<re_irc> <willeml> My problem is that everytime I exit cargo embed I have to re connect gdb
<re_irc> <willeml> so hopefully run will work
<re_irc> <willeml> Doesn't work for remote targets
<re_irc> <willeml> "monitor reset" is the answer
<re_irc> <adamgreig> 👍️, I think "target extended-remote localhost:1337" but not sure if probe-rs supports "run" in that case
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc> <willeml> Getting an error saying that cortex-m 0.7.4 cannot satisfy all of my dependencies, even though the only other mentioned thing to depend on it is stm32f7xx-hal which also requires 0.7.4...
<re_irc> <willeml> (I am doing this using git dependencies)
<re_irc> <willeml> Still working on the bootloader thing, just got distracted by updates to libraries and changes to the asm stuff in cortex-m
<re_irc> <adamgreig> Are you putting cortex-m as a git dep in your cargo.toml? You should use cargo's patching instead or you'll end up with two versions of cortex-m, one from your git dep and another from the released version used by the hal
<re_irc> <adamgreig> Probably best to just use 0.7.4 in both places if you can
<re_irc> <willeml> Oh, that explains it
<re_irc> <willeml> I would put 0.7.4 but it is not published to crates.io yet
<re_irc> <willeml> I think
<re_irc> <adamgreig> 0.7.4 is on crates.io I thought?
<re_irc> <willeml> Actually it is, cargo update is not grabbing it though...
<re_irc> <willeml> Oh, 0.7.4 in the repo has changes I want that are not in the release, namely the asm stuff is all in the code, instead of macroed out
<re_irc> <adamgreig> If you put [patch.crates-io] cortex-m = { git = "..." } In your cargo.toml it will set all packages to use the git version including the HAL, which should also work
<re_irc> <willeml> Ahh, thank you
<re_irc> <adamgreig> Bedtime here, good luck!
<re_irc> <willeml> Thanks! gn
stephe has quit [*.net *.split]
agg has quit [*.net *.split]
stephe has joined #rust-embedded
agg has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
darknighte has quit [*.net *.split]
darknighte has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
gsalazar has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
<re_irc> <MathiasKoch> Does anyone have knowledge of a no_std MPSC queue?
<re_irc> <ryan-summers> Heapless has one
<re_irc> <ryan-summers> It's an MPMC, but you can just create a single consumer and it becomes an MPSC
<re_irc> <MathiasKoch> Cool.. So rather than splitting to producers/consumers, you are just supposed to pass &mpmc::Queue to all?
<re_irc> <ryan-summers> I believe so. None of the operations require mutable access to the queue because they're atomic
<re_irc> <ryan-summers> I think my general use case is to store the mpmc::Queue in static memory and hand out refs to it
<re_irc> <ryan-summers> I've used it for a few apps successfully though
<re_irc> <MathiasKoch> Sounds good 👍️
<re_irc> <MathiasKoch> thanks
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <yruama_lairba> Hi, can the compiler optimize 2 successive write to a peripheral register ?
<re_irc> <ryan-summers> I highly doubt it, but when in doubt, look at the asm dump
<re_irc> <yruama_lairba> ryan-summers: don't know to do that and find pice of coe of my interest
<re_irc> <ryan-summers> Also, it depends on how you're accessing said regs. If you're using an svd2rust-generated PAC, it shouldn't optimize since it uses volatile operations
<re_irc> <yruama_lairba> pac, but old version
<re_irc> <ryan-summers> I very highly doubt it matters how old the version is, I don't believe semantics have really ever changed since PACs started to be generated
<re_irc> <ryan-summers> Since that's a fundamental behavior of accessing peripheral regs
<re_irc> <ryan-summers> But like I said, the only definitive way to guarantee that it isn't happening is to do a disassembly and find your point of interest
<re_irc> <ryan-summers> Google will be your friend on that - I always forget the commands/args
<re_irc> <yruama_lairba> ok, checked my code, i actually do a read modify, so this can be my issue
<re_irc> <yruama_lairba> i have trouble with stm32 32bits I2s communication in master receive mode
<re_irc> <yruama_lairba> under some situation, the rxne flag is not set for the first 16 bit data chunk
<re_irc> <yruama_lairba> i'm mean the first data chunk after having disabled/enabled the device to restart the communication
<re_irc> <ryan-summers> Try asking #stm32-rs:matrix.org (https://matrix.to/#/#stm32-rs:matrix.org) - I've never used I2S
<re_irc> <yruama_lairba> ryan-summers: unfortunatly, part of my trouble comes from the fact i'm trying to also support "PCM" variant with the same code. don't think much people did that
explore has joined #rust-embedded
<re_irc> <ejpcmac> Hello, to attend the CTCFT, do we really need a Google account?
<re_irc> <ejpcmac> Also, I've never used Zoom, do I need to create an account / install some software, or is it accessible via web as a guest?
<re_irc> <ejpcmac> Are crates generated by "svd2rust" compatible with "cortex-m-rt 0.7.x"? In the documentation, it is suggested to create a "Cargo.toml" with version 0.6.13. Is it up to date?
<re_irc> <firefrommoonlight> I am using the latest released version of those crates with cortex-m 0.7.3
iyed has joined #rust-embedded
iyed is now known as iyedonhismed
<re_irc> <yruama_lairba> Terrible, i assumed a peripheral behaviour that is actually not true
<re_irc> <yruama_lairba> i assumed stm32 i2s peripheral in master receive mode was resetting clock phase when disabled/enabled
<re_irc> <yruama_lairba> the actual clock phase after disable/enable is actually totally unrieliable :(
<iyedonhismed> lol
<re_irc> <yruama_lairba> this crap prevent me to do a code that work for all protocol supported by SPI/I2s peripheral
<re_irc> <dirbaio> maybe you need to reset it in RCC?
dreamcat4 has joined #rust-embedded
<re_irc> <adamgreig> Just a reminder that the CTCFT meeting about Embedded is starting now :)
<re_irc> <yruama_lairba> dirbaio: (almost) not possible. i'm rewritting a crate to implement I2s hal for all STM32 using particular version of I2S/SPI peripheral
<re_irc> I think that link should work for everyone.
<re_irc> <yruama_lairba> because of that, i don't have direct access to the MCU Rcc register
<re_irc> <dirbaio> yeah... not much you can do then
<re_irc> <dirbaio> you'll have to politely ask the user to do the reset themsleves
<re_irc> <dirbaio> * themselves
<re_irc> <henrikssn> maybe could be solved with some unsafe code? &(*pac::RCC) or similar?
aspe has joined #rust-embedded
aspe has quit [Remote host closed the connection]
aspe has joined #rust-embedded
<re_irc> <yruama_lairba> dirbaio: the crate use a trait to require needed stuff from a MCU-hal. I could add a method to require reset from RCC
aspe has quit [Client Quit]
<re_irc> <yruama_lairba> henrikssn, the crate is totally MCU independent, i don't have access to MCU pac
<re_irc> <ryan-summers> Defining your own trait, or using one otherwise, that the user would pass you resetability is your best bet here imo
<re_irc> <ryan-summers> If there's no reset required, then they can easily impl that trait as a no-op
<re_irc> <yruama_lairba> ryan-summers: except that is not a task deferred to user, but to MCU-hal implementers
<re_irc> <ryan-summers> But users can still easily implement it
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
<re_irc> <yruama_lairba> ryan-summers: but this probably require using an unsafe part of the pac
cr1901 has joined #rust-embedded
<re_irc> <yruama_lairba> ouch, I realized RCC reset strategy have a big issue. this require to keep a copy of my peripheral setup since it reset everything
<re_irc> <yruama_lairba> this is probably easier to write 2 version of the same methods to handle standard specificity
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
iyedonhismed has quit [Quit: WeeChat 3.5]
cr1901 has quit [Client Quit]
explore has quit [Quit: Connection closed for inactivity]
fabic has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <riskable> How do I get "defmt::println!()" to work when running "cargo test"?
<re_irc> <riskable> I'm running "cargo test" locally and just don't want to have to comment out all my "defmt" calls when running tests
<re_irc> <riskable> (it'd also be nice to see their output in the terminal when debuggin)
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
aspe has joined #rust-embedded
dreamcat4 has quit [Quit: Connection closed for inactivity]
iyed has joined #rust-embedded
iyed is now known as iyedonhismed
<re_irc> <yruama_lairba> @riskable maybe using "#[cfg(not(test))]" or " if !cfg!(test) {}" ?
<re_irc> <riskable> yruama_lairba: Can you give me that in some real code so I'd know where to put it? I assume right above every single "defmt::println!()" line?
<re_irc> <riskable> (which are sprinkled everywhere)
<re_irc> <James Munns> You can also look at what smoltcp does
<re_irc> <James Munns> It has flags for switching between log and defmt
<re_irc> <James Munns> Its a bit trickier, because the formatting syntax is different
<re_irc> <James Munns> But if you just wanted to flag off the defmt calls it should be straightforward
<re_irc> <James Munns> I wonder if adding 'DEFMT_LOG=DONT' that removes everything would be worth it
iyedonhismed has quit [Quit: WeeChat 3.5]
iyed has joined #rust-embedded
<re_irc> <dirbaio> this one is nicer than what smoltcp has https://github.com/embassy-rs/embassy/blob/master/embassy-boot/stm32/src/fmt.rs
<re_irc> <dirbaio> it covers all log/assert/panic/todo/unreachable
iyed has quit [Client Quit]
iyedonhismed has joined #rust-embedded
<re_irc> <riskable> dirbaio: Ooh that's nice 👍
cr1901 has joined #rust-embedded
<re_irc> <dirbaio> another nice thing is it overrides the default macros, so if you do "panic!()" it's defmt's panic (if you're using defmt), without having to "use defmt::panic"
<re_irc> <dirbaio> so you can't "forget" to defmtize all panics
<re_irc> <dirbaio> * some panic somewhere
bjc has quit [Remote host closed the connection]
<re_irc> <dirbaio> the downside is it only works in-crate, so you have to copypaste it into every crate 🤷
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
bjc has joined #rust-embedded
iyedonhismed has quit [Quit: WeeChat 3.5]
dreamcat4 has joined #rust-embedded
dc740 has joined #rust-embedded
iyedonhismed has joined #rust-embedded
iyedonhismed has quit [Client Quit]
aspe has quit [Remote host closed the connection]
<re_irc> <adamgreig> great talks today btw dirbaio and James Munns! I watched at work, my colleagues are very excited to try async now
<re_irc> <James Munns> :D
<re_irc> <James Munns> Howd the after chat go dirbaio?
<re_irc> <firefrommoonlight> Link?
<re_irc> <mabez> firefrommoonlight: The recording will be posted here soon: https://rust-lang.github.io/ctcft/meetings/2022-05-16.html
<re_irc> <mabez> Patiently waiting for it too, I signed up for the calendar event and I didn't get a notification 😠, caught dirbaio's talk but missed James Munns
<re_irc> <James Munns> Mine was whirlwind fast :D
<re_irc> <James Munns> the TL;DR is "the tooling's great, come on in!"
<re_irc> <firefrommoonlight> IMO the tooling is a big part of the appeal of Rust on embedded, or in general
<re_irc> <firefrommoonlight> C is makefile / compiler / system dep hell in comparison
<re_irc> <firefrommoonlight> Knurling's stuff in particular is great
<re_irc> <firefrommoonlight> - the stock Rust stuff like clippy, cargo, rustup etc
<re_irc> <firefrommoonlight> That's a "+" lol
<re_irc> <firefrommoonlight> TIL...
dc740 has quit [Remote host closed the connection]
cr1901 has quit [Ping timeout: 248 seconds]
<re_irc> <yruama_lairba> hi, how i can get panic info when using defmt ?
<re_irc> <firefrommoonlight> Should do it by default when configured per teh Knurling App Template
<re_irc> <James Munns> (and using panic-probe)
<re_irc> <yruama_lairba> i didn't used the template this the project already existed
<re_irc> <Caleb Webber> Hey James Munns good talk today!
<re_irc> <dirbaio> yruama_lairba: enable cargo feature "print-defmt" in crate "panic-probe"
<re_irc> <dirbaio> James Munns: it was fun, lots of interesting questions from people
<re_irc> <dirbaio> mixing people randomly in the sub-rooms was weird 🤣
<re_irc> <Phil Markgraf> Want to write Embedded Software in Rust creating a game-changing medical system using modern development practices and evolving a highly collaborative team environment? At Bionaut Labs, we are developing miniature remote-controlled robots that can navigate through tissue and target key anatomic locations in the body, for therapeutic or diagnostic purposes.
<re_irc> DM me if you are interested. I am both hiring manager and Embedded Rust enthusiast. (Remote or Los Angeles, US resident only.)
<re_irc> <yruama_lairba> dirbaio: seems it doesn't provide a panic handler ???
<re_irc> <dirbaio> what do you mean?
<re_irc> <dirbaio> "panic-probe" does provide the panic handler
<re_irc> <dirbaio> "print-defmt" makes the provided panic handler print the panic message using defmt
<re_irc> <dirbaio> you want to do it with your own panic handler?
<re_irc> <yruama_lairba> i got this error :"error: "#[panic_handler]" function required, but not found"
<re_irc> <dirbaio> ahh
<re_irc> <dirbaio> try "use panic-probe as _"
<re_irc> <dirbaio> * panic_probe as _;"
<re_irc> <dirbaio> crates that are never "use"d don't get linked
<re_irc> <firefrommoonlight> Included this:
<re_irc> // same panicking *behavior* as `panic-probe` but doesn't print a panic message
<re_irc> // this prevents the panic message being printed *twice* when `defmt::panic` is invoked
<re_irc> #[defmt::panic_handler]
<re_irc> <firefrommoonlight> *Probalby don't need the "exit" part.
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc> <yruama_lairba> f*** there is no defmt::print!()
<re_irc> <Caleb Webber> setting up a memory.x file for the nRF52 series. Does RAM mean Code RAM (SRAM)?
<re_irc> <dirbaio> yes
<re_irc> <dirbaio> err no
<re_irc> <Caleb Webber> yeah sorry i worded that wrong
<re_irc> <Caleb Webber> sec
<re_irc> <dirbaio> the same RAM is mapped twice, in ICODE bus at 0x0800_0000, and in DCODE bus at 0x2000_0000
<re_irc> <Caleb Webber> ah okay so i need to use the ICODE address in this case?
<re_irc> <dirbaio> so normally you put your code in FLASH, at 0x0000_0000, and your data in DCODE RAM, at 0x2000_0000
<re_irc> <yruama_lairba> how i can have hexadeciaml format on slice of integer with defmt ?
<re_irc> <dirbaio> you only use the ICODE mirror at 0x0800_0000 if you want to run code from RAM, which is a strange thing to do
<re_irc> <dirbaio> * not a common
<re_irc> <dirbaio> yruama_lairba: "info!("{:x}", my_slice)"
<re_irc> <yruama_lairba> dirbaio: i was reading that https://defmt.ferrous-systems.com/format-slices.html
<re_irc> <dirbaio> you can do "{=[u32]:x}" as well. Specifying the type makes it slightly more efficient
<re_irc> <dirbaio> * like that makes it slightly more efficient, but it's not required
<re_irc> <yruama_lairba> oh, i thought it was "{=[u32:x]}"
<re_irc> <dirbaio> syntax is always "{=type:format}"