<re_irc>
During development we used defmt pretty sparingly, and now that we also want unit tests, it is becoming a hurdle because "defmt::Format" and "defmt::{info, etc }" are everywhere. (Also link errors are really obfuscated)
<re_irc>
#[cfg(not(target_os = "none"))] // Linux, Windows, macOS, etc.
<re_irc>
use std::fmt::Format;
<re_irc>
<@mehmet:grusbv.com> I thought that this will work, but I think when I run "cargo test" it raises an error
<re_irc>
| ^^^ use of undeclared crate or module `std`
<re_irc>
|
<re_irc>
error[E0433]: failed to resolve: use of undeclared crate or module `std`
<re_irc>
--> vib-analyzer\src\lib.rs:12:5
<re_irc>
12 | use std::fmt::Format;
<re_irc>
<@mehmet:grusbv.com> What is a good way to separate test build and build?
<re_irc>
<@mehmet:grusbv.com> target_os feels a bit hacky
<re_irc>
<@mehmet:grusbv.com> test not(test) seems not to propagate through dependencies.
<re_irc>
<@mehmet:grusbv.com> maybe std and no_std can be separated with target_os and we can just assume that in tests they are defined and in embedded builds they will be undefined.
<re_irc>
<@mehmet:grusbv.com> Removed messages to save people's time
<re_irc>
<@mehmet:grusbv.com> So, now I am trying to understand this.
<re_irc>
<@mehmet:grusbv.com> log requires me to have Display trait implementations
<re_irc>
<@mehmet:grusbv.com> +of my variables.
<re_irc>
<@mehmet:grusbv.com> * many of my structs
<re_irc>
<@mehmet:grusbv.com> But I cannot derive Display
<re_irc>
<@mehmet:grusbv.com> Is there a better way?
vancz has quit []
vancz has joined #rust-embedded
vancz has quit [Client Quit]
vancz has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> Embassy and smoltcp use their own logging macros to switch between defmt and the log crate
<re_irc>
<@mehmet:grusbv.com> : So have found this.
<re_irc>
<@jamesmunns:beeper.com> It does mean you need to use a subset of formatting terms that work with both tho
<re_irc>
<@mehmet:grusbv.com> : Sorry, didn't get this. terms as in?
<re_irc>
<@jamesmunns:beeper.com> Like defmt supports formatters like "{=[u8]:}" that log doesn't, but both support "{}"
<re_irc>
<@mehmet:grusbv.com> Oh, that might be an issue
<re_irc>
<@mehmet:grusbv.com> Bur fair.
<re_irc>
<@mehmet:grusbv.com> * But
<re_irc>
<@mehmet:grusbv.com> So, say in embassy.
<re_irc>
<@mehmet:grusbv.com> is it better to list in the manifest
<re_irc>
<@mehmet:grusbv.com> are features "defmt" and "log" are implied with dependencies being optional?
<re_irc>
<@mehmet:grusbv.com> What I seem to use is sth like;
<re_irc>
log = ["dep:log"]
<re_irc>
[features]
<re_irc>
<@mehmet:grusbv.com> et cetera
<re_irc>
<@jannic:matrix.org> The dep: syntax is relatively new, that's probably why embassy still uses the implicit feature that comes with an optional dependency.
<re_irc>
<@dirbaio:matrix.org> if you have a optional dep that's not mentioned anywhere with a "dep:", it implicitly creates a feature with that same name
<re_irc>
<@paologentili:matrix.org> Hello, is there any way to have both the Systick interrupts and Delay<SYST>? As soon as I call the "delay" function I stop having interrupts from systick
<re_irc>
<@paologentili:matrix.org> * systick. I need the delay only once, so I can accept not having interrupts during that period of time.
<re_irc>
<@paologentili:matrix.org> Mh it seems that as soon as I turn it into a Delay provider it gets reconfigured. I guess I should rely on a timer.
<re_irc>
<@marmrt:matrix.org> : try calling "free()" on the Delay struct once you're done
<re_irc>
<@marmrt:matrix.org> You might have to re-register your original ISR as well
<re_irc>
<@yatekii:matrix.org> : interesting
<re_irc>
<@jamesmunns:beeper.com> Not even rust embedded is immune to "butt dialing" :)
<re_irc>
<@ryan-summers:matrix.org> It's like that time where I didn't realize my Yubikey was sending OTP codes over matrix everytime I took my laptop to work because I was accidentally hitting the touch part
<re_irc>
<@jessebraham:matrix.org> Haha oops
<re_irc>
<@dirbaio:matrix.org> what does CYCCNT do in WFE/WFI sleep?
<re_irc>
<@dirbaio:matrix.org> is it guaranteed to not count cycles while sleeping?
<re_irc>
<@dirbaio:matrix.org> or is it implementation depenedent?
<re_irc>
<@callym:matrix.callym.com> is there a good solution for BLE in embedded rust (yet) using chips that are easy to find?
<re_irc>
<@jessebraham:matrix.org> I wouldn't call it production-ready by any means, but we do have some level of BLE support for the Espressif chips as well:
<re_irc>
<@callym:matrix.callym.com> I thought the esp chips needed a custom rustc and things, is that still the case?
<re_irc>
<@callym:matrix.callym.com> I'm looking for a way to basically connect a bluetooth keyboard+mouse to something that then connects to a pc and forwards the connections - I've found someone built something similar using a RPi but seems a bit excessive to run a while linux stack for that (and RPis are still very hard to get hold of) - but it means I don't need anything production-ready because I'm just hacking around to make something for myself
<re_irc>
<@dirbaio:matrix.org> callym: xtensa-based ones yes, riscv-based ones (esp32c[236]) no
<re_irc>
<@callym:matrix.callym.com> thanks! is there a ""standard"" cheap development board for these like the bluepill/blackpill for stm32?
<re_irc>
<@dirbaio:matrix.org> okay, so apparently it keeps counting in sleep.
<re_irc>
there's another counter. SLEEPCNT, that counts sleep cycles. So non-sleep cycles is CYCCNT-SLEEPCNT
<re_irc>
<@dirbaio:matrix.org> but SLEEPCNT is only 8bit???
<re_irc>
<@dirbaio:matrix.org> WHY
<re_irc>
<@dirbaio:matrix.org> 256 cycles is nothing. that's useless
<re_irc>
<@dirbaio:matrix.org> what I want is to get cpu usage %
<re_irc>
<@dirbaio:matrix.org> like, every 1s read "non-sleep cycles" and then calculate cpu usage as "non-sleep-cycles / cpu-freq"
<re_irc>
<@dirbaio:matrix.org> > A counter overflows on every 256th cycle counted. When this happens, the counter wraps to 0, and if the appropriate counter overflow event is enabled in the DWT_CTRL register, the DWT outputs an Event counter packet with the appropriate counter flag set to 1
<re_irc>
<@dirbaio:matrix.org> bah, it's designed for use from the trace port, not from the core itself
<re_irc>
<@diondokter:matrix.org> : That's what I just read as well
<re_irc>
<@dirbaio:matrix.org> shame shame
<re_irc>
<@dirbaio:matrix.org> though I think nrf stops HFCLK when sleepng, right?
<re_irc>
<@dirbaio:matrix.org> * sleeping,
<re_irc>
<@dirbaio:matrix.org> perhaps not when core is sleeping but some peripheral is active
<re_irc>
<@diondokter:matrix.org> Not sure
<re_irc>
<@dirbaio:matrix.org> so perhaps with CYCCNT I can get some "% of time HFCLK is active"
<re_irc>
<@dirbaio:matrix.org> which is not the same as "% of time the core is active", but can still be useful...?
<re_irc>
> The HFCLK will run when something (peripheral) needs it.
<re_irc>
<@diondokter:matrix.org> According to a rando on a zephyr forum:
<re_irc>
<@diondokter:matrix.org> Yeah according to the nordic docs as well. So if you have a timer running, the clock will remain active
GenTooMan has quit [Ping timeout: 250 seconds]
<re_irc>
<@diondokter:matrix.org> Nordic does have EVENTS_SLEEPENTER and EVENTS_SLEEPEXIT. You could start/stop a timer with that I think
<re_irc>
<@dirbaio:matrix.org> : ooooooh this looks like exactly what I want ,3
<re_irc>
<@dirbaio:matrix.org> * <3
<re_irc>
<@dirbaio:matrix.org> wtf, why does it have to be vendor-speficic? 😭
<re_irc>
<@diondokter:matrix.org> What do you mean? ITM is perfectly portable 😋
<re_irc>
<@dirbaio:matrix.org> ITM is not useful for reporting cpu usage on devices in the field :D
GenTooMan has joined #rust-embedded
<re_irc>
<@peter9477:matrix.org> Maybe add a hook into the executor to record CYCCNT before/after the WFE, to accumulate a "time in sleep"?
<re_irc>
<@mabez:matrix.org> callym: Any of the devkits sold directly from Espressif will work, and you can also take a look at the board developed for some Rust training materials: https://github.com/esp-rs/esp-rust-board
<re_irc>
<@dirbaio:matrix.org> : that won't count time spent in interrupts
<re_irc>
<@diondokter:matrix.org> : All you need is a second MCU connected to the ITM 😁
<re_irc>
<@dirbaio:matrix.org> and I can't add that to all interrupt handlers, because some are from the softdevice
<re_irc>
<@dirbaio:matrix.org> there's one trick that allows counting irq cpu usage too:
<re_irc>
cpsid();
<re_irc>
start = now();
<re_irc>
wfe(); // sleep with interrupts disabled. An interrupt will cause wfe to return, but won't be handled yet
<re_irc>
loop {
<re_irc>
time_slept = now() - start; // so that we can count the sleep time before handling it
<re_irc>
cpsie(); // and now it will be handled
<re_irc>
}
<re_irc>
<@dirbaio:matrix.org> but that'll add a lot of latency to all irqs, i'm scared it'll make the softdevice angry and/or worsen battery life
<re_irc>
<@peter9477:matrix.org> Maybe it's good enough though? Many/most interrupts are fairly predictable/consistent, including the SD overhead (since you control advertising parameters, and possibly connection params).
<re_irc>
<@peter9477:matrix.org> By "it's" I mean the basic hook around executor WFE.
<re_irc>
<@dirbaio:matrix.org> i'm actually running everything in interrupt mode with "InterruptExecutor"
<re_irc>
<@peter9477:matrix.org> ah
<re_irc>
<@dirbaio:matrix.org> so I can set SLEEPONEXIT=1
<re_irc>
<@dirbaio:matrix.org> saves a bit of latency
<re_irc>
<@peter9477:matrix.org> Does SD restrict POWER peripheral, and its interrupt? ... in which case EVENTS_SLEEPENTER/EXIT aren't available I guess.
<re_irc>
<@dirbaio:matrix.org> no idea
<re_irc>
<@dirbaio:matrix.org> it's still probably fine to use these from PPI
<re_irc>
<@peter9477:matrix.org> (not to mention the overhead of processing those, which seems likely to be a problem)
<re_irc>
<@dirbaio:matrix.org> guess I'll find out 😅
<re_irc>
<@peter9477:matrix.org> Do you need this running all the time or just for an experiment or diagnostic? Maybe use the PPI idea to gate a timer and have the hardware count idle time for you....
<re_irc>
<@dirbaio:matrix.org> yeah that's what I was going to try
<re_irc>
<@peter9477:matrix.org> if you have a spare timer
<re_irc>
<@peter9477:matrix.org> cool
<re_irc>
<@dirbaio:matrix.org> and hopefully if it works deploy, deploy it with the main firmware
<re_irc>
<@dirbaio:matrix.org> not as just an experiment
<re_irc>
<@peter9477:matrix.org> Oh yeah, you don't care much about power consumption, do you?
<re_irc>
<@dirbaio:matrix.org> no, I do! most of our devices are battery powered that last 1y-1.5y
<re_irc>
<@dirbaio:matrix.org> I actually want this thing to diagnose some rare battery-drain issues
<re_irc>
<@dirbaio:matrix.org> collect metrics related to power usage, then when it happens I can see which metric is the outlier...
<re_irc>
<@dirbaio:matrix.org> stuff like cpu on %, radio on %, nfc active time, amount of flash operations..
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> heheeeee this works!
<re_irc>
<@peter9477:matrix.org> : Don't timers take enough power to impact your battery life significantly then? Or maybe you're just saying since the point is to figure out a problem, at which point you could remove this, then it's an acceptable tradeoff for now.
<re_irc>
<@dirbaio:matrix.org> with this code, the timer is stopped when the cpu is sleeping
<re_irc>
<@dirbaio:matrix.org> so out of these 60uA, only 4.5uA is the cpu
<re_irc>
<@peter9477:matrix.org> Sounds about right.
<re_irc>
<@peter9477:matrix.org> Do you have a power meter? Would be interesting to compare results with it, looking at the average and the idle-minimum.
<re_irc>
<@dirbaio:matrix.org> adding this 16mhz timer to measure cpu usage will add 70uA*1500ppm = 0.105uA
<re_irc>
<@almindor:matrix.org> shared SPI displays (using bus and device) with the new e310x-hal release
<re_irc>
<@almindor:matrix.org> i need to do more flashy graphics setups :D
bjc has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@deltronix:matrix.org> I have posted this as a github issue already, but perhaps someone here has ran into the same issue. When I add a dispatcher to the #app macro I get this build error:
<re_irc>
error[E0107]: this type alias takes 1 generic argument but 2 generic arguments were supplied
<re_irc>
<@dirbaio:matrix.org> or import under another name, like "use usb_device::Result as UsbResult"
<re_irc>
<@dirbaio:matrix.org> I guess the issue is emitting code using "Result", which breaks if you shadow it. Ideally it'd emit code using "::core::result::Result" ...
<re_irc>
<@dirbaio:matrix.org> +the macro
<re_irc>
<@deltronix:matrix.org> : Yeah that works, cheers!
<re_irc>
<@deltronix:matrix.org> Thought it would be some weird interaction between those two
<re_irc>
<@dirbaio:matrix.org> : yeah, a joulescope. been measuring, can't see any difference in consumption with and without that code
<re_irc>
<@jamesmunns:beeper.com> : Not totally caught up, but doesn't having cyccnt require DWT to be active, which uses a ton more power?
<re_irc>
<@jamesmunns:beeper.com> : Yeah, I have almost exactly that trick in mnemos too for measuring cpu usage :p
<re_irc>
<@dirbaio:matrix.org> it's this code
<re_irc>
<@dirbaio:matrix.org> timer + PPI to some POWER events that tell you sleep enter/exit
<re_irc>
<@dirbaio:matrix.org> better than that wfi trick
<re_irc>
<@dirbaio:matrix.org> (doesn't add latency, works with SLEEPONEXIT
<re_irc>
<@dirbaio:matrix.org> * SLEEPONEXIT)
<re_irc>
<@dirbaio:matrix.org> sevonpend is missing in cortex-m? 🤔
<re_irc>
<@peter9477:matrix.org> : I'm not confident DWT uses significant power. Does anyone have data on that? I seem to recall attempting to measure the difference with my power meter and not being able to get a precise number, because it was in the noise, therefore perhaps only a few microamps.
<re_irc>
<@peter9477:matrix.org> I've never found actual datasheet/docs on that one.
<re_irc>
<@jamesmunns:beeper.com> : I don't know if I have any citation for that, I feel like it's "folk wisdom" someone told me once and I remembered. Could be combined/mixed that I think some chips have trouble actually achieving sleep mode when the debug blocks are active.
<re_irc>
Anyway, I'll stop repeating it until I see someone quote me something more scientific :D
<re_irc>
<@peter9477:matrix.org> : I've seen the same sort of folk wisdom, and initially believed it, but gradually stopped trusting it. Currently just uncertain.
<re_irc>
<@peter9477:matrix.org> Next time I dig into power measurements I'll try to remember to do a more thorough comparison. If nothing else I can at least bracket the possible power cost within some error bars.
brazuca has joined #rust-embedded
brazuca has quit [Quit: Client closed]
brazuca has joined #rust-embedded
brazuca has quit [Quit: Client closed]
jcroisant has quit [Quit: Connection closed for inactivity]