ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
bpye has quit [Quit: The Lounge -]
bpye has joined #rust-embedded
bpye has quit [Quit: The Lounge -]
bpye has joined #rust-embedded
bpye2 has joined #rust-embedded
bpye has quit [Ping timeout: 260 seconds]
bpye2 is now known as bpye
bpye6 has joined #rust-embedded
bpye has quit [Ping timeout: 260 seconds]
bpye6 is now known as bpye
bjc has joined #rust-embedded
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
<re_irc> <Udayakumar Hidakal> Hello all,
<re_irc> I am working on "SAM4L8-Xplained-pro" development board,
<re_irc> I am trying to flash the code using "probe-run microchip --chip ATSAM4LC8C" command, here i am getting some errors like this
<re_irc> please help me to resolve this error.
<re_irc> <newam> Maybe try "--connect-under-reset"?
starblue has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 240 seconds]
XMPPwocky has quit [Quit: Bridge terminating on SIGTERM]
XMPPwocky has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
<re_irc> <Udayakumar Hidakal> newam: Thanks for this suggestion,
<re_irc> "Error: Failed to get information for AP ApAddress { dp: Default, ap: 0 } "
<re_irc> One more thing in probe-run supported board list we saw "ATSAM4LC8C" board, But in my development board "ATSAM4LC8CA" we saw extra "A" in the IC name,
<re_irc> I tried this command and it's also throwing some error like this
<re_irc> So is that make any deference in flashing to the board ?
<re_irc> <ia0> Anyone knows if there's a way to access the function names of the current callstack? I'd like to debug which parts of the code allocate too much
<re_irc> <9names (> You could set a data watchpoint near the high-water-mark of your stack, then get a backtrace as per normal. That won't tell you where the allocations occur but you could make some educated guesses from that.
fabic has quit [Ping timeout: 276 seconds]
lcbit has quit [Quit: leaving]
fabic has joined #rust-embedded
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
lcbit has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <ia0> Mmmm I would need to automate that then, since I want the backtrace for all allocations. I was initially thinking panicking at the i-th allocation and running the program n times with i in 0..n which is simpler to automate but a bit slow to run
<re_irc> <9names (> oh, i thought you were trying to troubleshoot an issue you were already having with allocations.
<re_irc> worked for prediction but IIRC it's not currently functional
<re_irc> <ia0> I'm already using this. This is about static stack size analysis, I need runtime stack information
<re_irc> <Chris [pwnOrbitals]> Hey everyone, in an FFI context I’m defining a function to be used in C ("extern "C" fn func([args]) { [impl] }") but this function isn’t called from the Rust side. It looks like it’s optimized away early because the linker throws an undefined symbol error... is there any way around it ? thanks
<re_irc> <Chris [pwnOrbitals]> * error (when linking rust and C artefacts)...
<re_irc> <9names (> it should be kept if it is a pub fn
<re_irc> <9names (> there is the #[used] attribute if it still gets dropped after making it pub
<re_irc> <Chris [pwnOrbitals]> it wasn’t pub but I just tried again making it pub and no change, trying the attribute
<re_irc> <Chris [pwnOrbitals]> looks like "#[used]" isn’t applicable to functions, only static variables
<re_irc> <9names (> have you tried writing it like it's laid out in the docs?
<re_irc> pub extern "C" fn foo{}
<re_irc> #[no_mangle]
<re_irc> <Chris [pwnOrbitals]> Well I had missed the no_mangle part it looks like ! thanks ;)
<re_irc> <Yashwanth SINGH M> HI
<re_irc> <Yashwanth SINGH M> Hi , i'm trying to build this code to blink led on stm32, i'm able the build & run it on windows but on mac i'm getting this error
fabic has joined #rust-embedded
<re_irc> <9names (> does it still do it on a clean build? have you tried removing cargo.lock and building?
<re_irc> <Yashwanth SINGH M> i deleted the cargo.lock still getting error
<re_irc> <Chris [pwnOrbitals]> now I’m having the same problem in reverse, when my Rust code can’t find a C function... :(
<re_irc> <robtsuk> Yashwanth SINGH M: are the versions of Rust the same on both? both set to either stable or nightly?
<re_irc> <david_horton> You'll need extern "C" { } around your Rust function definition. This will make the compiler use C ABI and avoid name mangling.
<re_irc> <david_horton> Best to use extern crate libc_interface which defines a mapping between Rust and C data types (eg. libc_interface::c_int)
<re_irc> <david_horton> You'll need extern "C" { } around your function declaration in Rust. This will make the compiler use C ABI and avoid name mangling.
<re_irc> <yruama_lairba> i just didn't a gross bechmark with rtic to look task spawning overhead. it's around 40 cpus cycle at least
<re_irc> <yruama_lairba> * did
<re_irc> <yruama_lairba> i was using task spawing inside interrupt to display message without without making this interrupt too long
<re_irc> <yruama_lairba> i think i will try other methods for that, spawning just double execution time of interrupt and i alreadu determined that can cause issue
<re_irc> <Joe (> Hello! I'm Joe, Rust enthusiast and full-stack dev based in Copenhagen. My team is hiring an embedded Rust developer - you can read more here ( We're an international team working on a wearable for mental health - it's great if you're based in Copenhagen, but we'd love to hear from anyone interested. Feel free to pass the word along!
<re_irc> <dngrs (spookyvision@github)> what's that crate called again that does sophisticated byte array view things… it went 1.0 a few months ago with a breaking api change
<re_irc> <dngrs (spookyvision@github)> ach, "bitvec"
<re_irc> <Chris [pwnOrbitals]> david_horton: yeah I’ve got that but still the linker can’t find the C function, maybe it has been optimized by cc... weird
<re_irc> <dngrs (spookyvision@github)> deactivate mangling with "#[no_mangle]"
<re_irc> <dngrs (spookyvision@github)> I don't think "extern "C"" implies it
<re_irc> <reitermarkus> Are you using the "cc" crate in ""?
<re_irc> <Chris [pwnOrbitals]> doesn’t seem to solve it, hmm... yeah it’s using cc in
<re_irc> <reitermarkus> Have you checked if the compiled library has the symbol (using your toolchain's "nm" tool)?
<re_irc> <Chris [pwnOrbitals]> tbh I’m still struggling to find where the output object file, it doesn’t seem like it’s generated&linked properly
<re_irc> <Chris [pwnOrbitals]> -where
<re_irc> <Chris [pwnOrbitals]> the symbol is not present :(
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <James Munns> Its happening!
<re_irc> <James Munns> If this PR is merged in the next 14 days, it _should_ be stable in 1.63.
<re_irc> <James Munns> (pending any problems found)
<re_irc> <dirbaio> finally!! so awesome! 🙌
<re_irc> <James Munns> Does this unlock/make progress towards "type_alias_impl_trait" or async traits?
<re_irc> <dirbaio> for async traits you need both GAT+TAIT
<re_irc> <dirbaio> stabilizing TAIT Is mostly independent to GAT
<re_irc> <dirbaio> but there's talks of stabilizing it already 👀
<re_irc> <dirbaio> +as well
<re_irc> <newam> we still get a ton of cool things with GATs though, lots of ways to make peripherals saner in HALs
<re_irc> <James Munns> 26 issues to go :p
<re_irc> <James Munns> (though not all of those are necessarily blockers, there are no unsound issues on that list)
<re_irc> <James Munns> (but the ICEs are probably blockers)
<re_irc> <dirbaio> most are just diagnostics (things that shouldn't be allowed, but the compiler explodes instead of giving a proper diagnostic)
<re_irc> <dirbaio> newam: interesting, have any examples?
<re_irc> <newam> dirbaio: impl LpTim1 {
<re_irc> &mut self,
<re_irc> pub fn new_trigger_pin<P: LpTim1Etr>(
<re_irc> filter: Filter,
<re_irc> <dirbaio> interesting! it's not needed if you don't have typestates on the pins though, afaict (?)
<re_irc> <newam> There's no typestates on those pins, I just had to separate it because of the different "LpTim1Etr", "LpTim2Etr", ect (different AF numbers).
<re_irc> <James Munns> Oh, I forgot how the train works - if it hits beta before the end of 14 days (which the stabilization PR would do), it'll be in 1.62, not 1.63. But that's not necessarily guaranteed.
<re_irc> <James Munns> So 8 weeks from now, not 14.
fabic has quit [Ping timeout: 276 seconds]
<re_irc> <reitermarkus> Thoughts on
<re_irc> <dirbaio> would be interesting to check what error messages rustc prints if you use it wrong
<re_irc> <dirbaio> these "clever" hacks usually lead to way worse error messages than the straightforward way
<re_irc> <newam> Are we doing a transition release?
<re_irc> <dirbaio> it's unsound, commented on PR
<re_irc> <jkelleyrtp> I'm getting memory corruption issues when trying to read from a serialport using zerocopy.
<re_irc> My code is super simple:
<re_irc> let mut reading = DataReading::default();
<re_irc> loop {
<re_irc> <jkelleyrtp> My data just gets randomly corrupted
<re_irc> [packages/gateway/src/providers/] reading = DataReading {
<re_irc> distance_mm: 1662,
<re_irc> timestamp: 720878767756,
<re_irc> <dirbaio> are you using RTS/CTS?
<re_irc> <dirbaio> if not, it's possible bytes are getting lost, which causes the 20 byte blocks to "shift" so the decoding will be off
<re_irc> <dirbaio> or noise can "insert" spurious bytes
<re_irc> <dirbaio> you'll need some kind of "framing" so that the receiver knows where each message starts and ends
<re_irc> <jkelleyrtp> dirbaio: Not sure?
<re_irc> My receiver side:
<re_irc> .parity(tokio_serial::Parity::None)
<re_irc> let mut port = tokio_serial::new(info.port_name.clone(), 115200)
<re_irc> <jkelleyrtp> dirbaio: I am using a 12ft usb cable, that actually might be part of it
<re_irc> <dirbaio> uart without framing is always trouble :P
<re_irc> <jkelleyrtp> dirbaio: What's the difference between software and hardware flowcontrol?
<re_irc> <jkelleyrtp> and how do I set it on the transmitter? it doesn't seem like nrf-hal has methods to set the flow control?
tafa has quit [Quit: ZNC -]
tafa has joined #rust-embedded
<re_irc> <jkelleyrtp> Does anyone know the rts/cts pins for nrf?
<re_irc> <jkelleyrtp> I can't find it online - and to setup rts with nrf_hal you need to know which pins are used
<re_irc> <dirbaio> you can use any pins
<re_irc> <yruama_lairba> hi, what technics would you use to display log information from an interrupt but without use rtprint in the interrupt (it cause timing issue)
<re_irc> <dirbaio> check out defmt, it's much faster
<re_irc> <newam> set a flag, log it later, or use smaller logging message like defmt
<re_irc> <newam> * messages
<re_irc> <yruama_lairba> i was thinking about a queue share across my task
<re_irc> <yruama_lairba> * shared
<re_irc> <dirbaio> defmt _is_ a queue internally, that the host drains through RTT
<re_irc> <dirbaio> as long as you never fill it, defmt won't block in the interrupt context
<re_irc> <yruama_lairba> im looking defmt
<re_irc> <yruama_lairba> i think i will not use it for my current stuff, i'm writing an example, and i think i will even remove logging from the example one it work
<re_irc> <yruama_lairba> * once
<re_irc> <yruama_lairba> * works
creich has joined #rust-embedded
cr1901_ has joined #rust-embedded
<re_irc> <dirbaio> so, about cortex_m::interrupt::free
cr1901 has quit [Ping timeout: 250 seconds]
<re_irc> <dirbaio> if we're going to adopt "critical_section" as _the_ official cross-arch critical section abstraction
<re_irc> <dirbaio> it'd maybe make sense to move _all_ impls out of "critical_section"?
<re_irc> <dirbaio> so the arch crates (cortex_m, riscv, etc) or HALs supply the impls
<re_irc> <newam> HALs supplying the impls may still be unsound, e.g. if using an RTOS that executes in unpriv
<re_irc> <newam> but yeah
<re_irc> <dirbaio> also that's very breaking so it'll require "critical_section 0.2" (or 1.0?)
<re_irc> <dirbaio> yeah, in all cases the user would have to explicitly opt-in
<re_irc> <dirbaio> supplying an impl by default can be unsound, and also can be annoying if the user wants to override it
<re_irc> <dirbaio> I'd say most HALs break down if you run them under an RTOS unpriv
<re_irc> <dirbaio> for example stm32 HALs insist on initializing RCC, allowing unpriv code to do that doesn't sound nice
<re_irc> <newam> Yeah, no HAL that I know of would work kindly with unpriv
<re_irc> <dirbaio> and what do we do with "bare_metal"?
<re_irc> <dirbaio> fold it into "critical_section"?
<re_irc> <yruama_lairba> i wonder the preformanc difference between a lock queue and a lock free queue ?
creich has quit [Quit: Leaving]
<cr1901_> Hrm, the i2c embedded hal trait got a hell of a lot more complicated since 0.3, didn't it?
cr1901_ is now known as cr1901
<re_irc> <dirbaio> complicated\ why?
<re_irc> <dirbaio> * complicated
<re_irc> <dirbaio> the Transactional stuff?
<cr1901> I have to implement 7 methods instead of a minimum of 2
<cr1901> Why aren't the *_iter methods provided? What's the difference between transaction and write_read?
<re_irc> <dirbaio> yeah :')
<cr1901> I just wanted to update my tcn75a crate to be more up to date
<cr1901> I don't feel like thinking today lmao
<cr1901> (Seriously... why aren't the *_iter methods provided?)
<re_irc> <dirbaio> hmm did some digging in the PRs
<re_irc> <dirbaio> for SPI the concern was it would lead to bugs with Managed CS
<re_irc> <dirbaio> so they were removed
<re_irc> <dirbaio> for i2c there was no discussion about it it seems
<cr1901> I would not have any particular insight into footguns. I'm just complaining about doing more work than I wanted to :P
<re_irc> <dirbaio> ah no
<re_irc> <dirbaio> you can't impl the _iter methods based on just "read" and "write"
<re_irc> <dirbaio> "write" does one transaction (start+stop)
<re_irc> <dirbaio> if you implemented "write_iter" with "write", it would do N tiny singly-byte transactions
<re_irc> <dirbaio> and it must do 1 big transaction
<cr1901> Okay, that's fair. So the old Write trait is now write_iter
<cr1901> ?
<re_irc> <dirbaio> no, still "write()"
<re_irc> <dirbaio> anyway
<re_irc> <dirbaio> I'd like to split the i2c trait into Bus/Device, like SPI
<re_irc> <dirbaio> that way you'll be able to do one transaction with multiple read/writes in it
<cr1901> hmmm
<re_irc> <dirbaio> the I2cBus trait would be just "read()" and "write()", it wouldn't even need "write_read()"
<cr1901> (This is by no means aimed at embedded Rust in particular, but why is it that every time I think something will take "n" units of time it's going to take an order of magnitude longer?)
<re_irc> <dirbaio> 🤣
<cr1901> I think tcn75a crate only requires the old Write + Read traits
<cr1901> meaning I can make a minimal working example by "unimplemented!()" for the other methods
<cr1901> >This allows your code to type-check, which is useful if you are prototyping or implementing a trait that requires multiple methods which you don’t plan to use all of.
<cr1901> Oooh, it's in the docs
<cr1901> that makes it okay
<cr1901> Just to confirm, the timer/watchdog traits are also gone?
<re_irc> <dirbaio> yep
<re_irc> <yruama_lairba> isthere an exampl of how using spsc with rtic ?
<re_irc> <yruama_lairba> *heapless spsc
<cr1901> that's fine, that's a copy-paste change
<re_irc> <yruama_lairba> seems there is no way to use heapless spsc without using usafe
<re_irc> <jamesmunns> yruama_lairba: define the spsc in the "local" section of the "init" function, split it in init, give the Producer and Consumer halves to different tasks as "local" items
<re_irc> <jamesmunns> no unsafe is required.
<re_irc> <yruama_lairba> jamesmuuns, Producer and Consumer need a lifetime, i don't know what to give except static
<re_irc> <jamesmunns> it's static
<re_irc> <jamesmunns> except instead of:
<re_irc> [a: u32 = 0]
<re_irc> <jamesmunns> you'll have:
<re_irc> [queue: Queue<u32, 32> = Queue::new()]
<re_irc> <jamesmunns> then in init, you can do:
<re_irc> let queue: &'static mut Queue = cx.local.queue;
<re_irc> let (producer, consumer): (Producer<'static, u32, 32>, Consumer<'static, u32, 32>) = queue.split();
<re_irc> <jamesmunns> (you probably don't need the type annotations on the second line, but you'll need them in the resources struct)
<re_irc> <yruama_lairba> thank, i missed the usage of local in init
<re_irc> <jamesmunns> then in init, you can do:
<re_irc> let queue: &'static mut Queue<u32, 32> = cx.local.queue;
<re_irc> let (producer, consumer): (Producer<'static, u32, 32>, Consumer<'static, u32, 32>) = queue.split();
<re_irc> <jamesmunns> there's also the "singleton!()" macro in cortex-m, if you're not using rtic
<re_irc> <jamesmunns> (but if you are, "local" is better)
<re_irc> <jamesmunns> (it works the same way, but you have to "unwrap()" it to make sure you only ever take it once - which you don't need in rtic, because it knows it only calls init once)
<re_irc> <yruama_lairba> rtic is so convenient
<cr1901> you're returning... nothing and yet it typechecks?
<re_irc> <jamesmunns> yeah
<re_irc> <jamesmunns> Infallible is an empty enum
<re_irc> <jamesmunns> so it is impossible to ever create one
<re_irc> <jamesmunns> it's an "unpossible type"
<re_irc> <jamesmunns> (that's not a real term)
<cr1901> So it's unreachable code and thus "any return type is allowed"
<cr1901> (Also: "Me fail English? That's unpossible")
<re_irc> <jamesmunns> sooooort of
<re_irc> <jamesmunns> because no variant is possible, it knows NO value is returned
<re_irc> <jamesmunns> this is a rough approximation of the never type ("!"), basically.
<re_irc> <jamesmunns> is actually a good explanation
<re_irc> <jamesmunns> but "Infallible" is literally:
<re_irc> pub enum Infallible { }
<re_irc> <jamesmunns> and you can't make one, like an empty struct, because all enums must be created with a variant (it is not itself enough)
<re_irc> <jamesmunns> like
<re_irc> let x = Infallible;
<re_irc> doesn't compile
<re_irc> <jamesmunns> but yes, that code is unreachable, because it can only be called with a reference to an instance of "Infallible", which can never happen
<cr1901> >because no variant is possible, it knows NO value is returned <-- I don't see how this is different from what I said ("any return type is allowed b/c the code is unreachab;e") :P
<re_irc> <jamesmunns> net effect, yes
<re_irc> <jamesmunns> actually, yes, I can't even rememeber what I was splitting hairs about after reading the docs
<re_irc> <jamesmunns> don't listen to me :p
<cr1901> I'll play w/ it later
<cr1901> I wanted to whip up a demo w/ postcard but now I'm stuck updating my HAL.
<cr1901> Not what I wanted
<re_irc> <jamesmunns> :(
<cr1901> Fortunately, the unimplemented!() macro exists, so I can just half ass the changes :3
<re_irc> <yruama_lairba> i don't understand, i have an interrput blocking everything else
<re_irc> <yruama_lairba> i have permanently an i2s underrun
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 256 seconds]
<re_irc> <yruama_lairba> i have a strangeissue, some hardware flags are not retrived correctly
<cr1901_> dirbaio: I didn't think of this until now, but... how was the Periodic trait impl'd w/o interrupts before it was removed?
<cr1901_> Wouldn't an interrupt be required because polling may reread "the timer is 0" many times before the timer ticks and can't tell the difference between the first and subsequent reads