Open davidmoshal opened 7 years ago
nkolban
commented
7 years ago Howdy David, I think the version you are using is old and tired ... I have uploaded the very freshest version and docs can be found here ... https://github.com/nkolban/duktape-esp32/blob/master/docs/installation.md
You will likely be the first person to be using it ... so I am all ears. Ping me live as needed if you need direct assistance... otherwise hoping to hear back from you ... Neil
davidmoshal
commented
7 years ago thanks, much appreciated.
I made a few notes above regarding the difficulties I faced.
All user error on my part, but probably worth noting in the docs.
I could make a few edits to your instructions and send a PR request if you like.
Dave
ps, what is a Guru Meditation Error ?
davidmoshal
commented
7 years ago oops, noticed that you incorporated the changes already!
davidmoshal
commented
7 years ago NICE! Significantly smoother install than the Nov 30 build. Rebooted by itself:
there seems to be copious output on screen, lot's of low level debugging, initially I thought it was throwing errors, but I think it's all low-level debugging.
Clicking 'run' with the `console.log("Hello World") results in:
D (28745) log: selectResult: {"readfds":[0],"writefds":[],"exceptfds":[]}
D (28745) log: loop: working on ready to read of fd=0
D (28745) module_os: >> js_os_accept
D (28755) module_os: About to call accept on 0
D (28755) module_os: << js_os_accept: new socketfd=1
D (28765) log: We accepted a new client connection: {"sockfd":1}
D (28775) log: IDE_WebServer: We have received a new HTTP client request!
D (28775) dukf_utils: requestHandler: heapSize=30532
D (28805) log: selectResult: {"readfds":[1],"writefds":[],"exceptfds":[]}
D (28805) log: loop: working on ready to read of fd=1
D (28805) module_os: >> js_os_recv
D (28815) module_os: -- js_os_recv: About to receive on fd=1 for a buffer of size 512
D (28815) module_os: << js_os_recv: length=480
D (28825) log: Length of data from recv: 480
D (28825) log: http parsing: POST /run HTTP/1.1
D (28835) log: http Method: POST, path: /run
D (28835) log: http parsing: Host: 10.1.10.14:8000
D (28845) log: http parsing: Connection: keep-alive
D (28845) log: http parsing: Content-Length: 29
D (28855) log: http parsing: Accept: */*
D (28855) log: http parsing: Origin: http://10.1.10.14:8000
D (28855) log: http parsing: X-Requested-With: XMLHttpRequest
D (28865) log: http parsing: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
D (28875) log: http parsing: Content-Type: application/javascript
D (28885) log: http parsing: Referer: http://10.1.10.14:8000/web/ide.html
D (28895) log: http parsing: Accept-Encoding: gzip, deflate
D (28895) log: http parsing: Accept-Language: en-US,en;q=0.8
D (28905) log: http parsing:
D (28905) log: End of headers
{"Host":"10.1.10.14:8000","Connection":"keep-alive","Content-Length":"29","Accept":"*/*","Origin":"http://10.1.10.14:8000","X-Requested-With":"XMLHttpRequest","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36","Content-Type":"application/javascript","Referer":"http://10.1.10.14:8000/web/ide.html","Accept-Encoding":"gzip, deflate","Accept-Language":"en-US,en;q=0.8"}
D (28945) log: HTTP Request on(data) passed: console.log("Hello World\n");
D (28955) log: HTTP Request on(end):
D (28955) log: - method: POST
D (28955) log: - path: /run
D (28965) log: - headers: {"Host":"10.1.10.14:8000","Connection":"keep-alive","Content-Length":"29","Accept":"*/*","Origin":"http://10.1.10.14:8000","X-Requested-With":"XMLHttpRequest","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36","Content-Type":"application/javascript","Referer":"http://10.1.10.14:8000/web/ide.html","Accept-Encoding":"gzip, deflate","Accept-Language":"en-US,en;q=0.8"}
D (29005) dukf_utils: ide_webserver: request.on(end): heapSize=22052
D (29005) log: We are about to run: console.log("Hello World\n");
D (29015) modules: >> js_console_log called
D (29015) log: Console: Hello World
D (29025) module_os: >> js_os_send
D (29025) module_os: About to send 17 bytes of data to sockfd=1
D (29025) module_os: - data: "HTTP/1.1 200 OK
"
D (29035) module_os: << js_os_send
D (29035) module_os: >> js_os_send
D (29045) module_os: About to send 2 bytes of data to sockfd=1
D (29045) module_os: - data: "
"
D (29055) module_os: << js_os_send
D (29055) module_os: >> js_os_shutdown
D (29055) module_os: About to shutdown fd=1
D (29055) module_os: << js_os_shutdown
D (29065) module_os: >> js_os_close
D (29065) module_os: About to close fd=1
D (29075) module_os: << js_os_closebut nothing in the Console at the bottom of the page.
nkolban
commented
7 years ago At this time, I had to disable the console output because we ran out of memory ... however ... that is hoped to be a temporary story. All appears to be working, if we look in your console log from the ESP32, we see the "Hello World" message.
davidmoshal
commented
7 years ago How are we dividing usage of processor memory vs spi memory? According to the sparfun specs my board has 520k SRAM and 4m flash. I recall the days of the parallax stamp where the interpreter was otp'd onto the chip, and user programs ran out of external memory.
nkolban
commented
7 years ago SPI memory (aka flash memory) is slow read/write memory ... that can only be written in 64K blocks but is permanent until it is re-written. Its content remains when power is removed. RAM (Random Access Memory) is very fast and readable/writable at the byte level but its content is lost when power is removed. The ESP32 modules have 4MBytes of flash and 512KBytes of RAM. The programs that the ESP32 runs written into flash and mapped to the address space of the ESP32 CPU. They are then executed from flash. Working storage (the storage that is used for variables) and some time critical functions are stored in RAM.
Currently, when a JS program is sent to the ESP32, it is sent as a text string (the source). This is transiently kept in RAM. The Duktape compiler then compiles the source to "bytecode" which is itself held in RAM and the original source released. The Duktape virtual machine (VM) then interprets the byte code to run the script. A goal is to have Duktape compile the JS to byte code and save that byte code in flash as opposed to RAM. This would free up the RAM currently held by the bytecode which (in principle) should be read-only. Unfortunately, I haven't been able to get that feature operational on the ESP32 and am working with the Duktape author to see what can be done. Its is NEW function in Duktape and all bets are still off on it. If you have time and inclination, have a good study of the docs of Duktape itself (www.duktape.org).
davidmoshal
commented
7 years ago A goal is to have Duktape compile the JS to byte code and save that byte code in flash as opposed to RAM.
Basically a JIT, no? I actually saw that in the Duktape docs a few weeks ago, just assumed you were doing that.
How are you debugging the ESP32? Is there a way to watch the memory allocation as you can in Java programs (or in Chrome)?
davidmoshal
commented
7 years ago btw- I'm not seeing anythin in the Chrome console, other than "Code sent for evaluation"
davidmoshal
commented
7 years ago Looking in the source of ide.html, I see that ide.js sends a post request with the script to execute.
So, using Postman, and sending: http://10.1.10.14:8000/run with body of:
console.log('hi')I get nothing back other than 200 response code.
D (680179) log: selectResult: {"readfds":[0],"writefds":[],"exceptfds":[]}
D (680179) log: loop: working on ready to read of fd=0
D (680179) module_os: >> js_os_accept
D (680189) module_os: About to call accept on 0
D (680189) module_os: << js_os_accept: new socketfd=2
D (680199) log: We accepted a new client connection: {"sockfd":2}
D (680209) log: IDE_WebServer: We have received a new HTTP client request!
D (680209) dukf_utils: requestHandler: heapSize=28872
D (680239) log: selectResult: {"readfds":[2],"writefds":[],"exceptfds":[]}
D (680239) log: loop: working on ready to read of fd=2
D (680239) module_os: >> js_os_recv
D (680249) module_os: -- js_os_recv: About to receive on fd=2 for a buffer of size 512
D (680249) module_os: << js_os_recv: length=497
D (680259) log: Length of data from recv: 497
D (680269) log: http parsing: POST /run HTTP/1.1
D (680269) log: http Method: POST, path: /run
D (680269) log: http parsing: Host: 10.1.10.14:8000
D (680279) log: http parsing: Connection: keep-alive
D (680279) log: http parsing: Content-Length: 17
D (680289) log: http parsing: Postman-Token: 858ba495-94ab-1643-6b62-316cccd86a65
D (680289) log: http parsing: Cache-Control: no-cache
D (680299) log: http parsing: Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
D (680309) log: http parsing: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36
D (680319) log: http parsing: Content-Type: text/plain;charset=UTF-8
D (680329) log: http parsing: Accept: */*
D (680329) log: http parsing: Accept-Encoding: gzip, deflate
D (680339) log: http parsing: Accept-Language: en-US,en;q=0.8
D (680339) log: http parsing:
D (680349) log: End of headers
{"Host":"10.1.10.14:8000","Connection":"keep-alive","Content-Length":"17","Postman-Token":"858ba495-94ab-1643-6b62-316cccd86a65","Cache-Control":"no-cache","Origin":"chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36","Content-Type":"text/plain;charset=UTF-8","Accept":"*/*","Accept-Encoding":"gzip, deflate","Accept-Language":"en-US,en;q=0.8"}
D (680389) log: HTTP Request on(data) passed: console.log('hi')
D (680389) log: HTTP Request on(end):
D (680399) log: - method: POST
D (680399) log: - path: /run
D (680399) log: - headers: {"Host":"10.1.10.14:8000","Connection":"keep-alive","Content-Length":"17","Postman-Token":"858ba495-94ab-1643-6b62-316cccd86a65","Cache-Control":"no-cache","Origin":"chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop","User-Agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36","Content-Type":"text/plain;charset=UTF-8","Accept":"*/*","Accept-Encoding":"gzip, deflate","Accept-Language":"en-US,en;q=0.8"}
D (680449) dukf_utils: ide_webserver: request.on(end): heapSize=20372
D (680449) log: We are about to run: console.log('hi')
D (680459) modules: >> js_console_log called
D (680459) log: Console: hi
D (680459) module_os: >> js_os_send
D (680469) module_os: About to send 17 bytes of data to sockfd=2
D (680469) module_os: - data: "HTTP/1.1 200 OK
"
D (680479) module_os: << js_os_send
D (680479) module_os: >> js_os_send
D (680479) module_os: About to send 2 bytes of data to sockfd=2
D (680489) module_os: - data: "
"
D (680489) module_os: << js_os_send
D (680499) module_os: >> js_os_shutdown
D (680499) module_os: About to shutdown fd=2
D (680499) module_os: << js_os_shutdown
D (680509) module_os: >> js_os_close
D (680509) module_os: About to close fd=2
D (680509) module_os: << js_os_closeso, in addition to WS being disabled, it's not returning anything after the script POST.
nkolban
commented
7 years ago Chrome is of course a browser that happens also to host a JavaScript runtime engine. The Chrome console is the console to the JS engine built into Chrome. For Duktape, we have a Duktape based debugging environment that is documented here ... https://github.com/nkolban/duktape-esp32/blob/master/docs/debugger.md
It seems to run as advertized on the ESP32 environment. For the majority of my debugging, I simply add "log()" statements in my JS code and watch the console.
nkolban
commented
7 years ago For your POST test ... if you look at the trace output at time stamp 680459 you will see the output of the script in the console. The POST request to ESP32-Duktape is posting the "JavaScript source program" that we are asking ESP32-Duktape to run. Given that the program could run and be done straight away or run for hours ... there is nothing to send back to the browser as a response to the POST request other than a "200" code saying "I got it and will process it". The use of WebSockets provides a "stream" of data back from ESP32-Duktape back to the browser ... and as mentioned, that has been deliberately switched off right now until we can reduce memory consumption. No use having the WebSockets and and able to stream data back to the browser if we fail because we are out of memory for the most simplest of programs.
The source for the ESP32-Duktape side of the processing of the Web IDE requests can be found here ... https://github.com/nkolban/duktape-esp32/blob/master/filesystem/ide_webserver.js
davidmoshal
commented
7 years ago Thanks, so we're sends via /run, and watching screen for the output, correct? So the alternative would be to hook up an IDE via the serial port and watch for output, no? I forked the project to play around, and am following your (excellent) book. Page 66 talks about setting up a sample project - you're using MinGW GCC as the compiler. As I'm on OSX, am wondering which one to choose, the options are:
davidmoshal
commented
7 years ago My earlier question about debugging was whether we have a way to do something like this, which webstorm does:
https://www.jetbrains.com/help/webstorm/2016.3/debugging-javascript.html
nkolban
commented
7 years ago Ahhh ... driving the ESP32 through the serial port as an alternative ... weve already started on that. Although not yet fully publicized, we can place the ESP32-Duktape environment into a "serial processor" mode ... what that means is that when it starts up ... it doesn't NEED to start WiFi nor does it start an internal Web Server to process HTTP requests. The benefit of that is a LOT less memory needed and hence free for our own applications. The way that works is that there are scripts in ./tools which take JS files from your PC and sends them over serial line into the ESP32. Currently, because it is experimental, one needs to connect a second serial port to the ESP32 using a USB->Serial connector.
As for a development environment ... I'm a Windows man ... BUT ... I wouldn't dream of using Windows (or Mac OS) for ESP32 development. Instead I would strongly recommend running Linux ... if not natively then hosted by "VirtualBox".
nkolban
commented
7 years ago For debugging, we can indeed set breakpoints and examine variables ... its not nearly as attractive as a professional browser based environment ... its more like debugging Node.js (server side JS). We are reliant on the facilities provided by Duktape for debugging ... its not the easiest thing in the world ... see:
https://github.com/svaarala/duktape/blob/master/doc/debugger.rst
davidmoshal
commented
7 years ago thanks, comments below:
re connecting a second port, I have FTDI serial boards, for use with the ESP8622-01, presumably anything that bridges between USB and UART would work, no? A digispark could do this, or even a Bluetooth serial chip, no? (or even and ESP8266).
re development environment: sounds like I should start with the espressif eclipse tutorial: https://github.com/espressif/esp-idf/blob/master/docs/eclipse-setup.rst
nkolban
commented
7 years ago I follow the crawl, walk, run approach when attacking a new technical area. First choose the platform in which you are going to do your development .. for me that is Linux. Then learn how to compile a simple program (a hello world) using the command line. From there you can work up. It isn't uncommon for getting boot-strapped like this to take some time depending on previous backgrounds. The ESP32 is a much lower level environment than desktop programming. Study all available materials ... including the ESP32 formal docs, my book of notes and relevant You Tube videos such as ...
https://www.youtube.com/watch?v=bYh2w0HzS7s
Realize that things take time. Should you get stuck, myself and the rest of the ESP32 community will be able to assist through the ESP32 forum and IRC chatroom. Becoming conversant with C, ESP-IDF, FreeRTOS and more will take weeks .... not hours ... be sure you know what you are getting into.
davidmoshal
commented
7 years ago :) thanks Which forum and chatrooms are best?
nkolban
commented
7 years ago For a forum .... http://esp32.com/index.php
For a chatroom #ESP32 on IRC
davidmoshal
commented
7 years ago Thanks, am on the ESP32 forum. Don't use IRC, will find a Mac client for it.
nkolban
commented
7 years ago Howdy David, Is there anything further on this issue? If not, can we close it out and open new issues as needed?
davidmoshal
commented
7 years ago Hi Neil, I have to admit that I haven't had any bandwidth to explore this further. Next step for me was to set up a Linux toolchain, but I haven't got round to that yet. Am still using ESP8266 for teaching (though espruino v1.87 is the most stable build, that project seems to be getting less stable over time). Going to be a few weeks before I can pick this up again. Sorry. David
nkolban
commented
7 years ago David, Don't give it any thought my friend. My goal is to make sure everyone is happy. Pick it up when you can, I'm always going to be here.
davidmoshal
commented
7 years ago Thanks
paseaf
commented
4 years ago ps, what is a
Guru Meditation Error?
The meaning can be found here. I also came across this error with duktape ver. 2.5.0 on ESP32. Trying to find a solution
paseaf
commented
3 years ago I found the solution for my problem.
My problem was I gave too less stack size to the main task. (the default size is small for using duktape) I found the problem by inserting printf("Stack Low Watermark: %d Bytes\n", uxTaskGetStackHighWaterMark(NULL));s in my code and found it goes to 0 after evaluating a small function.
I solved the problem by increasing sdkconfig -> Component config -> Common ESP-related -> Main task stack size.
Hi, I managed to connect to ESP32 Duktape, and change the access point. However, the device appears to have crashed
There appears to be a 'Guru Mediation Error'
Some notes regarding changing the access point which you might want to incorporate back into your instructions.
I followed the instruction here: https://github.com/nkolban/duktape-esp32/blob/master/docs/README.md
screen.You might want to make that more explicit...
Using the form to try and change the Access Point took a bit of trial and error, these were some of the issues:
So, now the ESP32 connects to the correct access point. However, I was unable to ping the IP address 10.1.10.14, nor could I access it from a browser.