eldruin / eeprom24x-rs Goto Github PK

IIUC, current implementation assumes that memory address consists of two bytes. In other words, three consequent address bytes should be sent for each operation: DEV_ADDR, MEM_ADDR_HI, MEM_ADDR_LOW.

However it looks like this is the case only for at24c32 and higher. For at24c16 and lower devices high memory address is passed as a part of DEV_ADDR.

There are further ICs that would be supported by this crate. The differences are mostly just the page size. See here.
Because of #2 I would like to wait with adding support for further ICs because it creates even more duplicated code.
Nevertheless, if you need support for a specific compatible IC, post a comment in this issue and I will add support for it and release a new version of the crate.

As suggested here, the page sizes could be defined by implementations of a PageSize trait for the different ICs.

However, implementing this would not compile at the moment.
This is blocked by upstream issue rust-lang/rust#42863

Hey, thanks for the great library! Quick question - is there support yet for the 24CSx parts (the ones with baked in unique IDs)? I'm working specifically with the AT24CSW010. If not, would you be interested in a PR?

Hey! I was just perusing the code base here and was wondering why there are different chips implemented.

I see write_page(&mut self, address: &[u8; 2], data: &[u8]) -> Result<(), Error<E>> re-implemented quite a bit for example.

Is there a reason for that? Can I help simplify it somehow?

Waiting on japaric/stm32f30x-hal#27

Hello, how is it planned to access multiple eeproms on the same I2C bus?

Consider the following code:

let mut eeprom1 = Eeprom24x::new_24x32(i2c2, SlaveAddr::Alternative(false, false, false));
let mut eeprom2 = Eeprom24x::new_24x32(i2c2, SlaveAddr::Alternative(true, false, false));

Each line is valid and the code (write / read) works fine. However, since eeprom1 takes ownership of i2c2, it is then no longer usable for eeprom2. Shouln't you avoid taking ownership of the bus ?

Devices for which the addressing is incorrect in version 0.2.0 should be removed.

It would be good if the methods would check if the address would refer to a memory position that is not within the capacity of the device.