alex[m]1 has quit [Quit: Idle timeout reached: 172800s]
tschundler has quit [Ping timeout: 276 seconds]
tschundler has joined #rust-embedded
igiona[m] has quit [Quit: Idle timeout reached: 172800s]
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
nickez[m] has joined #rust-embedded
<nickez[m]>
Hi everyone! I read that static muts are being removed from the language. What is the best way to store global mutable state? static UnsafeCell? I'm developing an SDK and getting callbacks for various events. I need to keep some state between the callbacks.
<nickez[m]>
* Hi everyone! I read that static muts are being removed from the language. What is the best way to store global mutable state? static UnsafeCell? I'm developing against an SDK and getting callbacks for various events. I need to keep some state between the callbacks.
<nickez[m]>
* Hi everyone! I read that static muts are being removed from the language. What is the best way to store global mutable state? static UnsafeCell? I'm developing against a c-based SDK and getting callbacks for various events. I need to keep some state between the callbacks.
<nickez[m]>
Thanks! I'll take a look, haven't seen that crate before
<nickez[m]>
<diondokter[m]> "Mostly the GroundedCell" <- Do you usually build some sort of abstraction on top of that, or just use raw pointers everywhere?
<diondokter[m]>
Build something on top. You don't want to deal with raw pointers everywhere
<diondokter[m]>
But if that's your goal, you might want to look at static-cell which does this for you and doesn't require you to write unsafe
<nickez[m]>
I'm not sure what my "goal" is yet. I want to use rust, and I want to be able to write somewhat safe and idiomatic code. static-cell seems much better documented than grounded.
<JamesMunns[m]>
(author of grounded): If static-cell works for your needs you should definitely use that!
<nickez[m]>
static-cell doesn't seem to solve my use case, since I need to "put the state back" somehow when I'm done with it in the callback
<nickez[m]>
Hmm, do you mean that I cannot execute `&mut *STATE.get()` in every invocation of the callback?
<diondokter[m]>
nickez[m]: Only if it's absolutely guaranteed that only one thing at a time can do this.
<diondokter[m]>
So usually behind a mutex
<nickez[m]>
there is only one thread and interrupts will not call this handler. So do I need a mutex?
<diondokter[m]>
This also includes interrupts!
<diondokter[m]>
Interrupts are the same threads in the regard
<diondokter[m]>
nickez[m]: No
<nickez[m]>
goody, then I'll use grounded for now
<diondokter[m]>
* the same as threads in
<diondokter[m]>
* This also includes interrupts!
<diondokter[m]>
Interrupts are the same as threads in this regard
<nickez[m]>
James Munns: Sorry for complaining. But the front page of the `grounded` docs didn't include any examples. So for a newbie like me it wasn't clear how it would solve my problems.
<JamesMunns[m]>
yep, happy to answer any questions, it definitely needs more docs!
<JamesMunns[m]>
It's basically a "building block" for people building unsafe data structures, it would be good to know what kind of behavior you are trying to build
<nickez[m]>
I think step one could be to just mention GroundedCell on the front page.
<nickez[m]>
I'm using static mut to keep global state between invocations of the same callback handler. And static muts are going away from the language. That is my "problem".
<nickez[m]>
* I'm using static mut to keep global state between invocations of the same callback handler. And static muts are going away from the language. That is my "problem" that I'm trying to abstract around.
<nickez[m]>
I feels like that should be a common use case in the "use a little rust with your C" section in the embedded book.
<nickez[m]>
s/feels/feel/
<diondokter[m]>
nickez[m]: You could also consider using the embassy thread-mode mutex.
<diondokter[m]>
It makes sure you're only locking it from thread mode giving guarantees about the behavior making all use of it safe
<diondokter[m]>
It's not even really a mutex
<nickez[m]>
perhaps there is some way to compose the SDK with something like Embassy so that I can keep the state in async functions. But that seems like a far to big project for now
<nickez[m]>
So that all the callbacks form the SDK just awake some waker in some async runtime
<JamesMunns[m]>
> The functionality implemented today is behind a flag called -Z build-std. This flag indicates that Cargo should compile the standard library from source code using the same profile as the main build itself.
<JamesMunns[m]>
flippette[m]: I don't see anything, did you forget to paste the link?
<flippette[m]>
JamesMunns[m]: the network where i am is kind of terrible
<JamesMunns[m]>
> section `.data' is not within region `data'
<JamesMunns[m]>
These errors are typical when you have overflowed the available RAM (too many statics or constant values) or FLASH (too much code)
<JamesMunns[m]>
The other error is weird (missing memcmp), but at that point it could be just that linking has totally failed and run out of space so symbols were dropped? not sure.
chrysn[m] has joined #rust-embedded
<chrysn[m]>
I haven't managed to spot almost anyone I know from here at EuroRust -- did I miss the secret cabal room?
<diondokter[m]>
chrysn[m]: Ha, well my colleague tamme is around somewhere!
<chrysn[m]>
yes, he's the "almost" :-)
<diondokter[m]>
Ah haha
<JamesMunns[m]>
JP and Amos (fasterthanlime) are there AFAIK
<thejpster[m]>
I haven’t seen Amos.
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
okhsunrog[m] has joined #rust-embedded
<okhsunrog[m]>
can I use cargo embed for RTT with C projects, without Rust?
<okhsunrog[m]>
* can I use cargo-embed (from probe-rs) for RTT with C projects, without Rust?
<JamesMunns[m]>
<okhsunrog[m]> "can I use cargo embed for RTT..." <- As far as I know, yes (plain RTT, not defmt-over-RTT)
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
Koen[m] has quit [Quit: Idle timeout reached: 172800s]
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
<FreeKill[m]>
(it admittedly makes more sense on structs)
<dirbaio[m]>
the compiler is pretty good at propagating constants
<dirbaio[m]>
if you compile with --release and lto=fat etc, if you just make the function take a regular `usize`, and only ever call it with one value, the compielr can propagate that knowledge into the function usually (or even better, inline it)
<dirbaio[m]>
it's not guaranteed, while with your trait Constable it would be guaranteed
<dirbaio[m]>
but still, it works well enough that tricks like these are generally not worth the xomplecity
<dirbaio[m]>
s/xomplecity/complecity/
<dirbaio[m]>
s/xomplecity/complexity/
<FreeKill[m]>
Ok cool!
<FreeKill[m]>
It presumably can't do that with structs, right? It can't decide that some field always has a known value and so choose not to allocate it?
<FreeKill[m]>
Or maybe it can, I guess there's no such thing as a struct at the end of the day as far as the optimiser is concerned
<dirbaio[m]>
it probably can yea
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
d3zd3z[m] has quit [Quit: Idle timeout reached: 172800s]
romancardenas[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<flippette[m]>
<JamesMunns[m]> "not as far as I know! I'm pretty..." <- and i just tested, it does make a difference: putting the section into `.cargo/config.toml` reduces the size by a little bit
<JamesMunns[m]>
The latter could just have more metadata in the elf.
<JamesMunns[m]>
Huh!
<JamesMunns[m]>
Til then, thanks for checking!
<JamesMunns[m]>
The latter could just have more metadata in the elf.
<JamesMunns[m]>
Edit: nope
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
Is anyone here interested/available to do code reviews for my work on adding support for running no-std apps on the Zephyr RTOS? The Zephyr project likes to see two code reviews on each change, and although I didn't have much problem with the initial support, as my code is getting meatier, I'm not finding a lot of people in the project.
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
sajattack[m]1 has joined #rust-embedded
<sajattack[m]1>
adamgreig I'm trying to use spi-flash-rs on AVR and running into some issues because you specify capacity as usize which is 16bit on AVR and I'm trying to work with a 128K spi flash. Any recs?