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 (@9names:matrix.org)> 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 (@9names:matrix.org)> oh, i thought you were trying to troubleshoot an issue you were already having with allocations.
<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 (@9names:matrix.org)> it should be kept if it is a pub fn
<re_irc>
<9names (@9names:matrix.org)> 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 (@9names:matrix.org)> 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 , 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
<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 (@joedeandev:matrix.org)> 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 (https://sensae.co/embedded-rust-developer). 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>
<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 "build.rs"?
<re_irc>
<Chris [pwnOrbitals]> doesn’t seem to solve it, hmm... yeah it’s using cc in build.rs
<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]
<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.
<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>
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> 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>
<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