I’ve been working on this project for some weeks now and I thought I’ll make a quick post here. I think it’s always kind of rewarding to see when other people start using the tools you provide.
RepPanel is a user interface for RepRap/Duet based 3D printers. It is a cheaper alternative to the already available PanelDue. Thanks to the port of LittlevGL to the ESP32 it is fast enough to get the job done and looks kind of modern & fancy.
A big difference to the PanelDue is that the RepPanel does not have to be connected via cable to the printer. You can put it up anywhere in your WiFi.
Under the hood, the firmware makes use of RTOS tasks. It requests JSON data from the 3D printers REST API, processes it and posts it to the UI. The application still crashes sometimes when it tries to write to the DMA-RAM for the SPI display. Not sure what causes it. Might be a memory bug (“low-RAM”) or ESP-IDF tasking issue.
I have not done an awful lot of embedded development, yet. So maybe some of these errors are because of bad design.
I choose LittlevGL over uGFX and I am very happy with it. It seems to be a good choice for my kind of project.
1 Like
The project sounds very interesting, is it hosted somewhere so we can take a look at it?
Do you have the log of the application when it crashes? Maybe we can take a look and find where the error is.
Regards
Carlos
Wanted to do that, but the forum thought I was not fancy enough to post links. Then it blocked me because I copy-pasted some text and it detected that as “typing too fast” 
Here you go: https://github.com/seeul8er/RepPanel_ESP32
The GUI works just fine until I show a specific gui screen. Then it takes about 10-20 seconds until the application crashes. I was able to trace it to the void ili9488_flush() call.
When calling
uint8_t *mybuf = (uint8_t *) heap_caps_malloc(3 * size * sizeof(uint8_t), MALLOC_CAP_DMA);
it returns a NULL pointer. I am guessing I am running out of memory?
Catching the NULL pointer and returning the function prevents the crash but freezes the UI entirely:
if (mybuf == NULL) {
ESP_LOGE(TAG, "Acquired NULL pointer for DMA\n\tAvailable min. heap %i",
heap_caps_get_minimum_free_size(MALLOC_CAP_DMA));
heap_caps_free(mybuf);
return;
}
1 Like
Yep, I think the system is running out of memory, what GUI screen are causing the crashes? Can you get a log out of idf monitor and share it with us?
I will take a look at your code later this week, we’re about to start working from home.
Keep safe.
Yes I’ll do. Thanks for the support. I’ll try to isolate the cause a bit more during the next days. Maybe I can create something like a crash demo so it is easier to investigate. Right now you would need to setup a HTTP server to answer with a specific JSON response to even get to the point of crashing.
At this point I definitely know it is trying to aquire more DMA memory than there is in a single free block.
I am crashing after a few seconds showing this screen while updating it with this function. I’ll see if not updating it causes the same problem.
I took the lv_port_esp32 repo and configured it to run on my ili9488 based display, it’s kinda slow, i left the demo project working for an hour and i didn’t had any issue, I will add more debug statements tho.
I’m pretty new with this esp32 microcontroller, so it may take me some time to get to the bug.
Regards
Thank you very much for your support. I think I found my bug. One of my many calls to cJSON was not freeing up the memory after processing. That caused my memory leak. As for now everything is running smoothly again!
@seeul8er Look great! Thank you for sharing!
May ask why have you chosen lvgl over uGFX? Your thoughts might be useful for other people who also needs to choose between to two library.
Hi,
Did not got the notification of your reply, it’s great to know that you found the bug 
Do you think the lv_port_esp32 can have more improvements? maybe the particular display driver you were using on your project?
Regards
The display driver works OK I think. Nothing much to improve I think. Did you ever try 8bit parallel with the ESP32 instead of the SPI?
I am looking forward to a power save mode. I think you were implementing something like that in the upcoming release. Something that informs the application via an event handler that it enters power save. Turning off the screen backlight etc. halved the power consumption in my experiments.