ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <xgroleau> So you are not totally wrong that I am writing a lib without requirements lol
fuwn has joined #rust-embedded
<re_irc> <firefrommoonlight> Sweet. Sounds like a good way to learn!
fuwn has quit [Client Quit]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <mmh> dirbaio: Great! I think this is what I want, and I think the pac chiptool fork of the svd2rust
<re_irc> <mmh> dirbaio: Great! I think this is what I want, and I think the pac crates generated by chiptool (which is the fork of the svd2rust) can also be used in non-async environment, isn't it? I will dig into the embassy, an awsome project!
<re_irc> <dirbaio> yeah, stm32-metapac and embassy-stm32 work for both async and blocking
<re_irc> <dirbaio> blocking works on stable
<re_irc> <dirbaio> (async works on stable too, but with some big caveats)
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
Socke has quit [Ping timeout: 268 seconds]
Socke has joined #rust-embedded
tokomak has joined #rust-embedded
<re_irc> <jkelleyrtp> Which marshalling library should I be using for sending messages across uart? Bincode? ssmarshal? zerocopy? I've run into an issue where zerocopy doesn't support enums but can't quite figure out if bincode is suitable (and ssmarshal hasn't been updated in 5 years)
<re_irc> <lulf> jkelleyrtp: check out
<re_irc> <jkelleyrtp> I have that in my dep list but didn't realize what it did - thanks!
<re_irc> <jkelleyrtp> lulf: Is there a good way of using io::read directly into the memory where postcard would convert from bytes into a type? With zerocopy I've been calling "as_bytes" and then passing that byte slice to the reader
<re_irc> <jkelleyrtp> Don't see an equivalent method in postcard. But I guess I can make a byte array with sizeof the enum
<re_irc> <lulf> sure, it does that
<re_irc> <lulf> from_bytes and to_slice
<re_irc> <jkelleyrtp> Ah okay - I've been using "read_exact" to block until I get a full struct filled in the buffer. Looks like I can do a similar dance but I have to provide the size explicitly with from_bytes or fill a pre-defined buffer with to_slice
<re_irc> <lulf> I use a fixed size frame width to avoid encoding the frame length, but you could define your protocol to start with the frame length I guess
<re_irc> <lulf> -I guess
<re_irc> <lulf> +in the first byte(s)
<re_irc> <jkelleyrtp> lulf: The API for postcard is a lot rougher than zerocopy - too bad zerocopy doesn't support algebraic enums
fabic has quit [Ping timeout: 260 seconds]
Rondom has quit [Quit: No Ping reply in 180 seconds.]
Rondom has joined #rust-embedded
<re_irc> <jkelleyrtp> Is there a way to get good stack traces with panic probe? I get the "Error: panicked" message but no indication where the error is coming from
mattgirv has quit [Ping timeout: 256 seconds]
mattgirv_ has joined #rust-embedded
<re_irc> <wucke13> How can I avoid the "duplicate lang item ... panic_impl" error for the doc tests of a no_std lib, that (normally) should define a panic handler?
<re_irc> <wucke13> Or rather: is there a "cfg!" macro that allows to detect whether a std lib is linked in?
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc> <Kaspar> hey, how do I access IPSR on cortex-m? or, figure out if code is currently executing inside an exception? (In C I was using "__get_IPSR() & 0xFF")
<re_irc> <Kaspar> I don't find IPSR in the cortex-m code...
<re_irc> <James Munns> Kaspar: I think you might want the vecactive field
<re_irc> <James Munns> Beat me to it :)
<re_irc> <Kaspar> Thanks to both! ;)
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <korken89> Are there any good impls to look at for the async SPI traits in "embedded-hal-async"? I'm looking to give RTIC's async support a try with the traits, but finding impls was harder than I thought.
<re_irc> <dirbaio> +for all stm32 chips:
<re_irc> <korken89> Nice thanks!
<re_irc> <korken89> Looking at the traits, is there something that stops "cloning" the SPI driver? I'm looking to just queue transactions to an underlying driver so any number of users can share an SPI
<re_irc> <korken89> Seems like it should be fine, but the docs do not quite seem to agree
<re_irc> <korken89> Hmm, the trait seems to allow it though
<re_irc> <korken89> Yeah, should be fine
<re_irc> <dirbaio> for sharing an SPI bus with multiple chips on it with different CS pins?
<re_irc> <korken89> Yes
<re_irc> <halfbit> imxrt-rs has some async crates as well
<re_irc> <dirbaio> you probably want to use the new SPI Bus/Device traits
<re_irc> <korken89> I'm thinking a queue of (Waker, TransactionSpec, CsPin)
<re_irc> <korken89> * "(Waker, TransactionSpec, CsPin)"
<re_irc> <korken89> Oh there are new traits?
<re_irc> <dirbaio> designed to solve SPI sharing, yup :)
<re_irc> <dirbaio> embedded-hal has a dummy SpiDevice impl that doesn't allow sharing
<re_irc> <dirbaio> if you want to share, you have to make your own SpiDevice impl with whatever mutexing you want
<re_irc> <dirbaio> I have one here using RefCell, not async though
<re_irc> <korken89> Ah
<re_irc> <korken89> Does not seem to be async though
<re_irc> <dirbaio> embedded-hal-async has the corresponding async versions of SpiDevice/SpiBus
<re_irc> <dirbaio> you could impl async SpiDevice using the (recently-merged!) async Mutex:
<re_irc> <dirbaio> so one task can lock it, then do async operations on the bus
<re_irc> <dirbaio> and if another task tries to lock it, it'll yield until the first task is done with it
<re_irc> <korken89> Hm, I'll give that a look as well
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
tokomak has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
diagprov has quit [Quit: diagprov]
diagprov has joined #rust-embedded
gsalazar has quit [Ping timeout: 272 seconds]
fabic has quit [Ping timeout: 248 seconds]
<re_irc> <riskable> I have a problem: I want to display a u8 value on my ePaper display but the function I'm using to display text only takes &str. How do I convert it in no_std?
<re_irc> <therealprof> Do you want to format the number as a string or is this an ASCII character?
<re_irc> <Jeffery Utter> I'm trying to setup a SD Card reader on my esp32 board. I think I've nearly got the code working, but I'm having trouble figuring out how to adapt the following line to rust . I have a spi initialized with "esp_id_hal::spi" but I think I need that device out of there and I...
<re_irc> ... can't seem to access it.
<re_irc> Is this a reasonable place to seek help on this?
<re_irc> Also let me know if I can clear up my question, I'm not sure if I even 100% understand what I'm asking.
<re_irc> <mutantbob> I am trying to figure out how to run tests against Rust's std library, and the best link google is offering me is an unanswered question from 2015:
<re_irc> <emilgardis> mutantbob: check
<re_irc> <mutantbob> That is promising.
diagprov has quit [Quit: diagprov]
<re_irc> <emilgardis> basically, clone rust-lang/rust, run "./ setup". modify "config.toml" to be have "profile = "library"", then "./ test library/std", also check
<re_irc> <emilgardis> how this is related to wg-embedded I don't know :D The rustc folks are mostly on Zulip, see
<re_irc> <emilgardis> actually, is probably better for std stuff
<re_irc> <jessebraham> Jeffery Utter: I'm not entirely sure what it is you're asking (sorry about that) but we do have a channel for all the "esp-rs" projects where I'm sure you can get some help!
<re_irc> <Jeffery Utter> jessebraham: Thanks! I'll check there
<re_irc> <firefrommoonlight> Where would you start troubleshooting an MCU that crashes shortly after startup, without any . STM32G431. I think "memory.x", the target, and "probe-run" runner are correct. STM32CubeProgrammer can open / view / erase it
<re_irc> <firefrommoonlight> Using STlink-V2, official
<re_irc> <firefrommoonlight> Where would you start troubleshooting an MCU that crashes shortly after startup, without being able to print anything using "defmt". STM32G431. I think "memory.x", the target, and "probe-run" runner are correct. STM32CubeProgrammer can open / view / erase it
<re_irc> <firefrommoonlight> (new design, on an MCU I haven't worked with before)
<re_irc> fn init(cx: init::Context) -> (Shared, Local, init::Monotonics) {
<re_irc> <firefrommoonlight> #[init]
<re_irc> loop {}
<re_irc> println!("A");
<re_irc> <firefrommoonlight> * target\thumbv7em-none-eabihf\release\quadcopter_firmware`
<re_irc> <firefrommoonlight> * defmt::println!("A");
<re_irc> <firefrommoonlight> *Looks like an attempt to write an arbitrary bit (Eg GPIOA en) is failing, eg if I try to set in Rust, then view in CubeProgrammer
<re_irc> <firefrommoonlight> +RCC
<re_irc> <firefrommoonlight> Oh hmm.... I just tried using my quickstart template and it works
<re_irc> <firefrommoonlight> So... Something with RTIC maybe?
<re_irc> <firefrommoonlight> This certainly eliminates config / MCU / board design
<re_irc> <firefrommoonlight> -certainly
tokomak has joined #rust-embedded
<re_irc> <firefrommoonlight> (I jump to RTIC since the quickstart I'm using is normal cortex-m, and I don't know what else would cause a fail with no code executing; so I'm assuming RTIC is doing something in the background that's triggering the fail, maybe to do with NVIC?
<re_irc> <firefrommoonlight> * NVIC?)
<re_irc> <firefrommoonlight> * minimal program
<re_irc> <firefrommoonlight> This eliminates config / MCU / board design / PAC / "cortex-m-rt"
<re_irc> <firefrommoonlight> This eliminates config / MCU / board design / "cortex-m-rt"
<re_irc> <firefrommoonlight> Commented out all RTIC tasks and still fail
<re_irc> <firefrommoonlight> This eliminates config / MCU / board design / "cortex-m-rt" / "probe-run"
<re_irc> <firefrommoonlight> OK, narrowed down. This RTIC idle task is doing it:
<re_irc> #[idle(shared = [], local = [])]
<re_irc> fn idle(cx: idle::Context) -> ! {
<re_irc> loop {
<re_irc> <firefrommoonlight> Code runs if I comment it out
<re_irc> <firefrommoonlight> WEIRDDDDD
<re_irc> <firefrommoonlight> Not sure I chose the correct LED diode, but the 3v3 line definitely works
<re_irc> <GrantM11235> riskable: You can use the "write!" macro to write to a "heapless::String" with the same syntax as "println!"
<re_irc> <riskable> GrantM11235: Cool! I'm going to try that!
<re_irc> <GrantM11235> That is the easiest solution, but it might increase your binary size too much
<re_irc> <GrantM11235> You can also try the ufmt crate, which should be much smaller (be sure to enable the ufmt feature in heapless)
<re_irc> <riskable> GrantM11235: Oh I don't care about binary size. I've got 16MB of flash! Bring on the boat! Haha
<re_irc> <riskable> therealprof: I was just trying to display an IR remote cmd number on the ePaper display so end users can program their own remote without having to run the firmware in debug mode with a probe or a USB serial port or whatever