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> <yruama_lairba> does somebody alread y had this error "note: rust-lld: error: memory.x:6: region 'FLASH' already defined"
<re_irc> <yruama_lairba> it seems i get this because i'm using a workspace
<cr1901> adamgreig: Do you know whether anyone has done work for linux-embedded-hal for the alpha.8?
<cr1901> Ditto w/ the mock objects
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
causal has quit [Quit: WeeChat 3.5]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
gsalazar has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #rust-embedded
explore has joined #rust-embedded
<re_irc> <adamgreig> cr1901: have you seen https://github.com/rust-embedded/linux-embedded-hal/pull/83?
<cr1901> adamgreig: No, because why would I have done my research before asking :)?
<cr1901> (thank you)
<cr1901> Now, I need embedded-hal-mock update, maybe I'll end up doing that myself
<re_irc> <adamgreig> I was about to tell you "no, I don't think so, just alpha.7, I did some .8 SPI stuff myself" then thought I'd double check first :p
<cr1901> My original idea was that I wanted my driver to target 6, 7, and 8 all at once via a private trait, but cargo treats alpha.X as semver compatiblre
<cr1901> (which IMO it shouldn't but I think that ship has sailed)
<re_irc> <adamgreig> i don't think there's much point targetting alpha.6/.7 any more, is there? they should be dead
<re_irc> <adamgreig> hopefully we can do a real 1.0 release one day soon
<cr1901> Well, embedded-hal-mock is at .6, and it seems like less work to target .6 and .8 than it is to port embedded-hal-mock to .8 :P
<re_irc> <adamgreig> ah, fair
Amadiro_ has joined #rust-embedded
Amadiro has quit [Ping timeout: 240 seconds]
aspe has joined #rust-embedded
<re_irc> <henrikssn> Does RTT polling halt the CPU while it is reading the output from RAM?
<re_irc> <henrikssn> I'm trying to debug a realtime app which crashes when I enable RTT logging
<re_irc> <henrikssn> I already made sure that RTT is nonblocking and the app works fine without a debug probe connected
<re_irc> <henrikssn> I'm trying to debug a realtime app which crashes when I try to read RTT logs
<Lumpio-> The one in probe-rs-rtt does not fully halt the CPU but I'd imagine it does cause some bus access which can slow things down slightly
<Lumpio-> It's very rarely a problem though
<re_irc> <henrikssn> I'm seeing jitter on the order of a few hundred cpu cycles of high priority timer interrupts
<Lumpio-> What chip is it?
<re_irc> <henrikssn> stm32f411
<re_irc> <henrikssn> 100MHz, 4 wait states
<Lumpio-> A few hundred cycles sounds pretty steep
<Lumpio-> Are you using rprint/rprintln?
<re_irc> <henrikssn> Yes rprintln
<Lumpio-> Could it be caused by the critical section those use internally?
<re_irc> <henrikssn> I already removed that :)
<re_irc> <henrikssn> I changed it to panic in case of nested logging
<re_irc> <henrikssn> I'll try UART logging to see if that resolves the problem or not
<re_irc> <henrikssn> Debugging the debug logs is tricky since you are flying blind
<Lumpio-> I'm not sure anybody's actually measured the amount of stalls/jitter/whatever constantly polling RTT causes
<re_irc> <henrikssn> Btw, is there a non-blocking transport for defmt over UART/USB/etc already?
<re_irc> <henrikssn> I found defmt-bbqueue but that is using critical sections
<re_irc> <James Munns> haha, beat me to it :D
<re_irc> <James Munns> you need critical sections with how defmt is built.
<re_irc> <James Munns> Since you could be mid-formatting when an interrupt fires and needs to format another.
<re_irc> <adamgreig> rprintln will waste cpu time on formatting but if there's no critical section going on that shouldn't cause jitter
<re_irc> <James Munns> (or, you need a buffer per-interrupt level)
<re_irc> <henrikssn> One buffer per interrupt level yes
<re_irc> <adamgreig> the host side rtt continuously polls the memory regardless of whether you're printing or not, so if jitter only happens when you actually rprintln it's probably not that
<re_irc> <adamgreig> what's the nature of the crash you see when reading RTT?
<re_irc> <James Munns> If you can find a reasonable way to remove that by creating N buffers, I'd be open to a PR for defmt-bbq!
<re_irc> <henrikssn> adamgreig: hmm yeah if I keep the probe connected but uncomment the logging then it doesn't crash
<re_irc> <adamgreig> if you change the print to just like "rprintln!(".");" (i.e. remove any formatting and minimise string length) does it still crash/jitter?
<re_irc> <henrikssn> It does yes
<re_irc> <henrikssn> Hmm maybe this is an rtic issue because it crashes even if I uncomment the log statement but keep the task
<re_irc> <henrikssn> I do the logging from a periodic low prio task and the realtime stuff in a high prio task
<re_irc> <henrikssn> I only share data between them as shared ref
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<Lumpio-> How does your app crashing manifest itself?
<Lumpio-> btw
<re_irc> <adamgreig> rtic also takes a few critical sections around scheduling, could they be impacting it?
<re_irc> <henrikssn> heisenbridge: It crashes when it can't meet the realtime requirements
<Lumpio-> No I mean how do you tell it's crashed
<re_irc> <henrikssn> Timer overruns before it is handled
<re_irc> <henrikssn> adamgreig: yes this might very well be the issue
<Lumpio-> errh
<Lumpio-> I mean like, how can you, as a human being, see that a timer has overrun?
<Lumpio-> Prints a message (where?)? Light an LED?
<re_irc> <henrikssn> The app panics
<Lumpio-> Which panic handler are you using
<re_irc> <yruama_lairba> weird, heapless::spsc real capacity seems to be one element less than asked/reported
<Lumpio-> capacity() should report N - 1 as well
<re_irc> <yruama_lairba> thanks, i missed the "N -1" in the doc
<re_irc> <yruama_lairba> however, there still be an error somewhere
<re_irc> <yruama_lairba> *error, is probably on my side
bpye has quit [Quit: Ping timeout (120 seconds)]
<re_irc> <henrikssn> It would be awesome if you could build a Rust embedded app with an option, so that compilation fails in case any of your dependencies disable interrupts
<re_irc> <henrikssn> It can be a bit tricky to track this down otherwise
bpye has joined #rust-embedded
<re_irc> <James Munns> You could maybe do the "panic-never" trick, replacing the cortex-m methods for critical sections, or just replace cortex-m entirely, and remove the associated methods
<re_irc> <James Munns> but that would probably break things you don't want to, like RTIC
<re_irc> <James Munns> Or, post-process the binary and look for any CPSID instructions
<re_irc> <henrikssn> maybe a feature in "cortex-m" which calls panic instead of disabling interrupts would do
<re_irc> <henrikssn> Then you get a nice stack trace to find the offending place
<re_irc> <henrikssn> Unfortunately not compilation time
<re_irc> <James Munns> you can patch override to your own version of cortex-m
<re_irc> <James Munns> the panic-never trick uses an undefined symbol to cause link-time errors if a function is ever called
<re_irc> <James Munns> at least with panic - it's a bit less deterministic, and requires you to use optimizations to ensure panic branches are never removed
<re_irc> <James Munns> it might be less touchy with something more "obvious" like disabling interrupts though
<re_irc> <James Munns> but again, you might need to patch your other deps that CAN mess with interrupt priorities, like RTIC, to prevent them from using the "fake" one
<re_irc> <James Munns> Or: You could use user mode, which I think will hardfault if you attempt to disable interrupts (though CPSID might just nop)
aspe has quit [Ping timeout: 255 seconds]
<re_irc> <James Munns> > CPS is only permitted in privileged software execution, and has no effect in User mode.
<re_irc> <James Munns> cool, cool.
<re_irc> <James Munns> so definitely don't do that lol
<re_irc> <James Munns> at least with panic - it's a bit less deterministic, and requires you to use optimizations to ensure panic branches are always removed
<re_irc> <adamgreig> henrikssn: we're looking into changing how this works for cortex-m 0.8, using the "critical-section" crate
<re_irc> <adamgreig> so the end application has to provide a handler for entering a critical section
<re_irc> <adamgreig> which by default could just be done by enabling a feature in cortex-m, but in your case you could replace it with a panic, or with whatever else (e.g. disable most interrupts, but not your high prio one)
<re_irc> <henrikssn> > disable most interrupts, but not your high prio one
<re_irc> <henrikssn> wouldn't this be unsound?
<re_irc> <James Munns> It would be if you used critical-section'd items in your hi prio task
<re_irc> <henrikssn> or I guess it won't as long as you stay away from the scheduling apis
<re_irc> <dirbaio> you could make it sound by making the CS impl panic if it's called from the "excluded" irq
<re_irc> <dirbaio> * fully safe/sound
<re_irc> <dirbaio> the CS definition (according to the "critical-section" crate at least) is "no other CS can run concurrently", not "no other code can run concurrently"
aspe has joined #rust-embedded
<re_irc> <henrikssn> dirbaio: So each CS could simply be replaced by a mutex (atomic)?
<re_irc> <henrikssn> Not sure if the CAS instruction is much more expensive vs the cpsie
<re_irc> <dirbaio> CSs already are a "kind" of mutex0
<re_irc> <dirbaio> * mutex
<re_irc> <dirbaio> a "normal" mutex that blocks waiting for the other thread to unlock it doesn't work in embedded
<re_irc> <dirbaio> because if you try to lock it from irq while main thread has locked it, the irq will spin forever waiting for main thread to unlock it, but main thread will never run because irq never returns
<re_irc> <dirbaio> this is why you use CSs instead
<re_irc> <dirbaio> disable irqs when main locks the mutex, so irqs can't fire at all in the first place, preventing the problem
gsalazar has quit [Ping timeout: 248 seconds]
aspe has quit [Quit: aspe]
<re_irc> <henrikssn> Right, the CS essentially implements priority inheritance policy, preventing the "higher" priority IRQ from preempting the main thread
<re_irc> <henrikssn> Which is great unless you really don't want anything to prevent the IRQ :)
<re_irc> <henrikssn> * preempt
<re_irc> <yruama_lairba> Hi, i'm using RTIC. for refactoring reason i'd like to know if there is a way to create a function that take as parameter an object that ned to be locked ?
<re_irc> <Kevin Clark> Hey folks - I'm just working embedded for the first time after working through the discovery book and doing a little outside reading. I'm trying to work with a HC-SR04 and a microbit (nrf52). Current goal is to time a pulse coming back from the sensor. I'm attempting to do that using GPIOTE, but it looks like when doing configuration the only way to select the pin in the config is unsafe. Is that expected and should...
<re_irc> ... I just get comfortable with it?
<re_irc> <yruama_lairba> you GPIOTE is a gpio pin ?
<re_irc> <Kevin Clark> yep. My intention is to setup an event where it detects the rising edge and captures a timer and then does a similar thing at the falling edge
<re_irc> <James Munns> GPIOTE is the interrupt-enabled version of GPIOs on the nRF family
<re_irc> <yruama_lairba> don't know nRF family, can't help
<re_irc> <Kevin Clark> I found a forum post where someone was doing something similar but in C, so I was headed that direction. But I have very little experience here, so feel free to point me elsewhere.
<re_irc> <James Munns> Kevin Clark there's also #nrf-rs:matrix.org (https://matrix.to/#/#nrf-rs:matrix.org), I think there's a method for doing that, lemme look quickly
<re_irc> <Kevin Clark> James Munns: Thank you!
<re_irc> <James Munns> You'll probably need PPI for linking the GPIOTE interrupt to the timer one I think?
<re_irc> <Kevin Clark> and I was planning PPI usage, yeah
<re_irc> <Kevin Clark> mostly trying to understand if the unsafe should be a warning I'm looking at the wrong api
<re_irc> <Kevin Clark> or if unsafe is typical at this level and I should get used to it
<re_irc> <James Munns> I don't think you need unsafe
<re_irc> <James Munns> so, you set up a gpiote channel, set it to an input pin with a reference to your GPIO pin, set the mode to something like "lo_to_hi", enable the interrupt, set the ppi event endpoint to the gpiote event, and set the task endpoint to your timer task
<re_irc> <James Munns> (that's using SPIM, but should work ~mostly the same for a timer)
<re_irc> <James Munns> (Here I'm using PPI to stop an in-progress SPI transaction when the "busy" pin goes high)
<re_irc> <James Munns> Writing unsafe is a sometimes tool, but I think in your case, you shouldn't need it for this :D
<re_irc> and
<re_irc> Are probably good places to look for better commented examples!
aspe has joined #rust-embedded
dc740 has joined #rust-embedded
aspe has quit [Quit: aspe]
<re_irc> <Kevin Clark> jamesmunns: thank you so much for the examples and references. I’ll dig in!
explore has quit [Quit: Connection closed for inactivity]
<re_irc> <Lachlan> Do any of you know how I could export a symbol from a rust binary that I'm compiling for embedded? Nothing that I've tried online seems to work.
<re_irc> <dirbaio> for calling it from C code?
<re_irc> <Lachlan> No, I want to process the binary later on and extract the git commit, which I'm pulling out of an environment variable when I'm compiling the rust
<re_irc> <dirbaio> #[used]
<re_irc> #[no_mangle]
<re_irc> static GIT_SHA: [u8;20] = [..];
<re_irc> #[link_section = ".build_info"]
<re_irc> <dirbaio> "link_section" is probably not required, if you don't put it, it'll go in ".data"
<re_irc> <dirbaio> * ".rodata"
<re_irc> <dirbaio> it can be useful so that it's present in the ELF for the postprocessing tool, but not in the final flash image
<re_irc> <Lachlan> How are you getting the SHA in binary into an environment variable?
<re_irc> <dirbaio> build.rs hacks
<re_irc> <Lachlan> Can the environment variable contain non-ascii?
<re_irc> <Lachlan> I'm using the build script as well, just assumed it had to be text though
<re_irc> <dirbaio> no idea
<re_irc> <dirbaio> I generate a .rs file from build.rs then "include!" it from the crate
<re_irc> <Lachlan> Oh sick
<re_irc> <Lachlan> dirbaio: Did you have to do anything specific with linker args or crate-types to get the symbol into the ".build_info" section?
<re_irc> <Lachlan> The section seems to contain no data for me
<re_irc> <dirbaio> ah yeah "KEEP(*(.build_info));" in the linker script inside .text
<re_irc> <dirbaio> (in my case I do want it in the flash image, but at a fixed offset. YMMV)
<re_irc> <dirbaio> I think "KEEP" is needed to prevent it from removing it due to being unused
<re_irc> <Lachlan> That worked!
<re_irc> <dirbaio> .text _stext :
<re_irc> {
<re_irc> *(.Reset);
<re_irc> KEEP(*(.build_info));
<re_irc> <Lachlan> Thank you for the help
<re_irc> <dirbaio> yw!
<re_irc> <yruama_lairba> need help. i'm using RTIC and i like to put in another module/file functions that take 'something_that_need_to_be_locked`
<re_irc> <yruama_lairba> unfortunatly i'm stuck by a private scope issue
eigenform has quit [Ping timeout: 256 seconds]
<re_irc> <yruama_lairba> i don't even understand why this module appear in generated doc since compiler claim it's private
eigenform has joined #rust-embedded
<re_irc> <yruama_lairba> found a workaround by using reexport
<re_irc> <Lachlan> I think the right way is to make your function generic on an rtic mutex
dc740 has quit [Remote host closed the connection]