Taking a semaphore is not guaranteed to succeed

[pimlie]

Calling xSemaphoreTake might not succeed, so it might be best to check the result and only continue when the lock really succeeded.

This would require quite a bit of a rewrite and error handling, but atm all the calls to i2cStart, spiStart and displayStart seem pretty useless as the code continues regardless whether the lock succeeded or not.

// make displayStart return a boolean
#define displayStart() xSemaphoreTake(mutexDisplay, portMAX_DELAY) == pdTRUE

// then check if the lock rly succeeded
if (displayStart()) {
    display.selectDisplayMode(INKPLATE_3BIT); // set grayscale mode
    display.clearDisplay();                   // refresh the display buffer before rendering.
    displayEnd();
} else {
  // log the lock failure and maybe reschedule the current task?
}

[lanrat]

Good find.

While there is definitely a bug here, as long as the calls don't time out and block for the brief moments while the i2c bus is active I've never encountered a problem.

I added i2cStart, spiStart and displayStart because the underlying inkplate library does not have any sort of mutual exclusion for multiple API calls that use the same bus and conflict with each other. Adding these checks resolved the issue for me. Each blocking sequence should always be very short, so I'd imagine its would be incredibly rare for xSemaphoreTake to return false.

Have you observed any problems with the current behavior?