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.