starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> torne:matrix.org: That's nuts! I agree in your case you may wish to have an intermediate PAC-like layer.
<re_irc> <@firefrommoonlight:matrix.org> Unfortunately, you won't be able to auto-gen it like you can with SVDs
<re_irc> <@firefrommoonlight:matrix.org> This also depends on if you're trying to write a general driver you can use later, of if you only need to implement specific functionality for a project
<re_irc> <@firefrommoonlight:matrix.org> (The latter is a lot easier!)
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <@korken89:matrix.org> henrik_alser:matrix.org: ( adamgreig ) there is no PR yet, but the idea of simple, let the user specify the instant and duration type of their time library (and we assert that it has the right traits implemented), then RTIC will happily use it. I needed to finish a first version of my time library so we have two to design with and make sure it works as we want :) I released the "const embedded time" lib...
<re_irc> ... yesterday, you can have a look here is you're interested: https://crates.io/crates/fugit
<re_irc> <@korken89:matrix.org> So now we can finalize the the monotonic trait
tokomak has joined #rust-embedded
edm has quit [Ping timeout: 264 seconds]
SanchayanMaity has quit [Read error: Connection reset by peer]
SanchayanMaity has joined #rust-embedded
edm has joined #rust-embedded
fabic_ has quit [Remote host closed the connection]
fabic has joined #rust-embedded
tokomak has quit [Ping timeout: 264 seconds]
<re_irc> <@andresv:matrix.org> korken89: I have a stupid question about fugit. Let's say I would like to use `trait CountDown` https://github.com/rust-embedded/embedded-hal/blob/master/src/timer.rs#L63-L86 using `fugit` Duration as `count`:
<re_irc> <@andresv:matrix.org> ```rust
<re_irc> <@andresv:matrix.org> use fugit::ExtU32;
<re_irc> <@andresv:matrix.org> This would allow `start` it like this:
<re_irc> <@korken89:matrix.org> You should select a duration
<re_irc> <@korken89:matrix.org> Or parameterize over `NOM / DENOM` and const generics
<re_irc> <@korken89:matrix.org> So eg `Time = MillisDurationU32`
<re_irc> <@korken89:matrix.org> Then it should work fine
<re_irc> <@andresv:matrix.org> Yes it works. I just missed `.into()` and that gave little bit confusing error message.
<re_irc> <@andresv:matrix.org> impl CountDown for SysTimer {
<re_irc> <@andresv:matrix.org> ```rust
<re_irc> <@andresv:matrix.org> type Time = fugit::Duration<u32, 1, 1000>;
<re_irc> <@andresv:matrix.org> What is the deal with ✂️ and 📝?
<re_irc> <@korken89:matrix.org> andres: Awesome!
<re_irc> <@korken89:matrix.org> andres: I think this is when the IRC bridge puts something in a pastebin
fabic has quit [Ping timeout: 265 seconds]
fabic has joined #rust-embedded
<re_irc> <@andresv:matrix.org> korken89: Let's say I have somekind of lib which has following enum. Instant is used here to timestamp for example when start was called.
<re_irc> <@andresv:matrix.org> use fugit::Instant;
<re_irc> <@andresv:matrix.org> ```rust
<re_irc> <@andresv:matrix.org> enum State {
<re_irc> <@korken89:matrix.org> To make something generic of the `Instant` I'd recommend using const generic parameters
<re_irc> <@andresv:matrix.org> Yes right I can do that.
<re_irc> <@korken89:matrix.org> enum State<const N: u32, const D: u32> {
<re_irc> <@korken89:matrix.org> Start(Instant<u32, N, D>);
<re_irc> <@korken89:matrix.org> Stop(Instant<u32, N, D>);
<re_irc> <@korken89:matrix.org> }
<re_irc> <@korken89:matrix.org> As instants generally do not have the same baseline, converting between instants is not valid
<re_irc> <@korken89:matrix.org> This is why these conversions are not implemented for Instant, but are for Duration
<re_irc> <@andresv:matrix.org> Jep that makes sense. I am converting one of the lib that is using `embedded-time` to `fugit`.
<re_irc> <@korken89:matrix.org> Ah nice!
<re_irc> <@korken89:matrix.org> Thanks for giving it a try!
<re_irc> <@korken89:matrix.org> I have not come that far myself yet with RTIC
<re_irc> <@korken89:matrix.org> Ping me if you find more issues with the interface or usability :)
<re_irc> <@korken89:matrix.org> It's only `0.1` so probably a lot of room for improvement
<re_irc> <@ryan-summers:matrix.org> Honestly, I would desperately prefer that any `Instant` only have a single type param at most, like embedded-time
<re_irc> <@korken89:matrix.org> How so?
<re_irc> <@korken89:matrix.org> The nice part with fugit is that you can choose one, and not be generic
<re_irc> <@korken89:matrix.org> Then the implementation is made so it does conversions to your chosen one at compile time
<re_irc> <@korken89:matrix.org> So the generic is only to set your specification
<re_irc> <@ryan-summers:matrix.org> Is there a generic type that any library can use?
<re_irc> <@korken89:matrix.org> The rest of usage will be converted to your specification
<re_irc> <@ryan-summers:matrix.org> I want crates to be able to make use of various `Instant`s and they have no concept of what the underlying system time keeping mechanism is
<re_irc> <@korken89:matrix.org> This is why it's so heavy on the `const` side
<re_irc> <@korken89:matrix.org> ryan-summers:matrix.org: Same as we want in RTIC
<re_irc> <@korken89:matrix.org> ryan-summers:matrix.org: Not quite sure what you mean?
<re_irc> <@korken89:matrix.org> As it converts at compile time you can choose any concrete type that fits your use case
<re_irc> <@ryan-summers:matrix.org> One thing I really like about embedded-time is that I can construct a `Clock` and hand it to a crate so that crate can now internally keep time on an arbitrary system
<re_irc> <@korken89:matrix.org> The clock part is not part of fugit
<re_irc> <@ryan-summers:matrix.org> Take for example my minimq crate, where I need to periodically send out `PING` messages at a set interval
<re_irc> <@korken89:matrix.org> If you want a clock trait it would be a different crate
<re_irc> <@ryan-summers:matrix.org> Does fugit support some `clock`-like trait?
<re_irc> <@korken89:matrix.org> It only defines instants and durations, if you want a clock trait that returns an instant this is fine - but up to you
<re_irc> <@korken89:matrix.org> E.g. if you want to make sure 2 instants are from different clocks, you would have the old interface of embedded-time
<re_irc> <@korken89:matrix.org> This is not the aim of fugit though, it only handles the time math very efficiently and with concrete types
<re_irc> <@ryan-summers:matrix.org> Gotcha
<re_irc> <@korken89:matrix.org> The areas where embedded-time did not do well
<re_irc> <@ryan-summers:matrix.org> ... agreed
<re_irc> <@korken89:matrix.org> You could on top of this make a crate like fugit-traits
<re_irc> <@korken89:matrix.org> And add an embedded-time like API
<re_irc> <@ryan-summers:matrix.org> I've fought embedded-time so incredibly much just trying to get e.g. a `Second(1) / 2`
<re_irc> <@korken89:matrix.org> Indeed
<re_irc> <@ryan-summers:matrix.org> Which is absurd
<re_irc> <@korken89:matrix.org> Plus that and expression like that should be compile time optimized
<re_irc> <@korken89:matrix.org> Plus another thing
<re_irc> <@korken89:matrix.org> As fugit uses concrete types you dont get the generic instantiation bloat that embedded-time has
<re_irc> <@korken89:matrix.org> If you want to write a function which takes a duration for example
<re_irc> <@korken89:matrix.org> Just let the compiler do the conversion for you to whatever granularity you choose
<re_irc> <@korken89:matrix.org> Only one impl is generated
<re_irc> <@korken89:matrix.org> We had quite big issues in RTIC to not get an implementation of the entire `spawn_after` system for every different duration the use hit us with in their code
<re_irc> <@korken89:matrix.org> And generating concrete type compression points was extremely difficult
<re_irc> <@korken89:matrix.org> So in `fugit` I simply removed this way of doing it
<re_irc> <@korken89:matrix.org> `The power of const compels you`
<re_irc> <@korken89:matrix.org> ryan-summers: I think something like this would be a clock interface ala embedded-time:
<re_irc> <@korken89:matrix.org> /// The type to hold the tick count
<re_irc> <@korken89:matrix.org> type Instant: fugit::Instant::<u64, 1, 1_000_000>;
<re_irc> <@korken89:matrix.org> pub trait Clock: Sized {
<re_irc> <@korken89:matrix.org> (not tested)
<re_irc> <@ryan-summers:matrix.org> I assume `type instant: fugit::Instant` is supposed to be `type instant = fugit::Instant`, e.g. default instant type?
<re_irc> <@ryan-summers:matrix.org> Was thinking that was some strange type trait impl shenanigans for a moment
<re_irc> <@jordens:matrix.org> korken89: I have only looked at fugit for a few seconds, please excuse my ignorance. But from the perspective of someone who has worked many years in time and frequency in national metrology institutes, your approach looks promising. I don't know whether the implementation is correct in detail, but I agree that `fugit` can likely solve the massive and fundamental unsoundness and the current problems with the...
<re_irc> ... existing crates.
<re_irc> <@korken89:matrix.org> ryan-summers:matrix.org: Ah yes
<re_irc> <@korken89:matrix.org> I mixed implementation and definition
<re_irc> <@korken89:matrix.org> Only would select a `fugit::Instant` as the `Clock::Instant`
<re_irc> <@korken89:matrix.org> jordens:matrix.org: Thanks!
<re_irc> <@korken89:matrix.org> I stole 99% of the math from embedded-time and made them const where it was not possible originally
<re_irc> <@korken89:matrix.org> The only thing I do differently is that I optimize the numerator and denominator for an expression at compile time
<re_irc> <@korken89:matrix.org> But I'm also not 100% sure everything is correct
<re_irc> <@jordens:matrix.org> But the idea of a rational time base and integer ticks on that is sound.
<re_irc> <@korken89:matrix.org> I only have basic testing in place, including overflow/wrapping testing
<re_irc> <@korken89:matrix.org> But I think there are edge cases not coverted
<re_irc> <@korken89:matrix.org> jordens:matrix.org: Yeah, both embedded-time and fugit uses the same idea here :D
<re_irc> <@chmanie:matrix.org> I'm trying to use cortex-m-rt in version 0.7.0 in my project but I'm getting loads of what I assume are linker errors:
<re_irc> <@chmanie:matrix.org> = note: rust-lld: error: undefined symbol: PVD
<re_irc> <@chmanie:matrix.org> I was upgrading from 0.6.13. Is there anything I'm missing here?
<re_irc> <@chmanie:matrix.org> On the same note, has anyone ever experienced issues with the `#[entry]` macro confusing `rust-analzyer`? It doesn't seem to pick up variable names anymore once `#[entry]` is present
<re_irc> <@korken89:matrix.org> Have you enabled the procmacro support?
<re_irc> <@jordens:matrix.org> korken89:matrix.org: My impression was that embedded-time doesn't really follow through with it though and that's where it becomes hairy and unsound.
<re_irc> <@jordens:matrix.org> Basically you want to free yourself from any preference for a timescale. That includes not interpreting/coerscing anything to SI units.
<re_irc> <@korken89:matrix.org> Ah yeah
<re_irc> <@korken89:matrix.org> That's true
<re_irc> <@chmanie:matrix.org> korken89: oh wow yeah that's a really good point. I don't think I have
<re_irc> <@korken89:matrix.org> I think its experimental still
<re_irc> <@chmanie:matrix.org> It seems like it's enabled by default now
<re_irc> <@chmanie:matrix.org> But I guess the experimental-ness of it is the reason why it doesn't work (yet)
<re_irc> <@chmanie:matrix.org> Thanks korken89, that's definitely a good point
<re_irc> <@sourcebox:matrix.org> I had some thoughts about the whole time traits discussion and did some experiments with code on an STM32L4 Nucleo board.
<re_irc> <@sourcebox:matrix.org> I think that stuff can really be optimized when the caller of Instant::now() specifies something additional.
<re_irc> <@sourcebox:matrix.org> Like`'let instant = Instant<Milliseconds>::now()`
<re_irc> <@sourcebox:matrix.org> But I don't know if this concept is the way to go.
<re_irc> <@korken89:matrix.org> Something comparable would be `let d: MillisDurationU32 = Instant::now().duration_since_epoch().convert()` ?
<re_irc> <@sourcebox:matrix.org> Performancewise, the expensive stuff happens on two places: creating the instant and converting it.
<re_irc> <@sourcebox:matrix.org> If the needed precision is known at the instantiation, you can get around it.
<re_irc> <@korken89:matrix.org> The more general problem here is that Instants generally are not connected to a specific time unit, so the conversion is always needed
<re_irc> <@sourcebox:matrix.org> But the implementation can optimize it for common use cases like Milliseconds.
<re_irc> <@korken89:matrix.org> Plus that instants in their own right are barely used, only durations form a good basis for thing more can comparison
<re_irc> <@korken89:matrix.org> sourcebox:matrix.org: Not sure I follow your problem
<re_irc> <@sourcebox:matrix.org> Yes, but duration is mostly addition and subtraction.
<re_irc> <@korken89:matrix.org> Unless time base changes are needed, then muls and divs
<re_irc> <@korken89:matrix.org> What issue is it you are looking to solve?
<re_irc> <@sourcebox:matrix.org> When I create an instant in my app code, I decide which precision is needed. If I create it with ms, I'm quite sure I don't do conversions to µs.
<re_irc> <@korken89:matrix.org> What do you mean with converting an instant?
<re_irc> <@korken89:matrix.org> They are opaque types without fixed baseline, so you can't really convert their bases
<re_irc> <@sourcebox:matrix.org> The main issue is that embedded-hal does not have Instant types because noone knows how they should look like.
<re_irc> <@korken89:matrix.org> Exactly
<re_irc> <@korken89:matrix.org> You generally only work in durations
<re_irc> <@korken89:matrix.org> Instants are only a means to get durations in the end
<re_irc> <@korken89:matrix.org> As they have a fixed baseline of 0
<re_irc> <@sourcebox:matrix.org> In the end, I need real time units.
<re_irc> <@korken89:matrix.org> So you have a duration and want it in millis?
<re_irc> <@korken89:matrix.org> `let d: Duration::<_, 1, 1000> = old_d.convert();` seems like what you want to do?
<re_irc> <@korken89:matrix.org> And then only use it in millis
<re_irc> <@sourcebox:matrix.org> Yes, but the main issue is that conversions imply expensive divisions if not optimized from the start.
<re_irc> <@korken89:matrix.org> If they are generated from a different timebase they never will be optimized completely, you would need to select an instant timebase that has the same granularity
<re_irc> <@sourcebox:matrix.org> This is no problem on a Cortex-M4 but for smaller chips it's not a good idea.
<re_irc> <@korken89:matrix.org> If your timer runs at 1 MHz and you want millis, you are forced to do the / 1000 divition
<re_irc> <@sourcebox:matrix.org> Yes, but I can decide how fast my timer runs. And this is 1k in my case.
<re_irc> <@korken89:matrix.org> Sure, then there is no problem
<re_irc> <@korken89:matrix.org> E.g. in fugit that will optimize to no conversion
<re_irc> <@korken89:matrix.org> The checks made for "same base" are done at compile time
<re_irc> <@sourcebox:matrix.org> With a Cortex, you can still get µs precision even if the systick runs on 1k only.
<re_irc> <@korken89:matrix.org> ?
<re_irc> <@korken89:matrix.org> Sure you can link multiple timers if you want to make a dual timer with different time bases
<re_irc> <@sourcebox:matrix.org> No, i'm talking about much simpler stuff.
<re_irc> <@korken89:matrix.org> I'm still not following on the problem though, what is it you are trying to solve?
<re_irc> <@korken89:matrix.org> Do you want to make a clock abstration that minimizes conversions?
<re_irc> <@korken89:matrix.org> E.g. in RTIC we don't do a single time conversion for the entire scheduling framework when applying `fugit`
<re_irc> <@sourcebox:matrix.org> Again, what I need in the end is `time::millis()` and `time::micros()` and this should play together with the `embedded-hal` abstraction.
<re_irc> <@korken89:matrix.org> You can implement a `Clock` abstration which does that
<re_irc> <@sourcebox:matrix.org> But it seems that my concept is too simple. Even the Arduino stuff provides them.
<re_irc> <@korken89:matrix.org> pub trait Clock: Sized {
<re_irc> <@korken89:matrix.org> fn micros(&self) -> Instant::<u32, 1, 1_000_000>;
<re_irc> <@korken89:matrix.org> fn milllis(&self) -> Instant::<u32, 1, 1_000>;
<re_irc> <@korken89:matrix.org> E.g.:
<re_irc> <@korken89:matrix.org> }
<re_irc> <@sourcebox:matrix.org> Where is this code from?
<re_irc> <@korken89:matrix.org> Directly from my head :)
<re_irc> <@korken89:matrix.org> That is the trait I would make for your usecase
<re_irc> <@sourcebox:matrix.org> It's not the point that I can do this on my own. The point is that embedded-hal should at least provide this simple stuff so it can be used widely.
<re_irc> <@korken89:matrix.org> Sure, but something simple like that you can make into your own crate if you don't want it to go through the WG machinery
<re_irc> <@korken89:matrix.org> But I'm not that into the `embedded-hal` design decision process
<re_irc> <@sourcebox:matrix.org> But this is what the initial discussion was about.
<re_irc> <@korken89:matrix.org> Ah, then I misunderstood you - I though you were looking for a clock abstration
<re_irc> <@sourcebox:matrix.org> embedded-hal is lacking these traits, there's an issue open in the tracker for more than one year now.
<re_irc> <@korken89:matrix.org> I think the main issue is that `embedded-hal` does not want to tie itself to a specific time library
<re_irc> <@korken89:matrix.org> We did that error in RTIC
<re_irc> <@sourcebox:matrix.org> It does not have to
<re_irc> <@korken89:matrix.org> And now we are redesigning those parts
<re_irc> <@korken89:matrix.org> I have to leave now, cya around all
<re_irc> <@sourcebox:matrix.org> To me, embedded-hal should provide traits that define Instant and Duration in a way that does not imply a large performance drop when implementing them.
<re_irc> <@ryan-summers:matrix.org> I think the reason it hasn't is because it's hard. Just look at our current discussion
<re_irc> <@sourcebox:matrix.org> I know, but a solution has to be found at some point.
<re_irc> <@ryan-summers:matrix.org> But there's no reason that solution has to be the only one or that it has to be incorporated into the `embedded-hal` yet
<re_irc> <@ryan-summers:matrix.org> Different approaches have different tradeoffs
<re_irc> <@firefrommoonlight:matrix.org> I think you should tie these down with specific use cases in midn
<re_irc> <@firefrommoonlight:matrix.org> Perhaps it would be best to start with projects you use that use time durations, or if you don't have that but still want to build infrastructure, public examples
<re_irc> <@sourcebox:matrix.org> But the amount of discussion shows that there's some interest to get this in.
<re_irc> <@ryan-summers:matrix.org> A lot of it is driven by RTIC
<re_irc> <@ryan-summers:matrix.org> Since RTIC has a scheduler as part of it
<re_irc> <@firefrommoonlight:matrix.org> Then it should be easy to find concrete examples
<re_irc> <@ryan-summers:matrix.org> What they choose to use will ultimately drive a lot of the ecosystem
<re_irc> <@firefrommoonlight:matrix.org> Chicken+egg problem?
<re_irc> <@ryan-summers:matrix.org> The only place I seriously need time support is in an MQTT TCP client: https://github.com/quartiq/minimq/blob/master/src/mqtt_client.rs
<re_irc> <@firefrommoonlight:matrix.org> There are probably some chickens around
<re_irc> <@firefrommoonlight:matrix.org> Find code bases that use RTIC and would benefit
<re_irc> <@firefrommoonlight:matrix.org> and see what works
<re_irc> <@ryan-summers:matrix.org> I just need to manage elapsed seconds. Smoltcp has similar issues with having an `Instant` for the network stack to know when to manage TCP-related ops, DHCP, DNS etc.
<re_irc> <@firefrommoonlight:matrix.org> I'm using it for one growing codebase, but can't comment since I only use its resource management, not scheduling
<re_irc> <@firefrommoonlight:matrix.org> I'm using ISRs and manually managing timers, but maybe I'll look at RTIC's scheduling soon
<re_irc> <@ryan-summers:matrix.org> I haven't had a need for `embedded-time` Instant support for anything more granular than e.g. 500ms
<re_irc> <@ryan-summers:matrix.org> And I assume anything less will start having serious impacts on performance just due to time math
<re_irc> <@ryan-summers:matrix.org> E.g. if you're working with uS durations on a 1MHz processor, just the additions have a big impact
<re_irc> <@firefrommoonlight:matrix.org> Can you think of any examples? For background, in the WIP project I'm thinking of (The one that uses RTIC), I use tmings on the order of 48kHz (it's audio), which comes from the MCU's audio clock, via DMA transfer complete and HT complete interrupts. I also use timers with ~second order timing to let's say, start or stop playing a certain tone or sound
<re_irc> <@firefrommoonlight:matrix.org> Would `embedded-time` etc help there? I don't know it well enough to comment
<re_irc> <@ryan-summers:matrix.org> The actual timing of the 48KHz audio is almost always going to be using a hardware peripheral, so `Instant`s are irrelevant there. The only time `embedded-time` makes sense is for the sloppier, longer scale start/stop actions
<re_irc> <@ryan-summers:matrix.org> You don't want a software-based time solution for any real-time constraints
<re_irc> <@sourcebox:matrix.org> Even the blinky LED needs a timebase.
<re_irc> <@firefrommoonlight:matrix.org> Blinky LED examples are historically done with cortex-m etc delays
<re_irc> <@ryan-summers:matrix.org> Yeah, but RTIC handles things like that. The reason I like embedded-time is that it gives you an application-aspecific clock for a generic crate
<re_irc> <@firefrommoonlight:matrix.org> You could also do it with a timer + ISR
<re_irc> <@sourcebox:matrix.org> Delay needs also a timebase.
<re_irc> <@firefrommoonlight:matrix.org> Then setting up your timer with something like
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> timer.set_period(0.3).ok();
<re_irc> <@firefrommoonlight:matrix.org> And cycling the LED in the ISR or w/e
<re_irc> <@firefrommoonlight:matrix.org> The delay timebase would come from the systick clock
<re_irc> <@firefrommoonlight:matrix.org> the timer timebase would come from whatever clock that uses
<re_irc> <@firefrommoonlight:matrix.org> I'm curious where the time abstraction fits in
<re_irc> <@ryan-summers:matrix.org> In any real application, you're not doing a busywait loop for blinking an LED
<re_irc> <@sourcebox:matrix.org> When I do delay_ms(), I need a ms() function first, but the trait for this is missing.
<re_irc> <@firefrommoonlight:matrix.org> Yea - we shoudl drop the blinky thing
<re_irc> <@firefrommoonlight:matrix.org> TBH I'm not a fan of its ubiquity as an example
<re_irc> <@firefrommoonlight:matrix.org> I'm coding time-related stuff ATM btw
<re_irc> <@burrbull:matrix.org> korken89: What about Rate and Duration <-> Rate conversion. Is it planned?
<re_irc> <@firefrommoonlight:matrix.org> Interplay between DMA, ISRs, and timers
<re_irc> <@firefrommoonlight:matrix.org> I'm making an interactive audiogram, that involves playing various combinations of noise, tones overlayed over the noise etc. Can you think of how the abstraction would work there?
<re_irc> <@ryan-summers:matrix.org> Generally, I see the use case of embedded-time for generic protocol crates. I find it less useful for applications
<re_irc> <@ryan-summers:matrix.org> Unless it's for task scheduling, but as I mentioned, RTIC manages that for you behind the scenes
<re_irc> <@firefrommoonlight:matrix.org> Basically, There's a double-output buffer fed into the audio periph (SAI) using circular DMA. So it continuously plays, and we sequence which side we play from, and which we can edit using DMA ISRs on HT and TC. I use timers to control how long each tone plays among the noise, and for things like timeout on user input response to the noise, and how long the user takes
<re_irc> <@firefrommoonlight:matrix.org> How would you fit your time abstraction in there? THere are several areas of attack
<re_irc> <@firefrommoonlight:matrix.org> Gotcha
<re_irc> <@firefrommoonlight:matrix.org> (ISR == RTIC task actually here)
<re_irc> <@firefrommoonlight:matrix.org> My thoughts in summary: Think about what the use case is. Who's the user, and how will this abstraction look in code.
<re_irc> <@sourcebox:matrix.org> Even if you don't like the blinky example, I have to say that the products I develop usually use some LEDs doing that thing.
<re_irc> <@firefrommoonlight:matrix.org> As korken89 just said, perhaps generic protocol crates. Start there and flesh it out. Find the crates and people who use them, and see how it would fit in
<re_irc> <@ryan-summers:matrix.org> Yes, LEDs are often used, but they are never implemented in the trivial method of "block all other code while we blink them" because the controller has better things to do
<re_irc> <@firefrommoonlight:matrix.org> *Sorry, you mentioned generic protocol crates
<re_irc> <@sourcebox:matrix.org> Yes, of course. LEDs should be non-blocking, that's obvious. This is what you learn as step 2 after doing step 1 with the delay function.
<re_irc> <@firefrommoonlight:matrix.org> You don't have to!
<re_irc> <@firefrommoonlight:matrix.org> It (can be) a few lines to do it with a timer and ISR
<re_irc> <@firefrommoonlight:matrix.org> But this is a bit of a tangent
<re_irc> <@firefrommoonlight:matrix.org> wherein I rant about examples that are too narrow-focused and/or unrealistic
<re_irc> <@ryan-summers:matrix.org> Honestly, LED blinking, unless you're doing dimming, is generally so timing tolerant that you just do it with a software-based timing solution, so `Instant` does actually make sense there
<re_irc> <@ryan-summers:matrix.org> But I don't know if that warrants some complexities of `embedded-time`
<re_irc> <@sourcebox:matrix.org> But the point here is, that you need to handle some kind of timestamp and it's a little bit ridiculous that you need a dedicated time library to do it.
<re_irc> <@ryan-summers:matrix.org> Since the whole purpose of those types of crates are to make a **generic** timebase that crates can use without knowing how the underlying system works
<re_irc> <@ryan-summers:matrix.org> Why? That's how it always works
<re_irc> <@ryan-summers:matrix.org> Or you write it yourself
<re_irc> <@ryan-summers:matrix.org> But rust is designed to make libraries small and easy to incorporate
<re_irc> <@ryan-summers:matrix.org> Using a library in rust is infinitely simpler than e.g. in C
<re_irc> <@sourcebox:matrix.org> Generally I expect it to be part of the HAL. At least the simple stuff.
<re_irc> <@sourcebox:matrix.org> All C HALs from ST provide the tick function.
<re_irc> <@firefrommoonlight:matrix.org> I buy it. I've been cracking that nut on switching between STM32 and nRF projects by using a common API
<re_irc> <@firefrommoonlight:matrix.org> Eg that `timer.set_period(0.3).ok();` I posted earlier works the same in either
<re_irc> <@ryan-summers:matrix.org> I don't think we should be looking to those as the beacon of soundness
<re_irc> <@sourcebox:matrix.org> Arduino provides millis() and micros().
<re_irc> <@ryan-summers:matrix.org> Nor do I think we should look at Arduino as the "right" way
<re_irc> <@sourcebox:matrix.org> Of course not, but something like this is so common.
<re_irc> <@ryan-summers:matrix.org> But they're fundamentally different things
<re_irc> <@korken89:matrix.org> burrbull:matrix.org: Not yet, but should not be a problem to add I think.
<re_irc> <@ryan-summers:matrix.org> An ST-HAL tick is (i presume) to drive some RTOS-based, system level timer. They define how you're using their architecture and make a lot of assumptions
<re_irc> <@ryan-summers:matrix.org> Same with Arduino. The `millis()` and friends are implying busywait loops, which again are infeasible in most real apps
<re_irc> <@ryan-summers:matrix.org> We're trying to provide generic, assumption-free implementations
<re_irc> <@sourcebox:matrix.org> millis() just return a value, no blocking.
<re_irc> <@ryan-summers:matrix.org> But implies there
<re_irc> <@sourcebox:matrix.org> Why?
<re_irc> <@ryan-summers:matrix.org> How else do you get the current wall time?
<re_irc> <@sourcebox:matrix.org> Yes, some source of time is implied.
<re_irc> <@ryan-summers:matrix.org> Not all systems have a reliable way of tracking wall time
fabic has quit [Ping timeout: 258 seconds]
<re_irc> <@ryan-summers:matrix.org> Micro clocks have drift, overflow, etc.
<re_irc> <@firefrommoonlight:matrix.org> Re Duration <->Rate:
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> timer.set_period(2.).ok();
<re_irc> <@firefrommoonlight:matrix.org> timer.set_freq(0.5).ok();
<re_irc> <@ryan-summers:matrix.org> And then you have to dedicate a timer to doing that
<re_irc> <@ryan-summers:matrix.org> Which steals a hardware peripheral from your users
<re_irc> <@sourcebox:matrix.org> If you you need something really precise, then it's up to you as the app developer to ensure that.
<re_irc> <@firefrommoonlight:matrix.org> STM32 HRTIM is good for that
<re_irc> <@ryan-summers:matrix.org> But this is the whole point of things like embedded-time
<re_irc> <@ryan-summers:matrix.org> It allows the app to determine what drives the wall clock
<re_irc> <@ryan-summers:matrix.org> Without making any assumptions for the user
<re_irc> <@firefrommoonlight:matrix.org> Hot take: Rust is awesome for embedded and we don't need to worry so much about making everything generic
<re_irc> <@ryan-summers:matrix.org> The only times I care about making things generic is when I need to use the same code for two different platforms
<re_irc> <@firefrommoonlight:matrix.org> You can crack that nut by standardizing APIs
<re_irc> <@ryan-summers:matrix.org> E.g. that MQTT library is going to be on 3(?) different hardwares
<re_irc> <@firefrommoonlight:matrix.org> Eg that timer code I posetd above works on most STM32s and all nRF52s!
<re_irc> <@firefrommoonlight:matrix.org> (Granted, maybe your approach is better than standardizing APIs)
<re_irc> <@sourcebox:matrix.org> Maybe it should be decided at some point if embedded-hal will provide time-related traits or leave it to some other crate.
<re_irc> <@sourcebox:matrix.org> That would make things clearer because now my impression is, these traits should be provided, but noone knows how they should look like.
<re_irc> <@ryan-summers:matrix.org> It has a few already btw, but people have so far found them insufficient imo
<re_irc> <@ryan-summers:matrix.org> or maybe Im thinking of `Delay`?
<re_irc> <@sourcebox:matrix.org> So either address that problem seriously or drop them would be my suggestion.
cr1901 has quit [Quit: Leaving.]
cr1901 has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <@sourcebox:matrix.org> If embedded-hal does not define the traits, then other crates will do it. This is fine until the point where you develop an application that uses driver crates and each of this crates uses a different time library. But all these libraries need a implementation of their traits and that's usually up to you.
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
Ekho has quit [*.net *.split]
Ekho- has joined #rust-embedded
Ekho- is now known as Ekho
<re_irc> <@jkelleyrtp:matrix.org> Does anyone recommend a gyro + magnetometer that's 1) in stock 2) has a rust driver and 3) is decently priced?
<re_irc> <@firefrommoonlight:matrix.org> #2 will significantly limit your options
<re_irc> <@firefrommoonlight:matrix.org> And won't save you much work. I recommend dropping it from your requirements
fabic has quit [Ping timeout: 245 seconds]
<re_irc> <@jkelleyrtp:matrix.org> firefrommoonlight:matrix.org: Sure, I can always implement the gyro/mag traits manually. Do you have any recommended gyros / mags that's 1 and 3?
<re_irc> <@davarice:matrix.org> having some trouble with `/dev/gpiomem`; relevant code:```rust
<re_irc> <@davarice:matrix.org> unsafe fn transfer_bytes(
<re_irc> <@davarice:matrix.org> // ...
<re_irc> <@davarice:matrix.org> gpio: *mut u32, // Address of `/dev/gpiomem` in mapped memory.
<re_irc> <@davarice:matrix.org> ew sorry, how do i format a codeblock?
<re_irc> <@davarice:matrix.org> there
ni has quit [Quit: WeeChat 2.8]
<re_irc> <@firefrommoonlight:matrix.org> No
<re_irc> <@firefrommoonlight:matrix.org> *to jkelleyrtp
ni has joined #rust-embedded
ni has quit [Quit: WeeChat 3.0]
<re_irc> <@davarice:matrix.org> agghhhhh i got it; i always forget that `offset()` is multiplied by the size of the referent type
<re_irc> <@davarice:matrix.org> fixed by `0x1C` -> `0x1C / 4`
<re_irc> <@chmanie:matrix.org> I'm looking for pointers on binary files. I'm properly confused about what I end up with after compiling (in target/thumbv7em-none-eabixx). `cargo size` reports roughly 11kb whereas the compiled file is 1.2M big. What are the steps that are magically taken for me to make it smaller? Just some reading material regarding this would be super helpful, as I'm not sure how to actually search for this.
ni has joined #rust-embedded
<re_irc> <@sourcebox:matrix.org> The ELF file is 1.2M?
<re_irc> <@sourcebox:matrix.org> That could be the case because of debug information.
<re_irc> <@sourcebox:matrix.org> But the debug information is not going to the chip, so don't worry.
<re_irc> <@chmanie:matrix.org> Ah so that's the ELF file
<re_irc> <@sourcebox:matrix.org> The ELF file contains a lot of stuff that is not flashed.
<re_irc> <@chmanie:matrix.org> Hm. I tried to convert it using arm-none-eabi-objcopy but it's basically still 1.2M
<re_irc> <@torne:matrix.org> that will depend exactly what you tell objcopy to do
<re_irc> <@sourcebox:matrix.org> Convert it to what format?
<re_irc> <@chmanie:matrix.org> Oh no, alright, this works: `arm-none-eabi-objcopy -O binary blinky blinky.bin`. I end up with the file size I expected
<re_irc> <@chmanie:matrix.org> Thanks both, it's time for me to do a bit man reading on this :)
<re_irc> <@torne:matrix.org> if you run `readelf -l <elf file>` you will get a dump of the "program header" which describe which parts of the binary will actually be loaded to memory
<re_irc> <@torne:matrix.org> when you objcopy to `binary` you're basically doing this loading and dumping the result to a file
<re_irc> <@chmanie:matrix.org> Thank you, that's helpful
<re_irc> <@torne:matrix.org> for systems that actually use ELF binaries directly (like Linux) this is the same data the kernel or dynamic linker will use to work out how to load the program; for embedded you are just usually doing this work at build time with objcopy instead of at runtime
<re_irc> <@torne:matrix.org> though some more complex embedded devices have their own mini binary formats that their bootloader understands so that you can do things like have data/code loaded into different regions of RAM
<re_irc> <@torne:matrix.org> generally not ELF though as even with all the unnecessary info stripped ELF is quite complex and large
<re_irc> <@henrikssn:matrix.org> torne:matrix.org: What about a runnable 45 byte ELF binary? :D https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
<re_irc> <@henrikssn:matrix.org> Yeah I know it isn't following the standard, but still
<re_irc> <@torne:matrix.org> yeah that's carefully crafted around exactly what the linux kernel happens to accept in practise, which isn't likely to work with an embedded device bootloader even if it understands ELF :)
<re_irc> <@torne:matrix.org> and definitely isn't going to be what you get by running `strip`
<re_irc> <@torne:matrix.org> also 45 bytes is still pretty huge given that the code is only 7 bytes of that
<re_irc> <@torne:matrix.org> 542% overhead :)
Foxyloxy_ has quit [Quit: Textual IRC Client: www.textualapp.com]
Foxyloxy has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent is now known as Guest4985
emerent_ is now known as emerent
Guest4985 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
<re_irc> <@firefrommoonlight:matrix.org> Are there any tricks to preventing the compiler from optimizing out or w/e `static mut` vars? eg:
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> unsafe {
<re_irc> <@firefrommoonlight:matrix.org> defmt::info!("If we comment this out, the playback doesn't work {}", &OUT_BUF[..100]);
<re_irc> <@firefrommoonlight:matrix.org> }
<re_irc> <@firefrommoonlight:matrix.org> I tried compiler fences around the DMA write op that uses this buffer.