trinhtuan[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
cr1901_ is now known as cr1901
IlPalazzo-ojiisa has quit [Quit: Leaving.]
slabity[m] has quit [Quit: Idle timeout reached: 172800s]
bomb has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
AlexChen[m] has joined #rust-embedded
<AlexChen[m]>
@alex:slack.com
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
AtleoS has quit [Ping timeout: 256 seconds]
AtleoS has joined #rust-embedded
vancz has quit []
vancz has joined #rust-embedded
<sirhcel[m]>
<MariusKriegerows> "Not sure if it helps but I ran..." <- > <@emrius:matrix.org> Not sure if it helps but I ran into a similar problem once and created a little macro that only compiles a test when a specific environment variable was set. It has limitations. E.g. it does not work with async code and is rather specific to the problem I once had. But if you like give it a try
<sirhcel[m]>
Thank you very much for the pointer! I’ve shot myself in the foot with checking environment variables at compile-time several times. Therefore after sleeping over it, i decided to go for a feature flag which triggers recompilation when changed.
<sirhcel[m]>
I’m also looking at checking for the configuration environment variables at runtime, as this is currently another footgun around.
<sirhcel[m]>
* environment variables for the tests at runtime,
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
badyjoke[m] has joined #rust-embedded
<badyjoke[m]>
Hello ! What is the best way to use FreeRTOS with Rust ?
<xiretza[cis]>
I don't think there are any ways that would qualify as close to "good"
<diondokter[m]>
But also, we have other options in Rust too like RTIC and Embassy. If you don't *really* need FreeRTOS, then I
<diondokter[m]>
Don't know if this one specifically is any good though.
<diondokter[m]>
s/But also, we have other options in Rust too like RTIC and Embassy. If you don't *really* need FreeRTOS, then I/But also, we have other options in Rust too like RTIC and Embassy. If you don't _really_ need FreeRTOS, then I'd pick one of these/
<badyjoke[m]>
* I would like to use Embassy or RTIC but I have to stick to FreeRTOS 😅
<ruabmbua[m]>
I also recommend checking out Lilos as an alternative to embassy. It's much leaner, and makes integrating different libraries way easier.
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<JamesMunns[m]>
Lilos is definitely a neat project, tho I'm interested if you could explain what you mean by "makes integrating different libraries easier"
bomb has quit [Quit: 💣]
<ruabmbua[m]>
I was converting something without any rtos / async to use async tasks.
<ruabmbua[m]>
Tried embassy first, and I quickly spent an hour changing the libraries / the hal I used because embassy brings it's own.
<ruabmbua[m]>
Got annoyed and tried Lilos next, the whole diff after introducing it is literally just a few loc in the main.
<ruabmbua[m]>
I was able to use all the same libraries as before
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
you can use any HAL with embassy-executor
<dirbaio[m]>
you didn't have to change it
<dirbaio[m]>
(and embassy's HALs work on any executor too, including lilos's)
<ruabmbua[m]>
I guess I did not spend enough time with the tutorial and docs then.
<ruabmbua[m]>
In Lilos it was just obvious because of how the example code etc... is steuctures
<ruabmbua[m]>
s/steuctures/structured/
<dirbaio[m]>
yeah, the "recommended default" is to use embassy's hals (because most non-embassy HALs have little/no async support)
<dirbaio[m]>
but you can use any
<ruabmbua[m]>
I am not even using async Hals, I just hooked up the isrs I needed myself.
<ruabmbua[m]>
And then use the non blocking methods if they exist
<ruabmbua[m]>
That's also very obvious on how to do it in Lilos examples
<M762spr[m]>
but I am having some brain fog on a good clean way to handle the sub registers
<M762spr[m]>
how would I have named values for 0x00, 0x04, etc tied to say REG1
bomb has left #rust-embedded [💣]
<M762spr[m]>
I thought maybe make each register a struct but since the amount of registers is variable, I'm not sure how to do that with fixed sizing of everything.
<diondokter[m]>
<M762spr[m]> "I'm looking for ideas/suggestion..." <- > <@762spr:matrix.org> I'm looking for ideas/suggestions on a good way to track registers and sub registers for a driver crate. I would like to be able to use named values and restrict sub register values to their parent register.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/pgVNAfCvdhvIikYOxHgxGDGs>)
<M762spr[m]>
diondokter[m]: > <@diondokter:matrix.org> Are you wanting to build a tool like this, or is it something you're missing?
<M762spr[m]>
trying to implement something myself mostly for learning purposes, so I'm trying to avoid external crates that just kind of do it for me. I want to understand what's happening vs using a "black box"
<diondokter[m]>
Totally fair!
ni has quit [Quit: WeeChat 3.0]
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
diondokter: Are there any examples how to implement the `Key` and `Value` traits on the new `sequential-storage` release?
<diondokter[m]>
I think it's relatively straightforward
<sourcebox[m]>
I just try to figure out how to migrate fro the previous version.
ni has joined #rust-embedded
<sourcebox[m]>
If the key is just an u8, only Value has to be implemented for a struct?
<diondokter[m]>
Yep!
<sourcebox[m]>
But I think it's also possibbe to use a tuple like (u8, u8) for the key if you implement the Key trait.
<diondokter[m]>
And you're now officially allowed to use multiple Value types in the same flash range.
<diondokter[m]>
So if you know that a `12` always stores a `Foo`, then you use `Foo`. For key `13` you can then use value `Bar`
<diondokter[m]>
sourcebox[m]: Indeed
<diondokter[m]>
Actually, now that you made me look, I missed adding an optimization optional function for the key length for the built-in types
<sourcebox[m]>
Yep, I've seen that. Really nice for some preferences I want to store later.
<sourcebox[m]>
Ok, I got it working with u8 as keys. Seems like I can reload items stored with 1.0, so data format has not changed. Is that right?
<diondokter[m]>
<diondokter[m]> "Actually, now that you made me..." <- Ok, well that's 2.0.1 released :D
<diondokter[m]>
sourcebox[m]: Ehh kinda? Depends on how you stored your key.
<diondokter[m]>
It's now `key` then `value`. If your previous implementation was also like that, then yeah, that works
<sourcebox[m]>
Yes, I had it on the first byte.
<diondokter[m]>
The other internals are unchanged
<sourcebox[m]>
Like in your example with 1.0.
<diondokter[m]>
Cool! Then it's an easy upgrade for you ;)
<diondokter[m]>
s/;/:/
<sourcebox[m]>
Yes, but I have to change the keys to a tuple because the current implementaion is a bit hacky.
<diondokter[m]>
Ah, then you won't be able to recover the data
<sourcebox[m]>
No, but that's fine.
<sourcebox[m]>
Question will be: will it return correct data or an error?
<sourcebox[m]>
s/correct/corrupted/
<diondokter[m]>
The data will be seen as correct as far as the crate is concerned. So it will present the data to the key deserializer and the value deserializer
<sourcebox[m]>
So I expect some garbage ;-)
<diondokter[m]>
Yeah probably
<sourcebox[m]>
The data itself is serialized by postcard.
<diondokter[m]>
Someone once suggested we could store the crate version in the page state words. Pretty nice idea actually because it would allow to detect version mismatches
<diondokter[m]>
But it'd lose some bitflip hardening
<diondokter[m]>
Anyways, I need to go to bed. Otherwise I'll be a walking zombie tomorrow at RustNL :P
<diondokter[m]>
But feel free to post more questions! If you tag me I'll see them tomorrow