I tried implementing the new timer method from that documentation link and that is considerably simpler (thanks).
The main issue here is that although I can trigger a block of code to run regularly at 1ms intervals, I cant quite read the sensor in that time (although I certainly should be able to do that)
The timeout errors are a sort of side effect of this fast/intensive reading. I can split this off to another thread, but I think its all related.
Apparently the i2c timeout errors only happen when the display task is run on CORE_0. This has me baffled. This behavior is similar if I am running in a standard task or with the above timer implementations.
Display>>>CORE_0, Sensor/timer>>>CORE_0 ==> timeouts
Display>>>CORE_0, Sensor/timer>>>CORE_1 ==> timeouts
Display>>>CORE_1, Sensor/timer>>>CORE_0 ==> works
Display>>>CORE_1, Sensor/timer>>>CORE_1 ==> works
No errors when only running one or the other. See the table above for more specifics when running both tasks.If you run either one of the two I2C buses only, do you still get timeouts?
Similar issues if I run the tasks without delays (see above). It appears that i2c_master_cmd_begin() allows a task switch, so my sensor loop is basically running as fast as it can:If you run the I2C operations from a normal priority task (ie slower and with less accurate timing), do you still get timeouts?
Code: Select all
while(true) {
value = readSensor(); //read from the I2C device on I2C_NUM_1
}
Code: Select all
void timer_cb(void* arg) {
value = readSensor(); //read from the I2C device on I2C_NUM_1
}
Code: Select all
while(true) {
//This I2C write is generating most of the timeouts, but there are occasional timeouts on the sensor read
UpdateDisplay(value); //write on I2C_NUM_0
vTaskDelay(100 / portTICK_PERIOD_MS);
}
The latest from githubWhat IDF versions are you using?