search

sblantipodi / glow_worm_luciferin

Bias Lighting and Ambient Light firmware, designed for Firefly Luciferin.
GNU General Public License v3.0
158 stars 19 forks source link

[Bug]: ESP32 serial output jumbled #26

Closed centripetal3 closed 3 years ago

centripetal3 commented 3 years ago

Firefly Luciferin version

2.0.1

Glow Worm Luciferin version

5.0.1

Firmware type

LIGHT

What is the stream method?

USB

Fiefly Luciferin config file

No response

Relevant log output

[16:58:39:375] BAUDRATE IN USE=500000␍␊
[16:58:39:474] ␊
[16:58:39:474] Using LEDs=511␍␊
[16:58:39:483] SAVED GPIO=0␍␊
[16:58:39:483] GPIO IN USE=2␍␊
[16:58:39:483] Using DMA␍␊
[16:58:39:483] ␍␊
[16:58:39:483] Initializing...␍␊
[16:58:49:448] framerate:0.0␊
[16:58:49:448] firmware:LIGHT␊
[16:58:49:457] ver:5.0.1␊
[16:58:49:457] lednum:511␊
[16:58:49:457] board:ESP32␊
[16:58:49:457] MACte:3␊
[16:58:49:457] effect:0␊
[16:58:49:457] :34:AB:95:4B:7A:08␊
[16:58:49:457] gpio:2␊
[16:58:49:457] baudra

How to reproduce

Hi guys,

I'm trying to run GlowWorm on an ESP32 CPU connected via USB. The PCB is Dr.Zzs PixelPro and the ESP32 module is the WROOM-32E. I haven't had any success getting FireFly to talk to GlowWorm yet, and am trying to figure out how/where to begin troubleshooting. The first thing I notice is that FireFly frequently has jumbled values in the "Devices" table. I think this points to an underlying issue in the GlowWorm serial output, and indeed, if I open a serial monitor when I plug in the ESP32, I receive the stream as shown in "Relevant log output". You can see that "MAC:34:AB:95:4B:7A:08" is jumbled up with "baudrate:3" and "effect:0".

I'm looking at the GlowWorm code to try to find out why the output gets jumbled. It looks like it only happens when the serial output is being handled by a task. You can see that the output produced during setup() is fine, but the output produced during tcpTask() has the problem. I'm not sure if this means it is a race condition, or a buffer overflow from a separate thread, or something else entirely.

How can I narrow this down further?

Thanks!

sblantipodi commented 3 years ago

I don't think that it a concurrency problem it seems that the USB signal is too weak I would suggest to change the USB cable, check that all the connections are well made, and if it doesn't solve the problem check with another PC, if the problem persist, I would lower the baudrate to see if it helps.

sblantipodi commented 3 years ago

hi @centripetal3 did you tried my suggestions?

centripetal3 commented 3 years ago

Yes, and it did not help.

sblantipodi commented 3 years ago

@centripetal3 have you tried with the same PC and cable using something like QuinLED-Dig-Uno?

centripetal3 commented 3 years ago

It's worth a try. I'll see if I can find a QuinLED-Dig-Uno with an ESP32 board and reproduce the problem.

Has anybody else been successful using an ESP32? If so, did it require any special configuration?

sblantipodi commented 3 years ago

@centripetal3 hey yes, Luciferin runs great on ESP8266/ESP32 devices, there are tons of users using Luciferin on ESP32. 😃

I think that we discovered the cause.

Pixel Pro uses MCP2221T chip that is capable of 115200 baudrate with a whopping 16% error. I think that CH340C chip will be a lot better for the purpose since Luciferin needs around 500K baud rate to run great. :)

feel free to reopen the issue or to continue commenting in this issue if you find something else interesting.

Thanks for your interest in the project and if you like it don't forget to cast a star here on GitHub 👍