Most recent activity
-
this is more than just resetting. I reset and upload/run my script and initially the callbacks are called but then fail per the output I supplied. Why would it initially call a callback but on the second call of the function fail to call the passed callback even though the function has clearly completed its task (e.g. disconnect). That seems like a bug to me (coming from nodejs world that has never happened to me) although I'm still a noob when it comes to javascript/espruino on esp32
-
based on comments in that issue looks like this S2 chip won't be working with espruino any time soon. I'll find alternative use.
-
Well I bought a wrover and tried my code and this issue persists. Since my code looks "fine" I can only assume this is a bug in espruino.
Looks like since the esp32 is not an official board so this bug may not be addressed.
I was hoping to use espruino on an esp32 (even written a starter repo using rollup) and I'd like to make a donation but it's a catch22. I'd like to donate but only if it can be used. If I can't get a simple program running with stable behavior (callbacks called dependably) well then it's not useful :(.
-
Bought this newish esp32 flavor, soala
https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/hw-reference/esp32s2/user-guide-saola-1-v1.2.htmlthe esptool can't upload the binary to flash apparently because the crystal frequency is different.
It seems this "new" frequency is not supported and/or the the esptool is not reading the correct value from the board. Has anyone else tried this board? Can the binary be recompiled to support this apparent hardware difference?Chip is unknown ESP32 (revision 1) Features: WiFi, Single Core, VRef calibration in efuse, Coding Scheme Repeat (UNSUPPORTED) WARNING: Detected crystal freq 344.33MHz is quite different to normalized freq 40MHz. Unsupported crystal in use? Crystal is 40MHz MAC: 3c:08:5b:80:ea:bd Uploading stub... Running stub... A fatal error occurred: Invalid head of packet (0x50)I'm using this script which works fine with wroom and "regular" wrover.
#!/bin/bash VER=${1:-latest} esptool.py \ --port /dev/ttyUSB0 \ --baud 115200 \ --chip esp32 \ --after hard_reset write_flash \ -z \ --flash_mode dio \ --flash_freq 40m \ --flash_size detect \ 0x1000 ./$VER/bootloader.bin \ 0x8000 ./$VER/partitions_espruino.bin \ 0x10000 ./$VER/espruino_esp32.bin -
I'm beginning to suspect that is the esp wroom. It only has 512K RAM.
I changed the code above to do 3 manual manual disconnects and you can see (below) both the disconnect and connect callbacks were called the first time but then not called afterwards (I used a timeout) even though it was really disconnected and connected. Sometimes though when I run it they may get all called for all three trials. The callback failure is not particularly consistent unless I fail to do a hard reset in which case then never get called.
I know that for low.js the minimum requirement is wrover (has extra (ps)ram and flash) maybe that is also true for espruino? @MaBe? Have others had similar issues issues using a wroom??
Explicit board JSON supplied: "../boards/ESP32.json" Connecting to '/dev/ttyUSB0' Connected environment { "VERSION": "2v06.122", "GIT_COMMIT": "eca6aae8", "BOARD": "ESP32", "FLASH": 0, "STORAGE": 262144, "RAM": 524288, "SERIAL": "246f2855-5a80", "CONSOLE": "Serial1", "MODULES": "Flash,Storage,heatshrink,fs,net,dgram,tls,http,NetworkJS,Wifi,TelnetServer,crypto,neopixel", "EXPTR": 1073484860, "PRODUCTION": false } determining wifi status not connected...connecting ERROR: Wifi: event_handler STA_START: esp_wifi_connect: 12298(SSID is invalid) WARNING: Wifi:startMDNS - espressif wifi connect callback ESP connected to AP application online at 10.0.0.225 ---------------- manually disconnect/reconnect test -------------- 1 forcing disconnect now wifi disconnect callback ESP disconnected from AP attempting reconnect in 5 application offline determining wifi status not connected...connecting WARNING: Wifi:startMDNS - espressif WARNING: Wifi:stopMDNS wifi connect callback ESP connected to AP application online at 10.0.0.225 ---------------- manually disconnect/reconnect test -------------- 2 forcing disconnect now disconnect timeout disconnect callback failed but device is disconnected!!! ESP disconnected from AP attempting reconnect in 5 application offline determining wifi status not connected...connecting true timed out trying to connect connect callback failed but device is connected!!! ESP connected to AP application online at 10.0.0.225 ---------------- manually disconnect/reconnect test -------------- 3 forcing disconnect now disconnect timeout disconnect callback failed but device is disconnected!!! ESP disconnected from AP attempting reconnect in 5 application offline determining wifi status not connected...connecting true timed out trying to connect connect callback failed but device is connected!!! ESP connected to AP application online at 10.0.0.225 done disconnect trial of 3 times > -
yes there is a rollup plugin for typescript so would be easy to add this.
https://github.com/rollup/plugins/tree/master/packages/typescript
Not sure if reducing to es6 and then following with what I have done (buble, etc) is best or just tell it to go all the way to es5. The later would include many superfluous transformations and defeat what I was trying to do which was only transform what was needed with buble and that single async/await.
@parasquid this "no callback" issue wasn't restricted to the connect and disconnect functions it was doing the same for wifi.ping, likely any callback.
The code I posted at the top was not the same code that generated the output above . The code whose output is above is from my starter repo that uses rollup and the listeners are not in the connect function. So rather than try to post all the pieces here is the link. I just committed the version of the "app.js" that does the three trials.
https://github.com/dkebler/espruino-starter.git
You'd be able to clone it and try my actual code. Directions are in the readme. It's swift to get this running. Maybe running the exact same code we can track down my issue.
In my wifi class there is a getter for a complete status which can be used at any time to see what state/status the wifi is in. I'll check again but I don't recall the disconnect being left in station: "AUTH_LEAVE" when the the callback was never called.
one thing to note is that station might be "connected but the ssid is empty which is really a disconnected state (as I can't ping the esp like this). That's why my connected getter checks both station and ssid.