When I compile my music player code, I get
Sketch uses 907870 bytes (69%) of program storage space. Maximum is 1310720 bytes.
Global variables use 124504 bytes (37%) of dynamic memory, leaving 203176 bytes for local variables. Maximum is 327680 bytes.
Most of the 124504 bytes of dynamic space are the required buffers needed to assemble the output for ESPAsyncWebServer, because it only allows one string to be sent to the client per request. The output can be 10,000 bytes and hundreds of lines. But ESPAsyncWebServer does not allow you to send one line at a time, and then close the request. So I need to assemble this huge string, which is the complete reply, and send it all at once to the client. The largest buffer for this purpose is 10,240 bytes. Also there is a 8,192 byte buffer.
As per the message above, I should have another 203,176 bytes of space available. However when I increase the first buffer to 14,336 bytes to send a larger reply, the compiler produces an error, which goes away when the buffer is reduced to its previous size.
exit status 1
Error compiling for board DOIT ESP32 DEVKIT V1.
There appears to be a hard limit of 122KB, and the remaining 198KB is inaccessible.
Do I need to declare some parameter to the compiler or is everyone having this problem?
Thanks, and your reply is greatly appreciated.
I’m not sure.
Do you have more details about the error you’re facing?
Are you using BLE in your code?
Not using BLE. Just ESPAsyncWebServer. Unfortunately the IDE compiler provides no clue why it has encountered an error. But it is related to the dynamic storage size and happens only when the size is increased. In fact of the 122KB used space, only 20KB is mine. The other 102KB is taken up by ESPAsyncWebServer and ElegantOTA. I am pretty sure this error is related to the web server and will go away if I don’t use it.
I think I am going back to wifi.h, and will discontinue using ESPAsyncWS. This package is generally useless, very difficult to use, a total bloat, and has this really crazy language that one must learn in order to use it to do the most basic stuff.
I am also using AsyncElegantOTA that requires it. But now I discovered that you have a wifi.h based OTA.
What I can say is that most people coming here to learn ESP32 are not here to load fancy packages that offer the kitchen sink, but have hidden problems and hidden limitations, and distort the learning curve, which just causes unlimited frustrations after one puts in days of work into it. I suggest instead that RNT should become a library of fundamental code related to ESP32, and avoid using someone else’s package to do basic things.
For example why are you not offering a library to drive a 480×320 or larger SPI or parallel TFT display? Displays have become very cheap and everyone should have one in their project. If you say there are already such packages available, then where are the links? And these are all coded for an Arduino and modifications are needed for ESP32. For example due to space limitations on the Mega, these packages only allow one or two very crummy fonts in a special format that you just can’t convert another font easily into this format. You should have a page that says if you want to do this, here is the link, the hidden limitations, the bloat factor, the hidden problems, the resources needed, etc.
Or better still, offer such a very basic driver that does the very basic things, including rendering curves, and offer a whole library of fonts.
I believe people who move to the ESP32 don’t want to re-invent the basic device drivers. Neither are they interested in a package, as they have their own project in mind.
Another good example are rotary encoders. Do you know how difficult it is to drive an encoder due to the bounce problem that can’t be corrected in software? I installed six encoder library modules, and they were all useless. Either they were bloatware built on a driver that they did not offer, or the driver did not work properly. You need a capacitor filter and interrupt driven software. A small interrupt driven driver that corrects the bounce problem and can offer important features such as double clicks, long clicks, rotary speed, is not more than a page long. It is frustratingly difficult to build such driver from scratch, and nobody offers a bounce-free open source.
Then it is a must to have a package on top that allows for the creation of objects on the screen and manipulate them by a rotary encoder. I think these packages will bring great value to RNT.
Hello Bernie, we are just two people behing Random Nerd Tutorials (me and Rui), it’s not possible for us to create and support our own libraries. The community itself needs hundreds of people working, debbuging and mainting those libraries.
We find libraries that the community created and that work fine for us, and we document/create unique projects using them.
We haven’t had and application that required an enconder library so we never tested those libraries, but we’ll add it to our to-do list.
Thank you for your insightful comment.