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(sizeof(SETTINGS_VERSION), data));

But this does:
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 :)


2016-05-10 22:56 GMT+02:00 Niklas Hauser <niklas.hau...@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/resumable/macros.hpp#L146-L152
> 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
xpcc-dev mailing list

Reply via email to