Adds in my alternate storage traits #8
Conversation
|
There was relevant discussion about this at: rust-embedded/embedded-hal#241 |
MathiasKoch
changed the title
| type Error; | ||
|
|
||
| /// Returns the start address of the device | ||
| fn try_start_address(&mut self) -> nb::Result<Address<U>, Self::Error>; |
There was a problem hiding this comment.
I don't know if it is a good idea to make these fallible. This will complicate the usage a lot. The same goes for try_total_size and try_page_size.
| /// | ||
| /// For Flash storage, the write functions can't set a bit to 1. | ||
| /// | ||
| /// For non flash devices, this trait is not required, but it can be used to erase data as recommended by the device (EG set all fields to 0). |
There was a problem hiding this comment.
If the behavior of these functions is device dependent, this trait is not really useful for generic drivers, because the driver has no way of knowing what the ErasePage trait will do. By driver I mean a file system implementation for example. That's why I proposed distinct traits for different kinds of storage with well defined behavior.
| /// intended to be used for when there is a optimized method of reading multiple bytes. | ||
| /// | ||
| /// Iterating over the slice is a valid method to ```impl``` this trait. | ||
| pub trait MultiWrite<Word, U> { |
There was a problem hiding this comment.
What is the expected behavior of write? ANDed like flash, always as is or device specific?
| } | ||
|
|
||
| /// Page represents an unsigned integer that is a Page ID in the device memory space. | ||
| pub struct Page<U>(pub U); |
There was a problem hiding this comment.
What do you mean by "Page"? For NOR flashes this is typically the maximum number of bytes you can write in one go. Since you used it further down in try_erase_page I suspect you mean the minimum erase size of the device. For NOR flashes this is typically a block. I thought about having something like that too, but erase sizes in flashes can be quite complicated, so I didn't know how to model that.
|
Your approach is a little bit more granular. That might be useful for read only storage for example. My biggest concern is that this crate should clearly separate device or technology dependent behavior from a transparent/abstract storage that Just Works™. Otherwise it is not possible to write generic efficient file systems optimized for specific technologies like flash. |
|
Will close this, as I think we have reached a concensus around traits in #12 |
Closes #28
These are a set of traits that can be used for on and off board storage.
Each function is split into its own trait to deal with the different types of memory (Particularly Read Only vs Read/Write)
MCU Flash impl:
https://github.com/tl8roy/alt-stm32f30x-hal/blob/master/src/storage.rs
I2C EEPROM impl:
https://github.com/tl8roy/eeprom24x-rs/blob/master/src/eeprom24x.rs
SPI PSRAM implementation:
https://github.com/tl8roy/esp_psram
This is a completely new implementation using SPI.