Hi,

> Today I tried to set up an I2C eeprom for my project, using the driver
> in xpcc. I got the communication working after a while (I think the
> default address it uses, 0xA0 is wrong, as that's an 8 bit address, so
> the correct would be 0x50), but something doesn't work, I think
> probably on the read side, but I'm not sure.

Yes, the address is definitely wrong, if should be 0x50.

> If I store a uint16_t and then read it back (either via the templated
> or the buffer-length way), the high byte (which is the second one in
> memory) is always 0xFF.
> If I lie, and for length I pass 3, the uint16_t will contain the
> correct value. I suspect there might be a small error in the low level
> implementation of the I2C transaction that causes this, but I don't
> know nearly enough to actually verify it. Can somebody take a look at
> this, or tell me if I'm completely wrong? :D

I've looked through the implementation, and there was nothing that caught my 
eye as obviously wrong.
Which specific I2C EEPROM chip do you use?
The driver is kept generic, but was modelled after the 24FC1025.
Acknowledge polling or page write is not implemented!

You can debug the SoftwareI2C driver by adapting these lines:
https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/architecture/platform/driver/i2c/generic/i2c_master_impl.hpp#L17
This will give you a reasonable debug output over serial.

If that fails, I recommend looking at the physical bus with a logic analyzer.

Hope that helps a little,
Niklas
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to