dmx_receive with DMX_TIMEOUT_TICK of 0 results in many missed updates

[adampulley]

The documentation says I can use a DMX_TIMEOUT_TICK value of 0 to stop the call holding (my ESP-IDF application is a simple main loop application with no hold states or threading). When I do though I see dmx_receive() retuun a non zero value (packet received) only very occasionally (<2 a second). If I set DMX_TIMEOUT_TICK to 1 I get normal fast update reponse, but my application gets stalled which I don't want. I'm testing with a DMX transmitter that transmits at the fastest rate possible.

[adampulley]

Looking through the driver I think the documentation is misleading in that if dmx_receive_num() isn't holding at: const bool notified = xTaskNotifyWait(0, -1, (uint32_t *)&err, wait_ticks);

Then driver->task_waiting = NULL; which means the main application won't get notified that a new packet has been received. Presumably, this means the driver must be used with a task that holds for the dmx_receive() otherwise it will be luck if it happens to be in it when a new packet is received and xTaskNotifyFromISR(driver->task_waiting,.... in uart.c gets called?

Shouldn't the documentation be updated to make that clear and the "If non-blocking behavior is desired, users should set this value to 0." removed (as setting to 0 means you won't get received packets except in extremely lucky moments?