<Ralph[m]>
that way you only have a single build to mark as required and if you add/remove builds (or change the matrix) you don't need to go to the GH settings for this. i've seen various repos use this (i didn't come up with this idea!)
<AlexandrosLiarok>
s/allocates/moves to the bss space/, s/so/So/
<AlexandrosLiarok>
I would at least like to only use the stack if this is prohibitive so that I avoid the 50kb on the bss.
<AlexandrosLiarok>
But it seems this does not play well with embassy due to main residing within a Future and it /seems/ it kind of doubles the stack usage for some reason.
<AlexandrosLiarok>
any ideas?
Makarov has joined #rust-embedded
<AlexandrosLiarok>
I guess I /could/ not use the embassy executor attribute and hand-write my main so that everything is initialized once on the stack and then shared to the main task.
<AlexandrosLiarok>
so I would only pay the price for the stack usage once.
<AlexandrosLiarok>
* usage once and not have the additional bss overhead.
<AlexandrosLiarok>
maybe there is another Cell that helps avoid first copying to stack and then to the cell ?
Makarov has quit [Quit: Ping timeout (120 seconds)]
Makarov has joined #rust-embedded
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
`init_with` optimizing the stack usage or not is a gamble with Rust opt-level settings. It might or might not work. What always works is `StaticCell::uninit` but then you get a piece of `MaybeUninit<your-type>` that you have to manually and unsafely initialize with your type. I've found `pinned-init` very helpful in that particular situation, but then your type needs to have an `Init` constructor function, all the way down to its
<ivmarkov[m]>
contai Ed types.
<ivmarkov[m]>
The other alternative is `StaticCo stCell`, but then you have to wrap your type in (async) mutex. And this type of cell will eath from your flash space.
<AlexandrosLiarok>
hmm this is fine for me I have a ton of flash
<AlexandrosLiarok>
but one issue is that these constructs are split-heavy
<AlexandrosLiarok>
so I can't const-fn them
<ivmarkov[m]>
What?
<ivmarkov[m]>
If you could clarify?
<AlexandrosLiarok>
I think I can allocate these once in an unwrapped main , so they will only eat memory once from the stack section, and remove the static cells entirely so they will be removed from the bss section.
<ivmarkov[m]>
What matter is if you could `const new` "large object", so that you can put it in a `StaticCell<Mutex<RawMutex, "large-object">>`. Once you do mutex::lock.await, you'll get a guard which will allow you to mutate "large-object" and do whatever with it.
<AlexandrosLiarok>
the only downside is not getting good info on a per-object basis in the linker map.
sirhcel[m] has joined #rust-embedded
<sirhcel[m]>
<Ralph[m]> "also: isn't is_sync going..." <- I gave it a try for async-ifying my e-h i2c driver sht4x. But stopped the experiment when realizing that you can have either or. Aren’t feature flags supposed to be “additive”? Havin `is_sync` breaks this for me in the sense that building with `—all-features` only gives a sync version.
<sirhcel[m]>
<danielb[m]> "I don't personally like that it..." <- And there is even `maybe-async-cfg`, which allows to have both variants ant the same time. But i did not manage to convince the macros to finally work with the type parameters of the e-h i2c sensor driver.
cinemaSundays has quit [Quit: Connection closed for inactivity]
<danielb[m]>
> Aren’t feature flags supposed to be “additive”?
<danielb[m]>
That is the intention, but comforming to said intention is unfortunately not a technical requirement.
<ivmarkov[m]>
Maybe now is the time to mention that duplicate + maybe-async was a success for me in that I was abple to implement - without code duplication - a driver that supports both blocking and async i2c...
<ivmarkov[m]>
* Maybe now is the time to mention that duplicate + maybe-async was a success for me in that I was able to implement - without code duplication - a driver that supports both blocking and async i2c...
<ivmarkov[m]>
... but you don't choose. You have both. You just pick one, or the other.
<danielb[m]>
I linked the comment that I remembered showcasing the basics, but I have one question: is that driver a single struct that does both, or two different ones?
<ivmarkov[m]>
It is a single struct when you define the driver, but in the end - after duplicate does its work - it ends up asd two - identically named structs, however in different modules.
<ivmarkov[m]>
* It is a single struct when you define the driver, but in the end - after duplicate does its work - it ends up as two - identically named structs - however in different modules.
<ivmarkov[m]>
Hmmmmm, actually.... I think it would be possible to pull off the struct in an outer module, and end up with a single struct, if - for some reason - you really need that!
<danielb[m]>
i see. I kind of wish for a solution where we'd get both in one, I think there might be some value in it. For example, in applications that can tolerate a bit of startup latency, maybe we could end up with slightly less code generated if driver initialization is done synchronously
<danielb[m]>
it's just a hunch, I have no proof
<danielb[m]>
unfortunately if every driver author decides to do their own thing it matters very little what I wish for :)
<ivmarkov[m]>
<ivmarkov[m]> "Hmmmmm, actually.... I think..." <- Sadly, no. It is NOT possible to pull-out the driver struct out of the duplicated `asynch`/`blocking` modules as a single struct. :( In retrospective, it is obvious why - the async and blocking methods in these two modules have **the same** names, so you end up with duplicate definitions of methods on the _same_ struct.
<ivmarkov[m]>
It might work if you add an extra generic to the struct, something like M where you put in M either Blocking or Async where these two are z-sized types. But... at that point it is a question whether it is the same struct :)
<ivmarkov[m]>
* It might work if you add an extra generic to the struct (typestate basically), something like M where you put in M either Blocking or Async where these two are z-sized types. But... at that point it is a question whether it is the same struct :)
<ivmarkov[m]>
* It might work if you add an extra generic to the struct (typestate basically), something like M where you put in M either Blocking or Async where these two are 0-sized types. But... at that point it is a question whether it is the same struct :)
<danielb[m]>
it's still the same problem; Async and Blocking is better suited for HAL drivers where you actually want that distinction for interrupt handling reasons
<danielb[m]>
for peripheral drivers you still have the name collision problem
<danielb[m]>
different q: has anyone noticed new miscompilations with the 1.82 stable release? we ran into one where the p192 crate just produces zeroes with O3 and fat LTO :(
Makarov has quit [Quit: Ping timeout (120 seconds)]
Makarov has joined #rust-embedded
Makarov has quit [Client Quit]
<danielb[m]>
specifically for riscv32im(a)c-unknown-none-elf
aliceryhl[m] has quit [Quit: Idle timeout reached: 172800s]
<Beregond[m]>
This is only a draft since I only understood how fat32 works inside after few days of tinkering, but I wish to push it further in comming weeks - if you have already any directions/vision how this should work codewise (like with regard to `ShortFileName` - should this stay, or be replaced with lfn struct?) - I'm open to suggestions 🙂
<Beregond[m]>
(BTW nice talk on Euro Rust thejpster 👍️)
gauteh[m] has quit [Quit: Idle timeout reached: 172800s]
RockBoynton[m] has quit [Quit: Idle timeout reached: 172800s]
davidmpye[m] has quit [Quit: Idle timeout reached: 172800s]
exark has quit [Quit: quit]
exark has joined #rust-embedded
ni has joined #rust-embedded
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
huszty[m] has quit [Quit: Idle timeout reached: 172800s]