-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Browser requirements ? #12
Comments
Hello my friend and MANY thanks for dropping by. Here is the story. When I started on the ESP32 Duktape project, I wanted a full IDE that was served up from the ESP32 into which I could enter and save/load JS code and run it. I also wanted a live console shown in the attached browser console area. I'm delighted to say this all worked ... everything was perfect. Under the covers, a large portion of ESP32 Duktape is itself written in JavaScript. This includes the IDE, WebServer, WebSockets and much more. Since the applications run on the ESP32 and we want the console output to appear on the browser, we need a mechanism to "push" new message from the ESP32 to the browser so that the browser can visualize them. The technology known as "WebSockets" is GREAT for that. Full support was added. All was good. And then I started writing some JS applications ... actually USING ESP32 Duktape ... and I noticed something VERY disturbing. The ESP32 has 512K of RAM. Great. However, only 200K of that is available to the application. Where did the rest go? Well it is needed by the ESP32 itself ... it is into this RAM that code is loaded from flash and then executed. Ok ... so that leaves us 200K ... thats a bunch. By the time we then load up the TCP/IP stack and Free RTOS, we are down to about 80K. Ouch ... getting tighter. Now let us look at the IDE .. that needs TWO concurrent TCP/IP sockets. One for the browser requests/responses using HTTP and a second socket for Web Socket connections to show console output. And now we are in trouble. When we create a socket, the ESP-IDF needs between 10-25K for message buffers (in and out) and the like. Creating two sockets and subtracting that from 80K ... we ran out of room. Everything would just about work ... but as soon as we ran any apps we wanted to load, we would fail. I looked into ways of stripping out and optimizing RAM usage as possible ... but it was getting tight and we were starting to sacrifice. For example, I could buy back 20K of RAM if I gave up on JavaScript stack trace for user code exceptions ... I didn't like where this was going. I worked with the author of Duktape and he said that he was working on a solution where the JavaScript code could be "compiled" and run from flash which would reduce our RAM footprint at the expense of performance. He hasn't gotten there yet ... however something NEW and WONDERFUL has happened. It is the ESP32 module called WROVER. While this still has limited availability, I have a few instances. It is an ESP32 module with 4.5MBytes of RAM. This is 9x the size of the base 500K. Last weekend I built ESP32 Duktape with everything enabled and all was a joy. Full IDE, Full WebSockets full everything. I think I am going to be recommending Duktape for the WROVER only. Now back to your original question ... I deliberately "disabled" WebSocket from ESP32 Duktape so that only one socket would be used ... and this means that even though there is space for it in the Web IDE editor, it is explicitly disabled. Its been re-enabled in the latest source code on Github ... so that the WROVER users can take full advantage of it. |
Is the esp32 duktape IDE successfully functioning with regular ESP32s? I am experiencing these same issues described by ThorvaldAagaard above with the esp32 M5stack. |
I have successfully installed the software and updated my ESP32. Connected it to my SSID, and is getting this screen:
But when I run the code there is no output to the console
I have tried the Enable options, and also the load, but nothing happens in the browser.
I get the following output if I monitor the UART
So it seems the code is executed, just not returned to the browser
The text was updated successfully, but these errors were encountered: