<re_irc>
<@dkhayes117:matrix.org> So far, I like this version way better than the stm32 version
<re_irc>
<@dkhayes117:matrix.org> probably because I had never seen itm before and I had an older board that needed a weird jumper wire
<re_irc>
<@adamgreig:matrix.org> yea, the modern tooling is a joy
<re_irc>
<@adamgreig:matrix.org> where was probe-rs in 2016 huh
<re_irc>
<@dkhayes117:matrix.org> I have the v2 microbit and it came with a cool demo program that played some 8bit sounding music from a little speaker. I was a little sad when the hello world program got flashed, lol
<re_irc>
<@dkhayes117:matrix.org> From the C programming I've done, Rust is so much nicer to use even if the language is "harder".
<re_irc>
<@yatekii:matrix.org> the language is easier ;) idk how so many folks confuse that. you just suddenly have to fix your mistakes :)
<re_irc>
<@dkhayes117:matrix.org> I actually do find it easier as well
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc>
<@therealprof:matrix.org> dkhayes117:matrix.org: Hm, I thought we have an example making some noise somewhere, too. That's usually my largest worry that my kids will find the noise making stuff for such boards. 😀
<re_irc>
<@adamgreig:matrix.org> great, and now github is broken, so much for my game of CI whack-a-mole
rardiol has quit [Ping timeout: 256 seconds]
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
jackneill has joined #rust-embedded
jackneilll has quit [Ping timeout: 240 seconds]
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Quit: Leaving]
VShell has joined #rust-embedded
starblue1 has joined #rust-embedded
starblue has quit [*.net *.split]
richardeoin has quit [*.net *.split]
Shell has quit [*.net *.split]
richardeoin has joined #rust-embedded
VShell is now known as Shell
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
cr1901_ has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
creich has quit [Remote host closed the connection]
<re_irc>
<@jamesmunns:beeper.com> Does anyone here have/know of a crate that has somewhat annoying feature flags, like multiple potential buffer sizes, string text, etc?
<re_irc>
<@jamesmunns:beeper.com> Or places where certain things would be better as configuration, rather than passed-in values? maybe some string values?
<re_irc>
<@jamesmunns:beeper.com> I'm interested to put `toml-cfg` through it's paces, and would be interesting in PR'ing you a change with what it would look like
<re_irc>
<@jamesmunns:beeper.com> Or: a crate with a lot of magic numbers or magic constants, that you'd prefer to have in one config file so it can all be tweaked there.
<re_irc>
<@gauteh:matrix.org> James Munns: I saw your new crate, I'm considering using it for as a config file for a bunch of ocean-buoys that will be used in different experiments. Then I can keep the stuff changes with each experiment in the config.
<re_irc>
<@gauteh:matrix.org> as an alternative to setting environment variables, easy to forget between iterations.
creich has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> That's super cool! Let me know how it goes :D
<re_irc>
<@dirbaio:matrix.org> James Munns: I have a cursed one for you :D
<re_irc>
<@jamesmunns:beeper.com> `app` -> `crate_a` -> `crate_b`, which one needs to configure which?
<re_irc>
<@dirbaio:matrix.org> crate_a (embassy-nrf) tells crate_b (embassy) "the time tick rate is 32768hz"
<re_irc>
<@dngrs:matrix.org> jamesmunns:beeper.com: Wifi name and password would be nice to have not inline in code/committed to repo (but also tricky in a config file if other parts of that file should in fact be in repo 🤔)
<re_irc>
<@jamesmunns:beeper.com> Hmm, I guess I'd be open to having multiple config files? But that could get complicated merging them.
<re_irc>
<@jamesmunns:beeper.com> dirbaio:matrix.org: At the moment, only the app can set configuration, so you'd have to set that in app, but I guess you could assert on the value in `embassy_nrf`?
<re_irc>
<@dirbaio:matrix.org> that'd work, it'd be slightly more friction for the end user though
<re_irc>
<@jamesmunns:beeper.com> Yeah, 1:N configs is easier than N:M, I'm not sure how I would "merge" all the configs otherwise
<re_irc>
<@jamesmunns:beeper.com> (Both conceptually, as well as implementation wise)
<re_irc>
<@jamesmunns:beeper.com> * Set up the config in embassy, and export the config
<re_irc>
<@jamesmunns:beeper.com> To do this, you'd have to:
<re_irc>
<@jamesmunns:beeper.com> * `use` the config in embassy-nrf, and use something like the `static_assertions` crate to verify, and throw a comptime error if mismatched
<re_irc>
<@jamesmunns:beeper.com> * Have the user include a `cfg.toml` with `[embassy] time = 32768` or something
<re_irc>
<@gauteh:matrix.org> I've written some filtering code and I'd very much like to benchmark this on the MCU. I am not sure if benchmarking on host will be relevant (maybe simd, who knows..). Do you have any tips for how that could be done? SYST + a defmt-test maybe? Is there significant overhead in RTT? Would I be fine if I just don't do any RTT inside the code being benchmarked?
<re_irc>
<@jamesmunns:beeper.com> I typically use `groundhog` (but you can use any timer that gives you tick values) at 1Mhz, giving 1uS resolution. I tend to do something like:
<re_irc>
<@jamesmunns:beeper.com> * Run something like 1,000-1,000,000 iterations, and count time in microseconds
<re_irc>
<@jamesmunns:beeper.com> * Run for 1 second, count iterations, or
<re_irc>
<@jamesmunns:beeper.com> Then divide
<re_irc>
<@jamesmunns:beeper.com> MCUs are pretty deterministic, so as long as you don't do something slow (like logging), or have interrupts enabled, you should get pretty consistent results
<re_irc>
<@jamesmunns:beeper.com> I know Jorge used to use GDB, put a breakpoint before the code, check CYCCNT from DWT, set a breakpoint after the code, and print the delta
<re_irc>
<@gauteh:matrix.org> oh nice.
<re_irc>
<@gauteh:matrix.org> groundhog seems like the simplest solution. do you impl RollingTimer for systick ?
<re_irc>
<@jamesmunns:beeper.com> You could probably do the same (if you have a DWT), and just snapshot values before and after, e.g.:
<re_irc>
<@jamesmunns:beeper.com> ```rust
<re_irc>
<@jamesmunns:beeper.com> let x = do_expensive();
<re_irc>
<@jamesmunns:beeper.com> let start = get_ticks(); // dwt or groundhog
<re_irc>
<@jamesmunns:beeper.com> basically, start a timer in freewheeling mode (ideally 32-bit), set the TICKS_PER_SECOND to whatever the frequency is, then you can use it everywhere
<re_irc>
<@jamesmunns:beeper.com> so like anywhere you can do:
<re_irc>
<@jamesmunns:beeper.com> ```rust
<re_irc>
<@jamesmunns:beeper.com> let timer = GlobalRollingTimer::default();
<re_irc>
<@jamesmunns:beeper.com> let now = timer.get_ticks();
<re_irc>
<@jamesmunns:beeper.com> Just be careful: groundhog DOES handle timer roll-overs, but you can't compare times more than one "full window" ago. For example at 1MHz, that's about 71 minutes
<re_irc>
<@jamesmunns:beeper.com> so... don't ever hold on to "Instant"s/tick values for longer than that.
<re_irc>
<@gauteh:matrix.org> 👍️ sounds good, that won't be an issue.
<re_irc>
<@gauteh:matrix.org> thansk a lot
<re_irc>
<@jamesmunns:beeper.com> To make sure you handle wraparound correct, you'd do:
<re_irc>
<@jamesmunns:beeper.com> expensive();
<re_irc>
<@jamesmunns:beeper.com> let start = timer.get_ticks();
<re_irc>
<@jamesmunns:beeper.com> ```rust
<re_irc>
<@jamesmunns:beeper.com> let elapsed = timer.ticks_since(start);
<re_irc>
<@jamesmunns:beeper.com> and it'll handle the rollover case for you correctly, e.g. if `start` is 0xFFFF_FFF0`, and the end time is `0x0000_00F0`
<re_irc>
<@jamesmunns:beeper.com> you can also get it to calculate human times for you, like `elapsed_ms = timer.millis_since(start);`.
<re_irc>
<@gauteh:matrix.org> that is pretty good, all it is missing is taking a closure and benchmarking some code an adaptive number of times ;)
<re_irc>
<@jamesmunns:beeper.com> or like:
<re_irc>
<@jamesmunns:beeper.com> ```rust
<re_irc>
<@jamesmunns:beeper.com> let mut count = 0;
<re_irc>
<@jamesmunns:beeper.com> basically, it accumulates iterations, or total time spent doing some activity, into a struct you can dump over defmt every second
<re_irc>
<@jamesmunns:beeper.com> As sort of a "poor man's `top`"
<re_irc>
<@gauteh:matrix.org> oh. nice. that is probably useful for more complicated situations with more tasks
<re_irc>
<@gauteh:matrix.org> is there any way to run `perf` over a debugging probe?
<re_irc>
<@jamesmunns:beeper.com> Yeah, I was mostly using it for profiling how long I spent in each interrupt:
<re_irc>
<@jamesmunns:beeper.com> uhh, I think you'd probably use SWO and program counter sampling for that. I think someone doing a thesis with RTIC is doing that currently
<re_irc>
<@gauteh:matrix.org> i'm going to be fine with groundhog for now, need to make sure signal processing keeps up with data-rate
<re_irc>
<@farbodpm:matrix.org> HI, I just want to start working with interrupts in stm32f302.
<re_irc>
<@farbodpm:matrix.org> Any help ? stm32f3xx_hal crate has many code templates but I can not find stm32f3xx_hal::stm32 is missing.
<re_irc>
<@jamesmunns:beeper.com> Yeah, in that project I have an `AtomicBool` that is called "FUSE", and if the tasks ever run out of buffers, or overrun a time, they set "FUSE", and all other tasks come to a graceful stop, and requires user intervention to start again
<re_irc>
<@jamesmunns:beeper.com> It was nicer than asserting and rebooting
<re_irc>
<@gauteh:matrix.org> That's a good idea. I'm at assert + reboot now
<re_irc>
<@dngrs:matrix.org> And then either first or last occurrence takes precedence
<re_irc>
<@dngrs:matrix.org> Hmm
<re_irc>
<@dngrs:matrix.org> Panic?
<re_irc>
<@jamesmunns:beeper.com> (also implementing this is fairly hard, since you need to find the config in the REVERSE dependency order, since leaves are built first)
<re_irc>
<@jamesmunns:beeper.com> ONLY allowing the "root" to config is a bit deterministic, as we can find the "root" config by working backwards from the target directory
<re_irc>
<@jamesmunns:beeper.com> but "finding" reverse deps would be a lot harder.
<re_irc>
<@dngrs:matrix.org> I see
<re_irc>
<@dngrs:matrix.org> (BBL)
<re_irc>
<@jamesmunns:beeper.com> ✅
<re_irc>
<@adamgreig:matrix.org> I guess for intermediate dependencies (library users, basically) you could permit them to copy a config toml into out_dir so you can both find it easily?
<re_irc>
<@adamgreig:matrix.org> if you wanted to somehow have multiple config files I mean
<re_irc>
<@jamesmunns:beeper.com> But `lib_a` doesn't get built until after `lib_b` is built
<re_irc>
<@adamgreig:matrix.org> ah, yea...
<re_irc>
<@jamesmunns:beeper.com> so the proc macros or build rs won't have executed at all yet
<re_irc>
<@jamesmunns:beeper.com> (at least not deterministically)
<re_irc>
<@adamgreig:matrix.org> seems v tricky then :/ lib_a might even have been added to the build tree after lib_b was built for the first time, so it wouldn't even exist on the disk when lib_b is built
<re_irc>
<@adamgreig:matrix.org> for benchmarking code ( gauteh), dwt is probably easier to use than groundhog if you don't already have groundhog set up and your cortex-m has it? just call `dcb.enable_trace(); dwt.enable_cycle_counter()` once, then `DWT::cycle_count()` anywhere you want the count in CPU ticks
<re_irc>
<@adamgreig:matrix.org> if you do already have groundhog set up then that is even easier :P
<re_irc>
<@adamgreig:matrix.org> farbodpm:matrix.org: it's called `stm32f3xx_hal::pac`
<re_irc>
<@dirbaio:matrix.org> Does anyone know of any MCU that doesn't support both "pin interrupt on high" and "pin interrupt on low"?
<re_irc>
<@dirbaio:matrix.org> like, it assumes external pin interrupts are always "active low" or something
<re_irc>
<@dirbaio:matrix.org> or do all MCUs support both?
<re_irc>
<@adamgreig:matrix.org> one will come into existance the moment you public a crate that depends on them all supporting it
<re_irc>
<@k900:0upti.me> I think I've seen old PICs that only support rising edge
<re_irc>
<@dirbaio:matrix.org> for "level triggered" vs "edge triggered" you can emulate one out of the other with software, that doesn't worry me
<re_irc>
<@dirbaio:matrix.org> but for "active high" vs "active low", if the hardware doesn't support both then the trait wouldn't be implementable
<re_irc>
<@dirbaio:matrix.org> I think I'll unify...
<re_irc>
<@adamgreig:matrix.org> what's the advantage of it being unified?
<re_irc>
<@dirbaio:matrix.org> less trait spam
<re_irc>
<@dirbaio:matrix.org> and it forces HALs to implement all of it
<re_irc>
<@jamesmunns:beeper.com> GREAT: Grand Reunified Embedded Abstraction Technique
<re_irc>
<@dirbaio:matrix.org> for example, stm32 EXTI is edge-triggered, but drivers usually want level-triggered
<re_irc>
<@dirbaio:matrix.org> it'd be bad if a HAL decided "the hardware only supports edge-triggered, so I'm only going to impl edge-triggered!"
<re_irc>
<@jamesmunns:beeper.com> Do you just `if level.is_high() { EXTI::pend() }` in the interrupt? :p
<re_irc>
<@k900:0upti.me> That sounds like a job for specialization, whenever that lands
<re_irc>
<@k900:0upti.me> You can just default-impl all of those traits in terms of each other
<re_irc>
<@adamgreig:matrix.org> stm32 is edge-triggered?
<re_irc>
<@adamgreig:matrix.org> oh, sorry, yes
<re_irc>
<@dirbaio:matrix.org> it's not that trivial to emulate level-triggered out of edge-triggered *above* the traits, it's best done in the HAL
<re_irc>
<@adamgreig:matrix.org> I don't think you can provide wait_for_low with just a wait_for_rising and wait_for_falling primitive, because it needs to return immediately if it's already low, you'd need InputPin or whatever as well?
<re_irc>
<@adamgreig:matrix.org> so makes sense for the HAL to implement it
<re_irc>
<@dirbaio:matrix.org> adamgreig: yeah it'd need InputPin as well, but even then it's not trivial
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@dirbaio:matrix.org> like, for `wait_for_low` you could create the `wait_for_falling` future, poll it once, then check gpio level, return if already low, otherwise wait on the future
<re_irc>
<@dirbaio:matrix.org> if you check gpio level *first* it's racy
<re_irc>
<@dirbaio:matrix.org> but that relies on the HAL setting up the interrupt and state in the *first* poll, which is not guaranteed at all
<re_irc>
<@xiretza:xiretza.xyz> hi, quick Q: there shouldn't be any problem with building application logic in rust as a static library, then linking that into a C HAL/BSP/init, right? aside from the usual joys of FFI
<re_irc>
<@chrysn:matrix.org> In general, that works.
<re_irc>
<@adamgreig:matrix.org> Yea, works well. You might need to add a panic handler is the only thing I found.
<re_irc>
<@xiretza:xiretza.xyz> ah yeah, that makes sense
<re_irc>
<@chrysn:matrix.org> You may need to do some own unsafe footwork to get back the comforts provided by many Rust crates, but that's to be expected. (Eg. unlike with the cortex embedded crates' main, you don't get any help in safely accessing static variables as Rust won't know that the BSP really only calls your main function once).
<re_irc>
<@xiretza:xiretza.xyz> I'll try to get by without globals as much as possible, but I'll keep that in mind, thanks!
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [*.net *.split]
Shell has quit [*.net *.split]
ni has quit [*.net *.split]
bpye has quit [*.net *.split]
re_irc has quit [*.net *.split]
dreamcat4 has quit [*.net *.split]
sauce has quit [*.net *.split]
cyrozap has quit [*.net *.split]
Ekho has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
mrkajetanp has quit [*.net *.split]
x56 has quit [*.net *.split]
rardiol has quit [*.net *.split]
creich has quit [*.net *.split]
wose has quit [*.net *.split]
Amanieu has quit [*.net *.split]
emerent has quit [*.net *.split]
mightypork_ has quit [*.net *.split]
hifi has quit [*.net *.split]
tafa has quit [*.net *.split]
jasperw has quit [*.net *.split]
Darius has quit [*.net *.split]
eigenform has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
vancz has quit [*.net *.split]
nohit has quit [*.net *.split]
agg has quit [*.net *.split]
darknighte has quit [*.net *.split]
dne has quit [*.net *.split]
Rondom has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
jackneill has quit [*.net *.split]
gsalazar_ has quit [*.net *.split]
Amadiro has quit [*.net *.split]
radens has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
Rahix has quit [*.net *.split]
Socke has quit [*.net *.split]
inara has quit [*.net *.split]
Lumpio- has joined #rust-embedded
Ekho- has joined #rust-embedded
cyrozap-ZNC has joined #rust-embedded
ni_ has joined #rust-embedded
Ultrasauce has joined #rust-embedded
dreamcat4 has joined #rust-embedded
re_irc_ has joined #rust-embedded
VShell has joined #rust-embedded
bpye has joined #rust-embedded
x56 has joined #rust-embedded
Foxyloxy has joined #rust-embedded
Amanieu has joined #rust-embedded
emerent has joined #rust-embedded
hifi has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
jackneill has joined #rust-embedded
mrkajetanp has joined #rust-embedded
wose has joined #rust-embedded
mightypork_ has joined #rust-embedded
radens has joined #rust-embedded
Amadiro has joined #rust-embedded
gsalazar_ has joined #rust-embedded
eigenform has joined #rust-embedded
vancz has joined #rust-embedded
creich has joined #rust-embedded
Darius has joined #rust-embedded
jasperw has joined #rust-embedded
tafa has joined #rust-embedded
Rondom has joined #rust-embedded
dne has joined #rust-embedded
darknighte has joined #rust-embedded
nohit has joined #rust-embedded
agg has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
inara has joined #rust-embedded
Rahix has joined #rust-embedded
Socke has joined #rust-embedded
rardiol has joined #rust-embedded
re_irc_ is now known as re_irc
VShell is now known as Shell
ni_ is now known as ni
<re_irc>
<@korken89:matrix.org> Does there exist any acceptable asymmetric encryption create that works well on embedded?
<re_irc>
<@chrysn:matrix.org> I've seen an implementation of the EDHOC protocol; didn't verify how far the author went to be embedded friendly, but at least it's no-std
<re_irc>
<@chrysn:matrix.org> But for many practical things you may want to look into hardware acceleration: The software implementation I used when evaluating group OSCORE took about 1s for an (otherwise simple) 25519 signature, and hardware acceleration would get that down by an order of magnitude
<re_irc>
<@korken89:matrix.org> Thanks!
cr1901 has joined #rust-embedded
Ultrasauce is now known as sauce
<re_irc>
<@ia0:matrix.org> dirbaio:matrix.org: Why is this done with a feature rather than a compile-time constant? If it's because some types differ depending on the value, then it should be possible to do that logic with traits and associated types right? Just not very readable, so it's essentially a trade off
<re_irc>
<@dirbaio:matrix.org> embassy defines Instant, Duration types that are internally "count of ticks". It exposes methods to conver to/from seconds, milliseconds, etc so it has to know the tick rate
<re_irc>
<@dirbaio:matrix.org> to avoid expensive maths, it's nice if the tick rate matches the hardware tick rate, and different hardware ticks at different rates (nrf rtc is 32khz, nrf timer is 1mhz, etc)
<re_irc>
<@dirbaio:matrix.org> so the "time driver" is what sets the tick rate
<re_irc>
<@dirbaio:matrix.org> the crates that provide the "time driver" (embassy-nrf, embassy-stm32) depend on embassy, so embassy can't depend on them
<re_irc>
<@dirbaio:matrix.org> so you can't use consts
<re_irc>
<@dirbaio:matrix.org> the value has to be passed "down" the dependency tree, not "up"
<re_irc>
<@dirbaio:matrix.org> and I don't want to use const generics like `struct Instant<const TICK_RATE: u64>` because they make using the Instant/Duration types horrible. I want them to be just `Instant`, `Duration`
<re_irc>
<@dirbaio:matrix.org> so Cargo features it is :P
rardiol has quit [Ping timeout: 245 seconds]
<re_irc>
<@chrysn:matrix.org> are const generics so bad? in the riot wrappers i'm using them everywhere where clocks are involved (admittedly not much yet), and the types are rarely spelled out in practical code.
<re_irc>
<@ia0:matrix.org> but I agree it's not perfect so it's still a trade-off and I see why having generics everywhere is not great
Ekho- is now known as Ekho
dne has quit [Ping timeout: 268 seconds]
dne has joined #rust-embedded
rardiol has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> ia0:matrix.org: also, I want a lib to be able to use `embassy::time::Instant` and co without having to care which driver is in use. having the driver crate reexport type aliases like that works for end user code because it uses a particular driver, but not lib code.
<re_irc>
<@ia0:matrix.org> I see, makes sense
<re_irc>
<@dirbaio:matrix.org> one consequence is it's not possible to use 2 different time drivers at once
<re_irc>
<@dirbaio:matrix.org> const generics would allow that
<re_irc>
<@dirbaio:matrix.org> but it shold be super rare
<re_irc>
<@dirbaio:matrix.org> the goal was to get something that is "global" and "just works", as easy to use as std's Instant/Duration
rardiol has quit [Ping timeout: 256 seconds]
dne has quit [Ping timeout: 268 seconds]
dne has joined #rust-embedded
<re_irc>
<@Ericson2314:matrix.org> I dumped a stock config to a target json and used that verbatim, and atomics dissapaer
<re_irc>
<@Ericson2314:matrix.org> has anyone else noticed such a thing?
<re_irc>
<@Ericson2314:matrix.org> This is rust 1.53
<re_irc>
<@Ericson2314:matrix.org> I just forced `atomic-cas = true` and it went back, but how odd
<re_irc>
<@Ericson2314:matrix.org> is `--print ....` with `--target thumbv6m-non-eabi` impure?!