Won't compile for esp32-C3 about esp_dmx

[txbugeater]

The transmitter is now producing the 22.73kHz frequency that I was expecting! Thank you for getting the driver to work with the esp32-3C!

[someweisguy]

Good find. Thanks for opening this issue! You already know this, but for those who may find this issue without having seen the post on Reddit: I'm out of town this weekend and a bit busy the next, but I'll see if I can find time to investigate!

[txbugeater]

I made some progress and am now seeing transitions on the scope when I send DMX data. IDK if it actually works when connected to my dmx board but its a start! I will certainly let you know if it does.

I needed to change the dmx_periph_signal to match the esp32c3 interrupt/io muxes. Here is the esp32c3 reference https://www.espressif.com/sites/default/files/documentation/esp32-c3_technical_reference_manual_en.pdf#iomuxgpio-reg-summ

Below is what I changed for the 2 UARTS on the part. I am currently using UART1 in my test app.

const uart_signal_conn_t dmx_periph_signal[DMX_NUM_MAX] = {
{
.tx_sig = 6,
.rx_sig = 6,
.rts_sig = 7,
.cts_sig = 7,
.irq = 21,
.module = 1,
},
{
.tx_sig = 9,
.rx_sig = 9,
.rts_sig = 10,
.cts_sig = 10,
.irq = 22,
.module = 2,
},

[txbugeater]

While I am getting transitions on the TX line there is clearly still a problem. It does not send a valid packet yet. There is also an issue with running as well. It does not always stay running and it triggers the watchdog due to too tight of a loop somewhere. About 1 out of 5 or so resets of the processor it will not trigger the watchdog and I get continuous traffic on the scope.

[txbugeater]

Made further progress and through some hacking, I believe I have the driver transmitting proper DMX packets. I needed to change the clock to use when setting the baud rate. I ended up using the RTC_CLK_FREQ (20MHz). This produces the same frequency (22.73kHz) when measuring the TX signal. It now matches the ESP32 based board. I also observed that breaks were not being generated by the UART. I have not investigated as to why it is not yet, but as a simple test of this being the problem with sending proper DMX packets, I sent a break in software after a new packet of data was memcpy'd in the interrupt routine (inter_handler.h in the block near line 66 ).

Next step is to test the receive side of the driver.

[someweisguy]

Finally got around to looking at this - thank you so, so much for your patience.

Everything you've said so far makes sense. I've updated the #defines in driver.h here and like you mentioned that seems to make that file happy.

For the issues in hal.h, the code is basically copied verbatim from appropriate files found here. The folders for other ESP32-like devices are here. It sounds like you're already figured this out as well. It looks like the esp32-c3 defines a struct of unique types for each register in the UART, which is annoying. But as long as the UART hardware isn't too drastically different it should be okay to just swap out code for the specific device.

Which brings us to uart_signal_conn_t. I have no idea what these do, except that I know funky things happen if they're not configured correctly. Again, I copied these from the IDF. The ESP32-C3 version of uart_signal_conn_t looks very different than the ESP32 version. It looks like the values you've written in yours agrees with what I'd expect them to be.

I've got a ESP32-C3 coming in the mail, so I am looking forward to hooking mine up to a scope and seeing what happens.

[txbugeater]

I will share my changes (just hacks and not something you would consider checking in) when I get back from my vacation around the 15th if you need them. You might have it all working by the time I get back!

I did test the receiver path and it seems to work with any further changes.

[someweisguy]

I've been looking at a lot of code, but not writing a lot of code. But I've seen some changes in the ESP-IDF that look promising.

When I released esp_dmx v1.1, the first release to support Arduino, the Arduino-ESP32 was based on ESP-IDF v3. Now, the latest version of Arduino-ESP32 is based on ESP-IDF v4.4.1. It looks like ESP-IDF v4 lets you include lots of code in the UART driver code that v3 obfuscated. Because esp_dmx creates its own, custom UART driver having those things be un-obfuscated is very handy.

So I think that there are enough changes here to be a major update. Since a lot of the esp_dmx code is copy/pasted from the ESP-IDF (due to the code obfuscation in ESP-IDF v3), I am going through and seeing what we can delete from the library and instead include straight from ESP-IDF. I'll be pushing these changes to the dev branch. I've also made a dev-c3 branch as well.

[someweisguy]

Well, I kinda-sorta made some progress in the dev branch.

I changed how cmake builds the library. It now includes all files in src/include for end-users to include if they would like. Everything in src/driver is privately included so it can be used within the library, but the user cannot include these files. Then I have a folder called src/esp32 which contains HAL functions for the ESP32. If you want to target the ESP32-C3, you would need to make an identical folder called src/esp32c3 with the appropriate HAL functions.

It looks like this works pretty well, except for in the Arduino IDE. The Arduino IDE has a different build process, which I need to read about and figure out how it works.

[someweisguy]

More progress in the dev branch!

Like I mentioned earlier, one of the handy things about ESP-IDF v4.4 is that there are a lot of new exposed functions that weren't exposed before. So instead of using CMake to conditionally build the library which, to my knowledge, isn't supported in the Arduino IDE, I'm using those newly exposed functions.

These functions are in the UART HAL. These functions aren't public API and are subject to change at any point. But these functions are conditionally built depending on your hardware target in the Arduino IDE. I've wrapped the ESP-IDF UART HAL functions in this library's HAL function to make updates easier when the IDF HAL functions inevitably change.

There are only 4 HAL functions that this library needs that don't exist in the ESP-IDF. I'm thinking it should be trivial to implement those per hardware target using preprocessor defines and ifdefs.

The dev branch is compiling for ESP32-C3. Writing almost works, but it looks like for some reason it's only writing a frame of DMX every 1.2 seconds instead of continuously. Edit: writing looks like it works. I was scoping the wrong pins earlier!

[someweisguy]

The timing tool still won't work, but both reading and writing work on the dev branch. Give it a shot when you are able. :)

[txbugeater]

Great! I will try to get to it this week. I just returned from vacation on Saturday. Dan Sent with [ProtonMail](https://protonmail.com/) secure email.

…

------- Original Message -------

On Sunday, May 15th, 2022 at 7:20 PM, Mitch Weisbrod ***@***.***> wrote: The timing tool still won't work, but both reading and writing work on the dev branch. Give it a shot when you are able. :) — Reply to this email directly, [view it on GitHub](#17 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AVGKTQNL6BO5WBYBZHPMP6LVKGIE5ANCNFSM5UCLAKGQ). You are receiving this because you authored the thread.Message ID: ***@***.***>

[txbugeater]

I finally got around to trying the dev version and I am happy to report that it works as advertised! No issues with compiling or running. I ran my simple transmit and receiver test without error. One observation is that the pulse frequency is a lower now. I am measuring 19.23kHz on the scope. My DMX receiver still accepts it and is able to decode the values.

[someweisguy]

Woohoo! Great to hear!

The UART hardware on the ESP32 and the ESP32-C3 are a bit different; on the ESP32 you can select one of two clock sources for the UART but on the C3 you can select one of three clock sources. I am guessing that is where the low pulse frequency is coming from. I'll see what we can do about that.

[someweisguy]

I found the reason for the discrepancy between the ESP32 and ESP32-C3 UART speeds. If you read section 24.4.5.2 in the ESP32-C3 Technical Reference Manual, you'll see that setting the UART mode to UART_MODE_RS845_HALF_DUPLEX sets the bits for UART_DL0_EN and UART_DL1_EN which causes the UART to delay for two bits after each byte is transmitted.

Wow - I've learned something very interesting about the UART hardware in the ESP32. When you set your UART to transmit two stop bits on the ESP32, the following code gets called:

esp_dmx/src/dmx/hal.h

Lines 201 to 203 in fdd9082

	// set 2 stop bits - enable rs485 mode as hardware workaround
	dev->rs485_conf.dl1_en = 0x1;
	dev->conf0.stop_bit_num = 0x1;

It seems that the ESP32 UART hardware was not designed to transmit more than one and a half stop bits. But by using this hardware workaround to delay each byte by an additional bit-length, it APPEARS that the UART is sending an additional stop bit. Fascinating design flaw in the ESP32.

In any case, in the DMX Standard this inter-byte time is called the “MARK” Time Between slots. According to the standard, its minimum length is 0 microseconds and its maximum length is <1 second. So as you mentioned, even with the extra 2 bits between each byte, it is still valid DMX. Despite this fact, I've added a fix to dmx_hal_init() that will remove the inter-byte time on the ESP32-C3.

[someweisguy]

I haven't done thorough testing, but every library feature should now be supported on ESP32-C3 on the dev branch. Let me know if you find something that still needs attention. Otherwise, once I publish the next release I'll close this.

Thanks!

[txbugeater]

Great news! Glad you found the issue so quickly. I have run into quite a few issues and quirks on chips over the years. Finding workarounds is what I was tasked to do for many years at my previous job/company. You don't always find work-arounds for hardware issues, but amazingly it happens more often than you would think. I will download it and check it out.

[someweisguy]

v2.0 is released and addresses these issues. Thanks so much!