-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type of addresses: mix of u32 and usize. #27
Comments
Agreed that this should be unified, but to EDIT: After some though I can see why the types are split. |
The one that should have its type changed is |
Would it make sense to have an associated size type? A hard u32 rules out applying this to large SD cards, but a hard u64 may be unacceptable overhead for other applications. |
large SD cards are not NOR flash though, you don't have to first "erase" a sector to write. You can't write individual words in a sector either. They're best modeled as some "block device" trait where all you do is "read block", "write block". How common is it to have >4GB actual NOR flash devices? |
Right; I was mixing in concerns of #23 which would AIU generalize over flash media -- SD cards behave like what is described there to haven an erase size identical to the write size (thus erasure can be implicit and AND writes are just RMW). As long as we don't do these generalizations, u32 iikely suffices.
|
The WRITE_SIZE, ERASE_SIZE etc are
usize
:embedded-storage/embedded-storage-async/src/nor_flash.rs
Line 7 in ef20738
But the addresses are
u32
:embedded-storage/embedded-storage-async/src/nor_flash.rs
Line 20 in ef20738
This makes doing math on addresses quite annoying: it needs a lot of casts. I sort of lean towards unifying this on
usize
, since slice lengths areusize
and we can't change that.The text was updated successfully, but these errors were encountered: