ESP32-DMX_rdm STATION_MODE #12
Comments
|
Is it the case that this works for you on one board and not another? It appears that the sketch made it all the way through the setup() function, ran into an error, and then restarted, made it all the way through setup and ran into another error. The errors look memory related to me. Are the boards you are running this on identical? |
|
632/5000 |
|
I have not noticed this problem and I mostly use the ESP32 in station mode. It seems like you are asking the ESP-32 board in station mode to connect to another in access point mode. Have you tried instead to connect to a non-esp WiFi network? Also, it could be that this is an issue with the arduino-esp32 library. The one I have been using is from somewhere around a month ago. There have been a lot of changes to the master on github since then. I updated my copy today (espressif/arduino-esp32) and will try uploading the rdm example using the latest when I get a chance next week. There's only one file that is changed from the espressif/arduino-esp32 library for DMX input to work and that is cores/esp32/esp32-hal-uart.c. I don't believe that any changes to this have been made in the last month. But there may have been changes to the WiFi that are causing this problem. (That's entirely speculative as to why you might see this when I don't.) |
|
actually I connect this esp in station on another in ap. |
|
Also, you can try to comment out line 612: |
|
I updated (espressif / arduino-esp32) and it's been 12 minutes that the esp are connected and no error. |
|
Well, no, I was too optimistic. |
|
it does not work. it is but worse. reboot on reboot. |
|
so i try to connect them to my home wifi.freebox network. but that's the same. |
|
the esp which is in dmx input does not reboot is stable on my home network. it is thus in station and stable but in input. ??? |
|
Can you post the backtrace now that the arduino-esp32 library is updated? Perhaps the decoder will be more accurate if I can duplicate your source files. Also, can you diagram the setup, something like this: dmx -> ESP-32(AP/input) ----Art-Net-----> ESP-32(STA/output) -> dmx I'm want to be clear which is input/output and which is access point/station and which network protocol you are using. And, of course, which one is crashing. |
|
of course,
my diagram is the one:
dmx -> ESP-32 (AP / input) ---- Art-Net -----> ESP-32 (STA / output) -> dmx
it's ESP-32 (STA / output) reboot
I add a screen on esp32 AP / input and buttons
config but the one works very well.
ESP32-DMX-rdm_riri_node_004 is AP
ESP32-DMXNeopixels_riri_007_3 is STA
De : Claude Heintz [mailto:notifications@github.com]
Envoyé : dimanche 31 décembre 2017 01:23
À : claudeheintz/LXDMXWiFi_Library <LXDMXWiFi_Library@noreply.github.com>
Cc : richard fontaine <ririfonfon10@gmail.com>; Author <author@noreply.github.com>
Objet : Re: [claudeheintz/LXDMXWiFi_Library] ESP32-DMX_rdm STATION_MODE (#12)
Can you post the backtrace now that the arduino-esp32 library is updated? Perhaps the decoder will be more accurate if I can duplicate your source files.
Also, can you diagram the setup, something like this:
dmx -> ESP-32(AP/input) ----Art-Net-----> ESP-32(STA/output) -> dmx
I'm want to be clear which is input/output and which is access point/station and which network protocol you are using. And, of course, which one is crashing.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#12 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AYX5coSIkhj6Y_PwH7DNgBFokU7mSVMRks5tFtP-gaJpZM4RPY1z> . <https://github.com/notifications/beacon/AYX5cvmpm6Af-V6zi6eP5TVluSXKh7paks5tFtP-gaJpZM4RPY1z.gif>
…---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
|
|
I thought that you were using the ESP32-DMX_rdm example which acts as an Art-Net node and outputs regular dmx. But, your post suggests that might not be the case, that you are receiving Art-Net to drive NeoPixels rather than regular DMX. If you were using the ESP32-DMX_rdm example exactly as it appears on GitHub, with only modifying the LXDMXWiFiConfig.cpp file, (and the latest arduino-esp32 hardware library with just the modified esp32-hal-uart.c file), then I can decode the backtrace to see where in the code the error is happening. The backtrace looks like this: Backtrace: 0x40087650:0x3ffd6360 0x4008774f:0x3ffd6380 0x400d6593:0x3ffd63a0 0x400d65da:0x3ffd63c0 0x400d6cde:0x3ffd63e0 0x400d6d67:0x3ffd6400 0x400d6232:0x3ffd6420 0x400d61e9:0x3ffd6440 0x400d3ad8:0x3ffd6460 0x400d4da5:0x3ffd64a0 0x400d4ddf:0x3ffd64c0 0x400d1b11:0x3ffd64e0 0x4011b9b0:0x3ffd6500 The decoder (https://github.com/me-no-dev/EspExceptionDecoder) converts these hex addresses into function names: Decoding 13 results For this to work and to match address to function, the compiled code must be the same. For me to do the decoding, I need to match what you have compiled and are testing. However, you could use the EspExceptionDecoder tool on your code, after an exception has occurred and that will give you a more precise location of what function is causing the error. In the above decoded stack trace, the addresses in the backtrace obviously do not match the functions in the source code. |
|
0x40087650: invoke_abort at /Users/ficeto/Espressif/ESP32/esp-idf/components/esp32/./panic.c line 553 |
|
Hello and good year. |
|
ok why do I have to change that: |
|
I updated the example today. Using the remote config app to setup 2 ESP32 boards, the following ran for a couple of hours: dmx -> ESP-32(AP/input) ----Art-Net-----> ESP-32(STA/output) -> dmx Its not clear what you are asking about in terms of the network addresses. The input address is that address that Art-Net is sent to when the mode is input to network, which reads DMX from the UART and sends out Art-Net packets. In my test, the station had the default static address 10.110.115.10. The gateway address is used to resolve addresses and the subnet determines what portion of the IPv4 address belongs to the network and what part is unique to the host. Addresses beginning with 10. are class A addresses so the that is the network portion. The other three octets form the host's unique address. If you use the subnet mask 255.0.0.0 then the broadcast address that goes to all hosts is 10.255.255.255. If you use the subnet mask 255.255.255.0, then the broadcast address is the first three octets followed by 255 in the last one. Any computer that can receive the broadcast must have the same first three octets in its address. In my test, the receiving ESP-32 in got its network setting using DHCP. |
|
if I understand correctly, with the application of remote configuration there is no bug of the receiver? thank you for all. |
|
so I followed your instructions: |
|
just to be really sure. |
|
Yes, it does work. The problem is not in the config at all. It is in the call to parsePacket() in the ESP32 WiFi library. Inside parse packet there's an allocation: I have never seen this problem. But I have plenty of memory on my board(s). You are running out for some reason. Assuming that your board has memory available and it is not physically running out, you could try increasing the stack size of the app_main function in hardware/espressif/ESP32/cores/ESP32/main.cpp extern "C" void app_main() You could try increasing the 8192 to 10240 and see if that allows parsePacket to allocate its buffer. |
|
Another way of freeing up memory (if you are sticking to Art-Net only) is to remove: 69] LXWiFiSACN* sACNInterface; and any code that uses these objects. sACNInterface allocates over 1500 bytes just in the DMX buffers alone. |
|
ok it works for now (30min) thank you |
|
well no after 45 minutes it does not work |
|
I've had the Art-Net->DMX example running for hours with the latest hardware/espressif/esp32 and no issues whatsoever. What you might try is running the example with regular DMX output instead of driving LED pixels to insure that it works on your hardware with the libraries you have included. You can add: Serial.println(uxTaskGetStackHighWaterMark(NULL)); after line 662, vTaskDelay(1); in the main loop. This should let you see how large the stack for the main loop was when it was at its largest. On my ESP32 it constantly shows 6600 from the first time through the loop. But, if something in your use is leaking memory, it might show up by doing this. Sending an update to LED pixels takes quite a bit of time. It is quite possible that it takes enough time that it is impossible to keep up at the same rate as the DMX. Art-Net should not be faster than 44 DMX frames/sec. But, it may be that the ESP is busy sending pixel data and packets are piling up waiting to be parsed by the WiFi UDP object. If this is the case, it means slowing down the rate of the DMX so that it is no faster than you can send the pixel data out. |
|
hello i compile another code. |
hello i have a problem with esp32dmxrdm when i go in station mode
the esp32 ce connect to the network then shows me this error:
config read OK.
wifi connecting to RIRI-DMX-WiFi... wifi started 2.0.0.111
starting DMX
interfaces created, udp started listening, setup complete.
number of tasks is 13
E (117455) esp_pthread: pthread_getspecific: not supported!
E (117455) esp_pthread: pthread_setspecific: not supported!
abort() was called at PC 0x400d6593 on core 1
Backtrace: 0x40087650:0x3ffd6360 0x4008774f:0x3ffd6380 0x400d6593:0x3ffd63a0 0x400d65da:0x3ffd63c0 0x400d6cde:0x3ffd63e0 0x400d6d67:0x3ffd6400 0x400d6232:0x3ffd6420 0x400d61e9:0x3ffd6440 0x400d3ad8:0x3ffd6460 0x400d4da5:0x3ffd64a0 0x400d4ddf:0x3ffd64c0 0x400d1b11:0x3ffd64e0 0x4011b9b0:0x3ffd6500
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0010,len:4
load:0x3fff0014,len:572
load:0x40078000,len:0
load:0x40078000,len:9880
entry 0x400789d8
config read OK.
wifi connecting to RIRI-DMX-WiFi... wifi started 2.0.0.111
starting DMX
interfaces created, udp started listening, setup complete.
number of tasks is 13
E (126324) wifi: error malloc bcn_param
I just changed that in LXDMXWIFIConfig.cpp in line 76
_wifi_config->wifi_mode = STATION_MODE ; // AP_MODE or STATION_MODE
_wifi_config->protocol_flags = MULTICAST_MODE; // sACN multicast mode
// optional: | INPUT_TO_NETWORK_MODE specify ARTNET_MODE or SACN_MODE
// optional: | STATIC_MODE to use static not dhcp address for station
// eg. _wifi_config->protocol_flags = MULTICAST_MODE | INPUT_TO_NETWORK_MODE | SACN_MODE;
strncpy(_wifi_config->ssid, "RIRI-DMX-WiFi", 63);
strncpy(_wifi_config->pwd, "riridmxwifi", 63);
it connect this on another esp32 in ap mode with ssid and pwd, of course with esp32-dmx_rdm
The text was updated successfully, but these errors were encountered: