embedded-storage

embedded-storage copied to clipboard

The WRITE_SIZE, ERASE_SIZE etc are usize: https://github.com/rust-embedded-community/embedded-storage/blob/ef207385baa1a7dd34a6778a8bd0238b42f748e9/embedded-storage-async/src/nor_flash.rs#L7

But the addresses are u32:

https://github.com/rust-embedded-community/embedded-storage/blob/ef207385baa1a7dd34a6778a8bd0238b42f748e9/embedded-storage-async/src/nor_flash.rs#L20

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 are usize and we can't change that.

Agreed that this should be unified, but to u32:) There are various 16 bit mcu's with more than 64k flash (e.g. MSP430F5529). They need to be able to address their entire internal flash.

EDIT: After some though I can see why the types are split. WRITE_SIZE is usize because it is guaranteed to represent some size that can always fit in memory, and that probably makes it more correct to have it stay as usize. That is not true for the flash addresses and ERASE_SIZE.

The one that should have its type changed is ReadNorFlash::capacity(). It should return u32.

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.