Data TX & RX from same underlying UART

[second-string]

I have a device that needs two way communication through a standard FTDI usb-serial chip. The data coming into the device through the usb to serial chip is DMX, which I am using esp_dmx to receive to then process and perform actions. I configure the device also through this same interface, using the manufacturer-specific start code (0x91), my own ESTA ID, and then a custom command structure.

I also need to be able to send responses from the device back through the FTDI chip + usb connection. Ideally this would be standard UART with no DMX break/MAB, but I can live with it being DMX-framed as well. I also understand that this is not proper DMX, this breaks the spec having two-way, non-RDM comms. However, I cannot find a way to make this work with the esp_dmx component.

Things that I've tried:

• using dmx_receive/dmx_write functions on the same DMX port number. This does not work after I attempt to transmit a single packet, as the driver->is_controller field gets set in io.c and never reset when trying to rx again. I tracked this down because the rx code spews timeouts after switching back to RX as it assumes it's now RDM
  • I hacked around this by rewriting driver->is_controller = false any time one of the receive functions is called (because I'm not using RDM, and I wanted to verify this worked before coming up with a cleaner solution)
  • this 'works' in the sense that i can go back and forth between tx and rx, but there is weird bleedover between the tx and rx stuff with buffers not getting cleared. After I send a packet, the next time my rx task starts to receive, I receive the same packet I just sent. I've tried a number of fixes like dmx_writeing all 0s after I send my packet, flushing with a dmx_receive to burn the data in the tx task, etc. Nothing works, and as soon as freertos context switches back to the rx task when tx is finished, it receives whatever was last written into the internal dmx data buffer
• disabling or deleting the dmx component, installing my own standard uart driver, sending with that, then deinstalling/reinstalling the other way around.
  • Out of the box this doesn't work, I get E (7938) uart: uart_driver_install(1626): Could not allocate an interrupt for UART when trying to install the uart driver.
  • I'm guessing the intr allocs in IRAM for the esp_dmx component aren't properly released in the dmx_driver_delete function Yeah, adding esp_intr_free(uart->isr_handle); in the uart.c:dmx_uart_deinit function removes this issue
  • So I can get the uart driver installed and configd correctly, but when I call uart_write_bytes it fails with a standard ERROR esp_err_t

I didn't want to spend too much time on this in case you have a more obvious solution that I'm missing, but I can keep debugging. My use-case of sending DMX back out the port isn't abiding by the spec as I've acknowledged, but I think the functionality to properly tear down the DMX use of the uart peripheral for reuse somewhere else should be supported.

Obviously happy to do the work and PR, but I would appreciate your thoughts here as the one with the most context on the code. Thanks!

[second-string]

Classic, figured out the issue ~30 minutes after writing up a whole issue.

In case 1) above, there is no stale data left in the dmx data buffer after TXing. I missed a return statement and so after I blocked receiving for a bit in order to transmit, after unblocking it it was re-processing the earlier command and turning into a never-ending cycle.

This does still require the hack of overwriting driver->is_controller though. So I'm still interested to know if you have a better way to do this, or a different approach.