jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
d34db33f has quit [Remote host closed the connection]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
Foxyloxy has joined #rust-embedded
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
DavidBrown[m] has joined #rust-embedded
<DavidBrown[m]>
I'm writing up business justification to go to RustConf. Are others looking to attend this year? Also, I'm curious if the UnConf will typically have an additional registration fee, or not.
<diondokter[m]>
If/when I have time I want to test this in sequential-storage to see if it works as well as I think it will
<JamesMunns[m]>
If you want a fun test case, cfg-noodle's traits don't *require* the embedded-storage chain, if you were to make an alt-sequential-storage, you could probably get cfg-noodle working with it pretty quickly :)
<diondokter[m]>
Ha true! :)
<JamesMunns[m]>
also IMO taking u32 instead of usize for indexes is sort of an annoying papercut
<JamesMunns[m]>
tbf, most nor flash is 24-ish bits of addressing space, so maybe u32 is more correct than usize, esp wrt msp430 devices
<JamesMunns[m]>
but it is sort of an annoying thing to always have to as-cast against.
<diondokter[m]>
I... don't know. In sequential-storage internals all addresses are u32
<JamesMunns[m]>
yeah, maybe it's one of those "annoying but actually correct" things
<diondokter[m]>
Making it usize will make it support 4GB+ on 64-bit targets, but <=4GB on 32-bit targets which is a bit weird
<diondokter[m]>
I'm afraid it is
<JamesMunns[m]>
btw, with WriteBehavior/Reliability being constants, does that allow you to bound that in impls?
<diondokter[m]>
Unless we go to u64, but no one uses that in practice and doesn't solve the casting thing
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
I'd gladly award 10000 internet points to whoever comes up with a graceful solution to this. My own custom flash libraries/servers all have the u32 issue.
<jason-kairos[m]>
(u32 wrapper type that lets you .into() from usize?)
<diondokter[m]>
JamesMunns[m]: Kinda. Not yet, but it will in the future. Right now you can make a const fn with an assert that will panic at compile time
<diondokter[m]>
I wish const generics were that far haha
<diondokter[m]>
But at least this is a design that scales into the future
<JamesMunns[m]>
"scales into the future" => "requires currently unstable features to work the way we want it to"? :p
<diondokter[m]>
The current design where you have either MultiWriteNor or normal Nor doesn't allow you to dynamically choose
<diondokter[m]>
JamesMunns[m]: Haha
<diondokter[m]>
No for sequential-storage I can make it work with these constants right now I think
<JamesMunns[m]>
I'm speaking some sass, I don't know a *better* way to express that, honestly.
<diondokter[m]>
But who knows, I really need to try it out to find the flaws of this trait
<JamesMunns[m]>
yeah, the const asserts don't seem like a terrible workaround, imo.
<JamesMunns[m]>
would be good to see how annoying they actually get in practice
<dirbaio[m]>
- WriteBehavior could benefit from a TwiceAnd. nrf52840 and similars are that.
<dirbaio[m]>
- i'm not sure if "InfiniteDirect" is very useful? it means the storage allows writing anything without a need for erase.
<dirbaio[m]>
* - WriteBehavior could benefit from a TwiceAnd. nrf52840 and similars are that.
<dirbaio[m]>
- i'm not sure if "InfiniteDirect" is very useful? it means the storage allows writing anything without a need for erase, if that's actually true a trait that doesn't have an erase() method would be a better fit
<diondokter[m]>
dirbaio[m]: Ah, I was thinking which ones are actually TwiceAnd. Good to know Nordic is
<JamesMunns[m]>
"Reliability" seems like a subjective trap, btw
<diondokter[m]>
And InfiniteDirect is e.g. RAM
<diondokter[m]>
JamesMunns[m]: True... But if I want sequential-storage to be able to insert extra error correction based on the storage, I need some info
<JamesMunns[m]>
like, what do I do differently between "MediumDegrading" vs "Bad"?
<diondokter[m]>
JamesMunns[m]: Hmmmm... Yeah I guess the user would still want to specify what type of error correction to add
<dirbaio[m]>
diondokter[m]: so the goal of the trait is to unify ALL storage? nor flash, nand, emmc, sd, eeprom, ram
<diondokter[m]>
dirbaio[m]: Yes
<diondokter[m]>
I don't know yet if that's a good idea :P
<JamesMunns[m]>
it's a spicy idea, for sure
<diondokter[m]>
But users don't have to accept everything
<JamesMunns[m]>
IMO, focusing on "the kind of memory that requires explicit erases" is probably "more useful" IMO, even if it's not specifically "NOR flash"
<JamesMunns[m]>
like, "I have to erase some data before I can write some data" seems like a reasonable abstraction
<dirbaio[m]>
yeah IMO NOR flash is different enough that unifying is not worth it
<diondokter[m]>
In sequential-storage I could say that I don't support storage that can be written Once for example
<dirbaio[m]>
when writing a db/fs the algorithms you'd use for NOR flash are very different than for sdmmc/eeprom/ram
<diondokter[m]>
JamesMunns[m]: Erase would need to be implemented for all types (even if it's just emulated)
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
JamesMunns[m]: Yeah, I'm suggesting "don't do that".
<diondokter[m]>
The goal is not that this is the main abstraction for e.g. RAM, but that it would at least work
<JamesMunns[m]>
like, if you want to *pretend* that your RAM requires erasing (e.g. for testing), that's fine, but you don't have to make it part of the abstraction.
<JamesMunns[m]>
that being said: I'm 100% of the opinion "if you have the vision, go try it out before letting the haters tell you it's a bad idea"
<JamesMunns[m]>
you'll know if it is/isn't before we do.
<dirbaio[m]>
for NOR you have to organize things in "pages" to ensure good perf by minimizing erases
<dirbaio[m]>
if you have eeprom, ram you don't need the concept of "page" at all, you can just write anything anywhere. If you split things in pages unnecessarily you're wasting space due to padding at the end of pages.
<dirbaio[m]>
sdmmc is InfiniteDirect but WRITE_SIZE=512, that seems a whole other can of worms to optimize for
<JamesMunns[m]>
I 100% agree taking the trait out for a spin w/ s-s + c-noodle will be a very instructive experience.
<diondokter[m]>
JamesMunns[m]: It would impl the trait with the const set to not requiring erase. It would still support 'erasing' though.
<diondokter[m]>
In sequential-storage I could then leave it as is and it'd work. But I could add an optimization with the extra knowledge
<JamesMunns[m]>
sure, but if someone impls the trait as "erase is not needed before write, I won't do that!", but then part of s-s requires that erase happens to invalidate old data, it gets wobbly.
<diondokter[m]>
dirbaio[m]: Yep I agree! It's up to the library to deal with that. It could have 2 backends for example, or assert so only one type type is allowed
<JamesMunns[m]>
IMO: just writing the doc comments of what implementors MUST do and what users MAY expect will be very illuminating as well
<diondokter[m]>
JamesMunns[m]: Definitely!
<diondokter[m]>
* Yep I agree! It's up to the library to deal with that. It could have 2 backends for example, or assert so only one type of storage is allowed
<diondokter[m]>
I get the skepticism haha. I'll just need to prove it (to myself too) that it works :P
<JamesMunns[m]>
like, (IMO) traits are MOST useful when they help people know what TO expect and what NOT to expect. If that gets too broad: it makes the trait less useful.
<dirbaio[m]>
diondokter[m]: yeah but my point is if you're going to have two backends anyway, a unified trait doesn't simplify things.
<dirbaio[m]>
You can have different traits for NorFlash, ByteDevice, BlockDevice and different backends. so the user uses `Db<FlashBackend<hal::Flash>>` or `Db<BlockBackend<hal::Sdmmc>>`
<JamesMunns[m]>
Agreed, answering "when would you WANT to be generic over RAM or NOR flash, without any other semantic changes" is a good question to pose.
<JamesMunns[m]>
and if you'd ALWAYS need different behaviors: you probably want two traits.
<diondokter[m]>
RAM is just a nice extra and not my focus
<diondokter[m]>
NAND, NOR and Block are
<JamesMunns[m]>
diondokter[m]: I worry it's going to be a trap that makes the rest of the design much more complex :D
<JamesMunns[m]>
anyway, excited you're working on it.
<JamesMunns[m]>
embedded-storage is fine, but it did have some papercuts and stacked traits to make things work the way we wanted in cfg-noodle
<diondokter[m]>
Yeah, maybe this will fail. But at least I'll then know this is not the direction to go in.
<diondokter[m]>
Have had this scratch for a year already
<diondokter[m]>
s/scratch/itch/
<JamesMunns[m]>
If it's not clear: hell yeah, I'm glad you're experimenting with it, I'm very interested what the changes to s-s/c-n will look like with this :)
<JamesMunns[m]>
I have *opinions*, sure, but if you're doing the lifting, that's all that matters :D
<dirbaio[m]>
yeah.. we definitely should add WriteBehavior to embedded-storage NorFlash
<dirbaio[m]>
JamesMunns[m]: what papercuts did you run into?
<JamesMunns[m]>
JamesMunns[m]: nothing huge, honestly, since we were mostly bolting on to s-s, so most of the decisions had been made. There's some naming things that are not great (e.g. Pages vs Sectors), and having stacked traits doesn't bring much joy, but I get that's how we've decided to specify "superset" behaviors
<dirbaio[m]>
that's not embedded-storage papercuts tho?
<JamesMunns[m]>
oh?
<dirbaio[m]>
> some naming things that are not great (e.g. Pages vs Sectors)
<dirbaio[m]>
this I agree. "page" is Nordic naming, I only later learned the industry term is "sector" 🤣
<dirbaio[m]>
ah by "stacked traits" you mean MultiwriteNorFlash?
<diondokter[m]>
dirbaio[m]: Me too haha. Sequential-storage calls it pages too
<dirbaio[m]>
JamesMunns[m]: how'd you do it otherwise? it's the only way to do "where F supports multiwrite". You can't do it with associated consts as discussed above
<JamesMunns[m]>
Just because I don't love it, doesn't mean I know a better way to do it :p
<diondokter[m]>
JamesMunns[m]: Also, error has a trait which has a `kind` to get a standard enum error.
<diondokter[m]>
The options are 'out of bounds', 'unaligned' and 'other'.
<diondokter[m]>
I highly doubt if anyone ever actually used that
<JamesMunns[m]>
Like I said, it's fine, it works, it's a bit annoying to wrap your head around the first time but it's not wrong by any means
<JamesMunns[m]>
I do think it's yet to be seen if "const but you have to const assert everywhere instead of a where clause" is actually better
<JamesMunns[m]>
I'm supporting of trying it out tho :p
<dirbaio[m]>
diondokter[m]: "unaligned" and "out of bounds" are the only hardware-independent errors possible. hardware-dependent errors are "other". I agree it's not very useful because db/fs libs that have no bugs shouldn't run into these errors in the first place. I don't think outright removing it is a good idea though
<dirbaio[m]>
it might be useful for other cases. for example if you're writing an RPC for reading memory, you could receive the addr+len from the wire, try the read, then return meaningful error codes for those and "internal error" for other errors
<diondokter[m]>
Yeah, it also doesn't allow you to optimize more. Say you require write Once, but can be more efficient for write Twice. This is really difficult to express. You need to choose beforehand what your generic is and can't check later
sirhcel[m] has quit [Quit: Idle timeout reached: 172800s]
wassasin[m] has joined #rust-embedded
<wassasin[m]>
Btw I am seeing some vendors moving to MRAM for more expensive MCU families as nonvolatile primary memory
<JamesMunns[m]>
it's pretty neat, but yeah easily 10-20x the price
<JamesMunns[m]>
would be very cool to write a rolling FIFO log/defmt buffer library intended for fram/mram tho
<dirbaio[m]>
nrf54 has RRAM
<dirbaio[m]>
it's so faaaaaast <3
DanielakaCyReVol has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
Ugh sorry everyone, there's no way I can make tonight's meeting either, hopefully be able to next week as things have started to calm down...
<JamesMunns[m]>
I can run the meeting today if you need :)
<adamgreig[m]>
If you could that would be great, thanks!
<JamesMunns[m]>
Hello Room! It's about that time!
<JamesMunns[m]>
(my client doesn't do @room, so you all are safe)
<dirbaio[m]>
want me to do @ room ? 😈
<JamesMunns[m]>
Sure!
lethalbit[m] has joined #rust-embedded
<lethalbit[m]>
🐱
<dirbaio[m]>
mwahaha!
<dirbaio[m]>
@room
<JamesMunns[m]>
I think we had some items rolled over from last week, so let's re-use last week's agenda:
<JamesMunns[m]>
fwiw: @Nick Stevens and @ryankurte run those bits
<bartmassey[m]>
That helps.
<JamesMunns[m]>
IIRC, this was because at one time we also had email aliases? However I am unsure if they are still actively used.
<JamesMunns[m]>
We probably could use GH pages (or whatever else), if someone is interested in taking it up as a project.
<bartmassey[m]>
What would the move take?
<JamesMunns[m]>
I'm not sure!
<JamesMunns[m]>
Probably:
<JamesMunns[m]>
* Getting the new hosting set up
<JamesMunns[m]>
* Pointing the DNS to the new location
<bartmassey[m]>
Yeah, that first step sounds easy… I guess we need to get in touch with the principals and ask them for help. Shall I just PM them now?
<JamesMunns[m]>
I guess my question is "why"?
<JamesMunns[m]>
Do we need to publish stuff in particular?
<bartmassey[m]>
Oh, as opposed to just taking it down. Excellent question.
<bartmassey[m]>
I mean the WG needs a website of some kind, I think?
<JamesMunns[m]>
We typically point folks to the wg repo, but I'm not against improving our use of rust-embedded.org
<bartmassey[m]>
Maybe not.
<bartmassey[m]>
Oh, it's just a page pointing at the repo. That's easy to move.
<bartmassey[m]>
Or we could just point the domain at the repo and call it a day.
<sourcebox[m]>
If you take the domain down, there's a 100% chance that it will be re-registered by scammers.
<JamesMunns[m]>
Yeah, right now, SOMEONE has to have it registered, and @Nick Stevens is kindly covering the cost in his other AWS account stuff
<bartmassey[m]>
We wouldn't take the domain name down, for sure. But I don't see any links on that page except to the repo. Moving the docs page doesn't look too challenging either.
jannic[m] has joined #rust-embedded
<jannic[m]>
Domains are cheap enough that I'm sure we get that covered. IMHO a redirect to the repo is enough, but we should not abandon the domain.
<JamesMunns[m]>
Maybe let's open an issue to discuss:
<JamesMunns[m]>
1. what we want to do
<JamesMunns[m]>
2. how we want to do it?
<JamesMunns[m]>
I'd tag Nick and Ryan in that issue, and it would be good to line up what we actually want done before we start moving stuff.
<jannic[m]>
Indeed. It's not like we have to change anything.
<JamesMunns[m]>
Okay!
<JamesMunns[m]>
Any other requests/nominations?
<jannic[m]>
Perhaps Jonathans question re Oxidize?
<JamesMunns[m]>
JamesMunns[m]: I think that's great to track in the same issue!
<jannic[m]>
I do not (yet) plan to be at oxidize, but I could imagine to do so. I surely won't fly to RustConf.
<JamesMunns[m]>
<JamesMunns[m]> "Maybe let's open an issue to..." <- Up to now, it's basically been:
<JamesMunns[m]>
* What do we think is useful
<JamesMunns[m]>
* What was someone willing to volunteer to do
<bartmassey[m]>
I doubt many will come from outside US to RustConf. This is sadly completely reasonable.
<bartmassey[m]>
I would love an excuse to go to Oxidize in Berlin, but that week is jam-packed for me. In the worst case, I'd stop on my way back from China. 😀
<JamesMunns[m]>
I don't see a lot of thumbs up, so maybe if folks ARE planning to go to Oxidize, we can arrange things?
<bartmassey[m]>
I know people hate virtual meetings, but we could plan a Saturday remote meeting at our leisure…
<JamesMunns[m]>
I'm not sure exactly what next steps are, I don't think there's a *need* for an in person meeting
<JamesMunns[m]>
just maybe a "nice to have" if many folks will be there?
<bartmassey[m]>
Yeah, unless folks object let's leave it at "those who are there can meet" for Oxidize and Rustconf.
<jannic[m]>
Anyway it doesn't look like it would be a huge group, so it would probably be possible to arrange something on shorter notice.
<bartmassey[m]>
I think having more frequent face-to-face meetings of some kind would be good, though. Bigger-picture stuff is useful, and maybe best done that way.
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
bartmassey[m]: if done virtual, can we please use Jitsi or similar? really anything that doesn't just feed some AI demon...
<bartmassey[m]>
We can try Jitsi. On a good day it works fine.
<JamesMunns[m]>
Feel free if someone IS going to be at either conference to open a tracking issue or discussion in the /wg space to coordinate :)
<bartmassey[m]>
How do people feel about a virtual meeting in a few months?
<rmsyn[m]>
bartmassey[m]: Matrix also does voice/video calls, so maybe that would work? does it do group calls?
<JamesMunns[m]>
Not against it, but maybe better to work forwards from "why", IMO
<JamesMunns[m]>
bartmassey[m]: not well, in my experience.
<JamesMunns[m]>
Having our meetings in text (GH issues, chat) means we can have logs automatically
<jannic[m]>
I'm already in video conferences most of the day at work so I actually enjoy that this is a chat meeting and not a video conference.
<JamesMunns[m]>
I think sometimes it's easier to speak in person, but IMO without an agenda, it's just a social hour :)
<rmsyn[m]>
JamesMunns[m]: when was the last time you tried? I've been using it more-or-less without issue
<jannic[m]>
A real in-person meeting is something completely different though.
<bartmassey[m]>
It is.
<JamesMunns[m]>
rmsyn[m]: probably more than a year ago
<RyanStreur[m]>
<RyanStreur[m]> "I'm new here, but I would also..." <- The conversation has moved on somewhat, but if nobody objects I'll open this issue in the rust-embedded/wg repo
<rmsyn[m]>
JamesMunns[m]: yeah, I think it's made a lot of progress. try again :)
<JamesMunns[m]>
RyanStreur[m]: Thank you! Maybe check if @bartmassey isn't doing the same :)
<JamesMunns[m]>
Okay, and Bart: I'd say feel free to organize anything you'd like! Just announce it, I don't think you need to ask permission :)
<bartmassey[m]>
I wasn't. Thanks much!
<thejpster[m]>
Sorry, was AFK. Sounds like not much interest in meeting at Oxidize. It’s not really a last minute thing because I need to arrange a space to meet and refreshments and whatever. But there’s still time if you want to set up a hackmd or something where people can register interest. Or, heaven forbid, eventbrite.
<thejpster[m]>
If you promise to play nice, the Ferrous / KDAB offices next to the Brazilian Embassy is an option.
<bartmassey[m]>
I really want some way for Cargo features to depend on the target architecture, and a way to pick the target architecture from Cargo features. I'm not sure exactly what the design would be, which is why I haven't posted anything yet.
<JamesMunns[m]>
bartmassey[m]: Anything that makes sense to discuss here?
<bartmassey[m]>
Only if someone has thoughts.
<RyanStreur[m]>
<RyanStreur[m]> "The conversation has moved on..." <- Absolutely!
<sourcebox[m]>
Different targets for workspace members maybe?
<bartmassey[m]>
Maybe. But I'm working on a crate that needs to be compiled differently depending on the target platform. I think this is common?
<bartmassey[m]>
Right now we've got a crufty barely-solution that is super-fragile and feels bad.
<JamesMunns[m]>
fwiw, the way I'd suggest handling this:
<JamesMunns[m]>
* have a crate for the shared bits with features
<JamesMunns[m]>
* have outer crates for each of your configurations that sets the right features for the shared crate
<JamesMunns[m]>
but I'm sure there a lot of other ways to solve that :D
<bartmassey[m]>
There are a lot of ways to solve it in the existing setup for sure, but I think I'd like some help from Cargo. Anyhow, we should probably move on. Everybody please look at that issue and see if they have things to contribute, though. We won't get things unless we ask for them, and it's good for us if the Project sees us interacting.
<JamesMunns[m]>
Or should we save that for another meeting?
<therealprof[m]>
JamesMunns[m]: What JP said.
<rmsyn[m]>
I think maybe carrying it to the top of next meeting might be good
<rmsyn[m]>
the version-gate makes sense to me fwiw
<therealprof[m]>
Might be annoying to implement though.
<JamesMunns[m]>
Okay! any quick nominations, or shall we wrap up for the day then?
<rmsyn[m]>
definitely, might have to bring in additional dependencies for checking compiler version, think japaric has one
<bartmassey[m]>
There is definitely an inherent conflict between "asking for new embedded features" and "preserving Ferrocene compatibility". Not sure if there's any general way to resolve this. I think it will be case-by-case.
<bartmassey[m]>
I think we're good for today.
<therealprof[m]>
Naked functions have great potential and are way less error prone.
<therealprof[m]>
It would be really weird to not have that less-error-proneness in Ferrocene. 😉
<bartmassey[m]>
Ferrocene is massively hard to update from what I understand, though. Which makes sense.
<therealprof[m]>
bartmassey[m]: Yeah, but maybe they might decide to backport features which help the goal of providing more safety?
<JamesMunns[m]>
They do release quarterly, but folks tend to "lock in" the version they use to keep it constant across a product
<JamesMunns[m]>
Okay, I gotta run here sharp at the top of the hour, so we'll adjourn there, thanks all for participating this week!
<bartmassey[m]>
James Munns: Do they update the compiler version with releases?
<bartmassey[m]>
Thanks for running the meeting!
<JamesMunns[m]>
bartmassey[m]: I'd ask @thejpster, I haven't been involved in quite a while now :)
<therealprof[m]>
People might want to watch out for code gen improvement between 1.87 and the next couple of versions. There have been decent improvements to LLVM codegen, particularly for Cortex-M.
<JamesMunns[m]>
JamesMunns[m]: (also it's very unstable, I don't actually recommend using it for anything serious yet, but I'm serious about working on it :D)
<dirbaio[m]>
jannic[m]: cfg_global_asm emits one single `global_asm!`
<dirbaio[m]>
oh no, but that code has multiple cfg_global_asm!( calls 🤣
<jannic[m]>
I know, and that's how it's used on cortex-m. But riscv-rt does multiple cfg_global_asm! calls.
<dirbaio[m]>
yeah that feels scary
<dirbaio[m]>
fix seems easy, just merge them?
<jannic[m]>
Yes, it looks like a misunderstanding about how cfg_global_asm! is meant to be used. I mean, if you do separate cfg_global_asm! calls anyway, you don't need it, you can put #[cfg] above global_asm! as well.
<jannic[m]>
For some parts of the code it could become quite tedious though, because the cfg conditionals are nested, one cfg on the cfg_global_asm! block that in turn contains some conditionally compiled statements.
<bartmassey[m]>
Maybe could write a macro to merge the blocks?
<jannic[m]>
Everything can be solved with more nested macros, except having too many layers of macros.
<dirbaio[m]>
cfg_global_asm! can probably be adapted to allow nesting...
<jannic[m]>
At the current temperatures my head is unable to fully parse that macro, but the approach looks good.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
is the #[interrupt] attribute compatible with the #[naked] function attribute on cortex-m? I recently had a problem where that would not work on avr-none, where its a bit differet. I had the problem that the compiler was a dummy and created not a very good prologue story, e.g saving all registers where it actually didn't need to, while using trying to use inline asm in the handler.
<vollbrecht[m]>
* is the #\[interrupt\] attribute compatible with the #\[naked\] function attribute on cortex-m? I recently had a problem where that would not work on avr-none, where its a bit differet. I had the problem that the compiler was a dummy and created not a very good prologue story, e.g saving all registers where it actually didn't need to, while trying to use inline asm in the handler.
JonathanKeller[m has joined #rust-embedded
<JonathanKeller[m>
The naked attribute is allowed by the whitelist in the #[interrupt] macro, but I don't think it would compile successfully. The interrupt handler generates a "trampoline" function that delegates to the real function (in order to handle mutable statics), but the #[naked] attribute would be applied to this trampoline which would then fail to compile because the trampoline is written in Rust, not naked_asm.
<JonathanKeller[m>
This could be fixed with logic to skip generating the trampoline function if there are no mutable statics
<dirbaio[m]>
or remove the static mut transform altogether
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
Hi everyone! I ran out of battery and could not join the discussion.
<romancardenas[m]>
I would love a way of letting proc macro crates not which target architecture is being used in the "main" compilation. It would make things way easier.
<romancardenas[m]>
What do you think? Is there something like that already?
<romancardenas[m]>
s/not/know/
<thejpster[m]>
<dirbaio[m]> "or remove the static mut..." <- I am now in this camp. It’s unsound on a multi-core CPU.
<romancardenas[m]>
<jannic[m]> "I know, and that's how it's used..." <- So far, all the code in `asm.rs` is generated in order in the final binary (except section reorderings), but that may change in the future, I guess.
<romancardenas[m]>
Nesting in `cfg_global_asm` would be quite handy to avoid very long `cfg` gates
<jannic[m]>
Yes, there's likely no reason for the compiler to do any reordering here. Like any UB, it may continue to work forever. Until it doesn't.
<jannic[m]>
One problem with making it one single cfg_global_asm! statement is that the amount of generated code quickly grows: With N cfg attributes, it generates 2^N global_asm! blocks. (At least if I understand the macro correctly.) And I count 29 of them. So to avoid compile time explosion, it's probably required to still split it up in multiple blocks. Eg. by splitting it up into multiple functions connected by a jump.
<dirbaio[m]>
I think it doesn't, the branch where the cfg doens't match doesn't get expanded further
<jannic[m]>
Not due to your extension, even the original macro does this.
<dirbaio[m]>
like, if you have `#[cfg(nope)] some_macro!(whatever);`
<dirbaio[m]>
the compiler checks the cfg before expanding
<dirbaio[m]>
* before expanding. it doesn't expand then throw away the result because of the cfg
<dirbaio[m]>
I could be wrong tho
<jannic[m]>
It's more likely that I'm wrong. :-)
<dirbaio[m]>
anyway it's easy to check :D
<jannic[m]>
You are right. It still compiles fast enough that I intentionally added a typo to make sure the assembly is actually being parsed :-)
<diondokter[m]>
<JamesMunns[m]> "They do release quarterly, but..." <- Wouldn't those same people lock their dependencies?
<TomB[m]>
<jannic[m]> "Everything can be solved with..." <- Macros, macros everywhere
sparrowe[m] has joined #rust-embedded
<sparrowe[m]>
Just wondering, where's the best place to get started contributing the open source group?
<dngrs[m]>
do you have anything specific in mind?
<sparrowe[m]>
I'm more so new to Rust in general but Ive done a bit of work on STM32s and ESP32
<dngrs[m]>
I would probably suggest checking the ESP32 repositories for open issues and picking one that suits you. You could also ask in the #esp-rs:matrix.org room if people can give you a list of good starter issues.
<sparrowe[m]>
Thank you !
<dngrs[m]>
yw!
<sparrowe[m]>
One small question, havent used Matrix much but is it essentially one chat per room kinda thing?
<dngrs[m]>
you can have threaded discussions in a room, they're not often used here but over in esp-rs they are
<sparrowe[m]>
lovely ty !
<dngrs[m]>
dngrs[m]: for example like this
<sparrowe[m]>
sparrowe[m]: !!
<dngrs[m]>
sparrowe[m]: 🥳
<dngrs[m]>
dngrs[m]: in the web client there is a thread list icon on the top right, it looks like a speech bubble
<sparrowe[m]>
dngrs[m]: The arch client has the same thing
<sparrowe[m]>
sparrowe[m]: thankfully not much difference