>> 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
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
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
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.
xpcc-dev mailing list