dmx_receive blocking about esp_dmx

[someweisguy]

Thanks for the code link. It is possible that this is related to interrupts clashing. It should be possible to check this by adjusting the DMX driver interrupt priority. The constant ESP_INTR_FLAG_LEVEL3 should work when installing your DMX driver. In other words, instead of calling dmx_driver_install(dmx_num, DMX_DEFAULT_INTR_FLAGS), try calling dmx_driver_install(dmx_num, ESP_INTR_FLAG_LEVEL3).

You should also check to ensure that your other components are using lower level interrupts.

[someweisguy]

The last argument of dmx_receive() is the maximum block time in FreeRTOS ticks. If you set this argument to 0, the function will not block and will return the number of DMX packet slots received.

dmx_packet_t packet;
if (dmx_receive(DMX_NUM_2, &packet, 0)) {
  // Do work if packet is received
}

As a side note, dmx_receive() will only return the number of slots received for a NEW packet. If you call dmx_receive() again with a block time of zero and before a new packet is received, it will return 0.

This is a relatively new feature so let me know if this is not the behavior you see!

[netmindz]

Thanks for the very prompt response, using 0 does resolve my blocking issue. However, I'm now seeing some rather odd glitches with WLEDs output when DMX is active if I then use that.

Is 0 a magic value to trigger a different behavior?

So with the blocking, all is fine when I have DMX, but no signal blocks my main loop for the timeout.
With no blocking, when no DMX all is fine, but when receiving I get very erratic behavior of the WLED output

[someweisguy]

Setting the block time to 0 should not cause another behavior.

What do you mean by erratic behavior? Do you mind sharing your code?

[netmindz]

The LEDs star showing incorrect values, I wondered if we were seeing clashing interrupts

https://github.com/netmindz/WLED/blob/DMX-Input-esp_dmx/wled00/dmx.cpp

[netmindz]

That seems to be working nicely, thank you