Pico-DMX icon indicating copy to clipboard operation
Pico-DMX copied to clipboard

DmxInput improvement: Trigger the IRQ not based on number of received bytes but on the state of the line

Open kripton opened this issue 2 years ago • 13 comments

As described in #20, some DMX senders might send less than 512 channels. Our current implementation waits for a specific amount of bytes (= DMA transfers) before the IRQ is triggered and the data is assumed to be ready. Since DMX doesn't really define an "end of frame" condition, we could maybe assert one of the PIO_IRQs in the PIO program whenever a break has been detected. This way, the user of the library has the chance to use the data that is already in the buffer up to this point, even if it's not yet the number of bytes expected.

Open for discussion, I'm not sure yet if it makes sense?

kripton avatar Dec 15 '21 20:12 kripton

Makes sense to at least get an interrupt at break so you can error gracefully when getting a truncated packet and looking for a higher channel. Was this resolved?

Gavin-Perry avatar Feb 19 '22 07:02 Gavin-Perry

Yes, indeed, an IRQ on BREAK or MAB would be great. But no, it's not yet implemented and not resolved.

kripton avatar Apr 16 '22 20:04 kripton

I can confirm that many controllers (especially cheaper China consoles) sends less than 512channels. 192 for instance.

Triggering on break is also good for sync of independent receivers, for instance pixels. Lets say you have a RGB pixel, that consumes 3 channels, one patched to start address 1, and one that is patched to start address 508 would have no less than 22ms difference in the received data. 22ms difference can be noticeable. Especially on camera.

e120guru avatar Oct 28 '22 07:10 e120guru