Hi, I've updated xpcc to include the eeprom fix, and there were still problems, but FINALLY I've got it working. What I'm doing in my code is that I have a "version" constant, which I change when the data structure to be saved changes, so invalid values don't get read. When I read the data structure, first I check this version, and if it matches the compiled-in version then I read the real data. On writing the data I just unconditionally write first the version then the data. The problem was that the second write (which should write the actual data) didn't work, because the first one didn't finish yet. If you read "7.0 ACKNOWLEDGE POLLING" of the data sheet (http://ww1.microchip.com/downloads/en/DeviceDoc/21191s.pdf) it describes a way to poll for readiness of the device. So this doesn't work: RF_CALL_BLOCKING(eeprom.write(0, SETTINGS_VERSION)); RF_CALL_BLOCKING(eeprom.write(sizeof(SETTINGS_VERSION), data)); But this does: RF_CALL_BLOCKING(eeprom.write(0, SETTINGS_VERSION)); while (!RF_CALL_BLOCKING(eeprom.write(0, nullptr, 0))) {} RF_CALL_BLOCKING(eeprom.write(sizeof(SETTINGS_VERSION), data)); This really seems like a hack, so maybe this check should be incorporated into the driver (I might give a shot at implementing it if this is the way to go). I should have probably read the data sheet way earlier. At least I learned something :) Regards, Antal 2016-05-10 22:56 GMT+02:00 Niklas Hauser <niklas.hauser@rwth-aachen.de>:
Hi,
Is that what you are seeing?
It has nothing to do with this, I'm not even close to the page boundaries. I'm trying to write and read the first ~4 bytes. I've tried a million things now without much success. One thing I do which I know I shouldn't is using RF_CALL_BLOCKING everywhere. Could this be the cause?
No, I don't think so. The failure that you describe is so specific, I don't think the RF_CALL_BLOCKING mechanism, which is extremely generic, could have any effect on this. If there were something wrong with that macro, I would expect the entire transfer to fail, not just one byte.
RF_CALL_BLOCKING is a while(1) loop that polls the resumable function _in place_. So no other task will run during that call (except interrupts of course): https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/processing/r...
Note that hardware I2C is interrupt driven, so it will definitely execute during that macro. SoftwareI2cMaster executes completely within the `start` method of I2cMaster, which is called inside the macro (somewhere in the driver) and therefore also executes during that macro.
Using RF_CALL_BLOCKING is fine _both_ inside and outside of a Protothread. But particularly for I2C, which is quite slow compared to the CPU speed, you can use time during the transfer to switch to other protothreads and do other things. Hence the recommendation to call your resumable functions using PT_CALL from inside a Protothread, because it makes it a lot easier to add more tasks in the future and make them execute in parallel.
Cheers, Niklas
_______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev