Serial Monitor output is only the character "null" about esp_dmx

[someweisguy]

The issue was in dmx/driver.h. There was a struct named uart_periph_signal, whose name I copied verbatim from ESP-IDF in order to make the library compatible with Arduino. The Arduino framework hid a lot of useful ESP32 UART constants found in the IDF so I essentially copied them across in order to rewrite as little code as possible. To fix the bug, I renamed uart_periph_signal to dmx_periph_signal. I am guessing there was some sort of name conflict? Really strange.

In any case, I've pushed those changes to the dev branch. If you need to use Arduino-ESP32 v2.0.1, please clone the dev branch to your libraries folder. @quirsh I'm very interested to see if this fixes your problem. Please let me know if you are able to test out the changes!

[quirsh]

Sorry for the long silence, I only came around to revisit my project now.
Thank you so much @someweisguy for your support and fix, I can report it works now flawlessly on my setup as well. Thank you very much!

[someweisguy]

Thanks for the question and the kind words!

On line 43, when you call dmx_param_config(), what is the value of dmxPort? Is it 0, 1, or 2? dmx_param_config() configures the UART hardware for use with DMX. The serial monitor uses UART 0, so if the value of dmxPort is 0, that could cause the issue that you are experiencing.

[quirsh]

I used the default which is 2. I also tried with the two other ports but nothing changed.
I was physically able to verify that the DMX output works and the serial port pin is not influenced by it (continous data stream on DMX pin, interrupted data stream on serial port pin, fits with the incoming charcters).

(PS: Just realized that I gave the wrong line number, it's 54 in the example file, my bad)

[someweisguy]

Thanks for the info. I'm glad to hear that the DMX output is working. I just ran the DMXWrite.ino example on my ESP32 Feather last night and I didn't have any issues, so I'm wondering if you are using a different ESP32 board? Which one are you using?

Can you also share what your platformio.ini file looks like?

[quirsh]

I am using the ESP-WROOM-32 Devkit Board and at least this problem is new to me.

This is my platformio.ini:

[env:esp32dev]
platform = https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream
board = esp32dev
monitor_speed = 115200
framework = arduino
lib_deps = 
	someweisguy/esp_dmx@^1.1.1
	ottowinter/ESPAsyncTCP-esphome@^1.2.3
	ottowinter/ESPAsyncWebServer-esphome@^1.3.0

[someweisguy]

I want to say that this has something to do with how your UART is being configured in PlatformIO, but that doesn't explain why the problem goes away when you get rid of dmx_param_config().

Take a look at this line in esp_dmx.c. It might be worth deleting lines 16 through 26 inclusive and replacing with #define CONSOLE_UART_NUM 0. I think that for some reason, dmx_param_config() is disabling the UART peripheral at this line, causing the null characters.

[quirsh]

The suggested change made the output a bit more diverse but I can't really say if it goes in the right direction. Today I also tried it with an other physical board (same model) to be sure it's not a faulty one.

I might be going in the wrong direction, but is there a way to figure out which datastream is running on which UART port? They aren't hardwired to the physical pins, are they?

Serial output, same options, still the Write example:

e�sZ␘�R␀␀␅␀␀␀␀E␀"␐␀␀␌(␀␂␐&␇j����N�E�␀␆H␀␒␀�␀b␁␀ �Z␂␄␀�␀0␀␀␅␀0␄�␄␀K␀ �!� ␀␀�`��C␞␂␀�␀␁V␀ �␆��␀E␀␀Ԅ␕␂␁␀␀␁␁␀␀ ␌␀␀␀�␀␀Z%�
,␒0␂Ȕ� �v␄␀␀␀␀␀
X1C�2␁�XE0�Qd0␐␀ȓ\␀
?␄␂�␐�␔H␌�␂␀␀␀�␀�␀P�␂   �␁T ␅␀P␀�
␀␃�␎K␑�␀�␀␀@�␁"a�␀�␀�␀<␏␀eN␃␀�␀�Đ2ɤ␕␁�␀]␖Q␒D��␀␑␀␀�␆A    �␁r@␀�
␀␄␀␀␀M␃␀␄␀␂�␎␀@␀␘�␀␅���␆␀d␀␀␂␀␂␁␄t␀␄␀ ␀@@␁␅��ȩ ␀�␀X␀jA␀� ␀ �␀␕␀␁␀␀␀␋␀␀a0z␁6�P:␁��␎␀␀␇␀␀␀␀␆ɖa�T�␄␓�$␀0�␀␀␁�␁␄�␀�␏��␀�␀@␀d␐@␐␁ �␋␀␀␀��␀␀␃op␀�␀␀␆␂␀*�H␀␌␂(␀ 

EDIT: I might later try if I can reproduce the issue with the Arduino IDE...

[someweisguy]

I've tested out a different board. I used an ESP32-DevKitC, which is an ES32-WROVER-E, but that shouldn't make a difference. Same chip with different amount of RAM. I built and uploaded the DMXWrite.ino example file as-is, and I copy/pasted your platformio.ini to mine. I wasn't able to get it to build due to some dependency issues with ottowinter's libraries, but I removed those and it uploaded fine. So I am more or less using the same system you are using, but I am not able to reproduce your error. Grrr....

I am not sure there is great way to see which UARTs are being used for what. UART 0 is used for the serial monitor in all boards that I am aware of. UART 0 is transmitted on GPIO 1 and 3. UART 1 and 2 are free for use for whatever is wanted, and you can assign them to almost any other GPIO on the board. When I had you replace those lines with #define CONSOLE_UART_NUM 0, my intention was to test to see whether or not we were clobbering your serial monitor on UART 0 by accidentally setting it to DMX speeds. I feel pretty confident that isn't what is happening here, but when you think about what dmx_param_config() does, it is hard to imagine what else is going on.

Here's what dmx_param_config() in esp_dmx.c does:

1. First, we do some error checking to make sure that the user didn't pass arguments that don't make sense.
2. Next, we enable the UART peripheral. If the UART selected is not the serial monitor, we reset the peripheral first. I said that it disables the UART in an earlier comment, but I linked you the wrong line. Sorry! It actually enables the UART.
3. Then we configure the UART hardware to use the correct data bits, parity, stop bits, etc. We also set break and MAB times.
4. Finally, we flush the UART hardware FIFOs so that we don't process any garbage data that may be in them.

I'm going to keep chugging along on trying to recreate this problem, but I am stumped. You might try commenting out each of those sections individually and find out which fixes your serial problems. This would break the DMX, but it would at least give us a broad idea of what the issue is here.

Definitely let me know if you have issues on Arduino IDE! Good thinking!

[quirsh]

Definitely let me know if you have issues on Arduino IDE!

After some hassle getting ArduinoIDE to compile and upload sketches to ESP32 I was able to push the Write Example to my board and the serial monitor worked flawlessly. Not sure if this it good or bad :D

I will continue testing your proposed changes in VSCodium/PlatformIO as I don't want to change back to ArduinoIDE ;)

EDIT:

You might try commenting out each of those sections individually and find out which fixes your serial problems.

I tried this but wasn't able to fix the serial, still lots of nulls. To be sure I used a new project with no other dependcies activated and only the example code. I'm feeling a bit stuck with this problem, nethertheless already a huge thanks for your great support!

[someweisguy]

After some hassle getting ArduinoIDE to compile and upload sketches to ESP32 I was able to push the Write Example to my board and the serial monitor worked flawlessly. Not sure if this it good or bad :D

This leads me to believe there is something fishy going on with VSCodium and PlatformIO. I am running VSCode (not Codium) on PlatformIO. I tried to get VSCodium running, but I was not able to get the PIO extension installed on it. On VSCode, I cannot reproduce this error.

Going back to your earlier comment on seeing how each UART is configured, I wrote a little snippet that may help, which you can copy/paste to line 77 in the DMXWrite.ino example. It looks at the registers for the UART port that you specify and returns how each are configured. In this case, it should print 115201, 0, 1, 3 for UART 0 on the serial monitor. Since your serial monitor doesn't work, maybe try lighting up and LED or digitalWrite() a pin on the comment that suggests doing so?

// Change this to select different UART ports
int uart_port = 0;

uint32_t baud;
uart_parity_t parity;
uart_stop_bits_t stop_bits;
uart_word_length_t data_bits;

esp_err_t err = uart_get_baudrate(uart_port, &baud);
err |= uart_get_parity(uart_port, &parity);
err |= uart_get_stop_bits(uart_port, &stop_bits);
err |= uart_get_word_length(uart_port, &data_bits);

if (!err) {
  Serial.printf("%i, %i, %i, %i \n", baud, parity, stop_bits, data_bits);
  if ((baud >= 109440 && baud <= 120960) && parity == 0 && stop_bits == 1 && data_bits == 3) {
    // do something here? maybe light up an LED?
  }
}

If you can get this code to light up an LED for UART 0, this would confirm that the issue is with VSCodium/PlatformIO and not the code. An ESP-PROG would be a better idea for troubleshooting this, but that is a whole other can of worms.

[quirsh]

I tried to get VSCodium running, but I was not able to get the PIO extension installed on it.

Yes, I remember this problem. It's because PIO is not listed in the open-vsx marketplace for some reason, but you can manually add the MS market place as the resource for Codium (see here, no guarantee its still working).

EDIT: I used VSCODE and PIO and had the same problem. Now currently wondering if I did some stupid config to my machine...

I inserted your snippet and used the inbuilt LED as an indicator as proposed. The condition became true so I think the serial monitor of PIO is the culprit. I noticed that the serial monitor says something like /dev/ttyUSB0 115200,8,N,1. As you might have already recognized I'm quite a noob with lot of those internal working of the µC but if I get it right the serial monitor expects 8 data bits while we ask in the if condition if data_bits == 3. Might this be the problem?
3 data bits sounds strange to me and I wasn't able to find a way to change it in the serial monitor (only options are 7 or 8 data bits). Am I offtrack?

[someweisguy]

Thanks for the information about VSCodium and PIO - I will take a look!

Back to the problem at hand though: data_bits == 3 is correct. On the ESP32, the number of data bits is is equal to data_bits + 5. So that would mean that you are transmitting 8-bit words, which is what we want. The data-bit/word-length constants for ESP32 can be found here if you are interested.

Seeing 115200,8,N,1 is also what we want to see. It indicates that your PIO serial monitor is 115200 baud with 8 data bits, N for no parity, and 1 stop bit. /dev/ttyUSB0 is the device that PIO is monitoring, which may not necessarily be accurate. Could you check to see what port you upload code to? An easy way to do this is to open the Arduino IDE and go to Tools->Port and see which option is selected. It may be something like /dev/cu.SLAB_USBtoUART.

EDIT: I'm still trying to replicate this error. Are you using Mac or Linux?

[quirsh]

Sorry for the late answer, didn't saw your edit in time.

I'm using Linux, Ubuntu 20.04

For the moment and the planned application I don't need the serial output, although it still bothers me why the error occurs. And of course it would be nicer for debugging ;)

[martin3000]

Same problem here.
This is my code:

#include <esp_dmx.h>

void setup() {
  Serial.begin(115200);
  while (true) {
    delay(500);
    Serial.print("ok ");
  }
}

void loop() {
}

As you see, the problem arises by including esp_dmx.h
Including dmx_caps.h or dmx_types.h has the same effect.

While playing around with the arduino ide, I found that including an empty file from the library directory esp_dmx/src triggers compile operations in esp_dmx/src/dmx.

Going back from esp32 board version 2.0.1 to 2.0.0 solved the problem.

[someweisguy]

Interesting! I am able to replicate this issue now. It looks like Arduino-ESP32 v2.0.1 Serial is now using ESP-IDF. I am not quite sure what that means exactly, so I will investigate to see if that is the problem.

It's really bizarre that #include-ing an empty file causes this issue. It looks like when you do this, Arduino looks for the appropriate library in your libraries folder and compiles the entire library anyway. I used #include <dmx_caps.h> which contains no compilable code and I got the following verbose compilation log:

Alternatives for dmx_caps.h: [[email protected]]
ResolveLibrary(dmx_caps.h)
  -> candidates: [[email protected]]

Still: weird that it seems to link the library in. In the meantime, yes, v2.0.0 still works. I will let you know what I find!

Edit: Looks like it may be something in esp_dmx.c. When you delete that file, the problem goes away. I am guessing it is either one of the includes in that file, or one of the macros in that file that is clashing with a macro in Arduino. Will keep you posted.

[martin3000]

Wow, great that you found it!!!

[someweisguy]

Changes have been merged. Thank you!

[someweisguy]

Glad to hear it! Thanks for following up!