Add support for other compatible ICs

[eldruin]

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.

[RandomInsano]

Yeah, I think this makes sense. To be honest, I’m not sure I would define special structure for this and maybe just pass in the memory size.

Argument for: I don’t need to have an array of every size defined and usually the page size is in the part number.

Argument against: guarantees sizes are followed properly?

[eldruin]

I see that it would be comfortable for this driver not to have to deal with the page size but if the user passes a too big page size, data will be overwritten. Given an EEPROM IC, I would say that is one of the worst things that can happen.
As a user, I would like the driver to prevent me from doing something potentially bad for myself (there might be use cases for this behavior, but in such an unusual case, I expect an advanced user not to be surprised that he would need to talk to the IC directly to do it).

As you said, the page size is something that is immutable for an IC and I would simply expect a driver to abstract me from such a parameter .

[RandomInsano]

Yeah, I think that’s alright. It’s a difference of opinion and what matters is that it exists and is usable by people. :)

[eldruin]

I added support for many other ICs and got rid of the duplicated code via macros.
I published this in release 0.2.0.
However, I will leave this issue open, as I would like to offer a generic API where the user can specify the page size since the device names are not quite consistent. I will probably do this after #5

[eldruin]

All this has been fixed in https://github.com/eldruin/eeprom24x-rs/releases/tag/v0.3.0