-
-
Notifications
You must be signed in to change notification settings - Fork 749
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
Improve ESP32 implementation #1777
Comments
Solution: Update to 2v04.401 or newer, go for lastest travis build and |
Cannot use sd card. (I'm not sure this is not my fault.) I get:
Here is the pinout: (sd detect is working)
Solution: check #1778 for details |
save(); does not work If call save(); ESP32 resets and then I cannot access the uploaded functions...
After that esp32 resets:
MaBecker: run require('Storage').eraseAll() to fix this |
After some times switching the switch connected to D39 (headphone sense), ESP32 resets. Here is the code:
Here is the serial coredump:
|
Started running device testing from Device Test Harness |
run test for https reduced vars down to 1700
trying some simple code
|
I summarize the list of hardware functions that I use successfully:
I am ready for any contribution or details that allow us to advance and improve the ESP32 version. |
All these functions have been tested with firmware v2.0.130. It seems that the latest firmware has problems, and perhaps some functions that I say work, have stopped working. I have to check with the latest firmware. |
This is my actual enviroment :
and API
|
I just generated a new Build environment. I have downloaded the latest github and the firmware generated is the following version:
I'll do the tests from here ... |
So my situation for testing is: my previous environment where everything works well is: and the new environment is The objective is : |
I publish here the little code that I have tried to use the Touch functionality ... It is pending to implement it correctly, since it is necessary to define the state of a PIN as TOUCH. file jswrap_io.c ->
file in jshardware.c ->
In case the code is useful for someone to start the implementation |
The partition file (BIN) has been modified according to but the CSV file detailing the partitions I don't know if it is still correct now. |
I have verified that the original js_code partition started at 0x2C0000 now it has been changed to 0x320000 to leave more room for the firmware. Doing tests to add Tensorflow I had to increase the space more and I have it at 0x380000 which leaves me 1728Kbytes. Maybe we could leave a big size thinking about the future. |
There is one bitter site on adding function. It reduces the heap and that reduces memory. |
Yes it's correct. I have not calculated how much heap and JSvar spends. But if it could work as a BLE that can be disabled on reset it is a very good solution. |
ESP32 and https is all about memory ..... The kicker to get heap memory is to remove this build option
and set 'variables' to a lower value like 1800, having compact vars would be helpfull. test code:
output:
@jumjum123: What do you think about removing this option?
|
JSVAR_MALLOC is all about allowing memory to be allocated as needed - so theoretically it'd be possible to set it up to allocate less memory if you wanted HTTPS, even without a reboot. Maybe via whatever flags are currently used to toggle BLE state? |
Toggle BLE cause a reboot. So let me look into JSVAR_MALLOC and try to make it dynamical. Maybe @jumjum123 can support too. Does JSVAR_MALLOC is using the conventional allocation or does it use something like compact vars? EDIT: Ok, so it is not ESP32 specific as it lifes in src/jsvar.c - wrong! It is used in main.c for esp32 with a heap limitation of 40000. Edit: added test results for different values
Summary: Need about 47 KB free heap to run https. |
also add these to the list: #1832 |
Using Storage, it does not take many write/erase cycles to cause an error that results in a reboot. Test code:
|
This code causes a stack overflow
If it runs again it also produces
|
I have spent a lot of time on this stack overflow bug and I think I have exhausted what I can do without help. Here is what I have found so far: My investigation is focused on The stack overflow exclusively occurs when Using uxTaskGetStackHighWaterMark shows that the call stack always has over 21000 My attention is drawn to the input parameters to Anything from a nudge in the right direction from a more experienced Espruino maintainer to a solution would be greatly appreciated at this point. |
Thanks for looking into this. Have you been able to add a It's very odd about there being enough stack free. If not, I'd have put it down to maybe In that case I can totally see how it would overwrite the available stack. |
Hello everyone, I haven't written for a long time. I've continued to work on ESP-IDF 3.3.6. I go slow. I'm learning how everything works. And finally I've managed these days to make ESP-IDF 3.3.6 work by myself. Once achieved, I've started working on ESP-IDF 4.4, which is from January 2022 the same as 3.3.6. I'm making progress even though the BUILD system is different. I've not been able to keep the current makefile. And I'm using the one from ESP-IDF 4.4. A day ago I started in parallel with ESP-IDF 5.0 stable. The build system is very similar to ESP-IDF 4.4. But the hardware API has changed a lot and the FreeRTOS version too. You've to rewrite a lot of code with the implications that it entails. At the moment I'm going slowly but well, so I'm going to continue. I hope to write news not too late. |
Hello, I'm still working on ESP-IDF 4.4 and 5.0. Now working on the analog hardware. I see that only the ADC1 channel is implemented, but not the ADC2. I noticed it when I read the analog value of pin 4, which gave me error. According to ESP32 we have: I'm going to add the code for channel 2, it will be useful. |
@rgomezwap Nice. Do you have time to fix some of the errors? |
Unfortunately the time available varies from week to week depending on the work. |
Current status of version 4.4. VID-20221230-WA0000.mp4Testing the hardware. Still a long way to go, but I'm not that far away. |
Nice, what about the known errors? Do they still exist with IDF 4.4? |
At the moment these are basic tests. There are important modules that aren't included at the moment: WIFI and Bluetooth. At the moment I have a Espruino Core, only interpreter and REPL. Both in 4.4 and 5.0. Now adding the basic hardware. This allows me to minimize the number of errors. And see how the memory consumption goes up according to the modules. Is there a major error I should watch for? |
Yes: #2295 plus the Collection of observations at the top |
Ok when I add WIFI I will look into this specific problem and say something on #2295 . |
Hello, I am still working. At the moment with ESP-IDF 4.4 adding WIFI. But having two cores accessing JsVars at the same time gives problems and I'm looking for a solution. FreeRTOS with SMP systems says to use taskENTER_CRITICAL. I'll continue to report. |
@rgomezwap Any update? I can't still use any espruino version after the 2.06 because I get a lot error ( guru meditation and psram ) with my esp32 wroom 32 |
It would be interesting if you can come up with a code example that fails reliably on 2v17 - I have customers using this in production and it's stable for them |
Hi and thank you for answer me! I flashed espruino 2v17.56. Even If I do a simple "console.log("hello world") I got this: | |_ ___ ___ _ ||___ ___
| |_ ___ ___ _ ||___ ___ |
Hello, the truth is that I got stuck on an error related to the WIFI SCAN callback. And I have started working on the ESP32 S3 version, but compatible with ESP32. This thread discusses the topic: https://forum.espruino.com/conversations/372053/#comment16953127 But I think the error you have is very specific. I don't think it's from the latest Espruino builds. But I'll try it later to see if it happens to me. I always do is erase all memory before uploading new firmware. Sometimes things are left in data partitions. |
I'm sorry. I just tested it. You are right. I have uploaded the firmware from the link you sent me and the same error occurs. Let's see if more people say something and we can clarify. |
Ok, thank you! This is a bit frustrating for me because i can't use a recent version of espruino |
Ok, I just:
It seems the issue is |
I've just pushed a few other changes (getting rid of warnings, adding flow control). Maybe try now - it should be a lot better. Some the 2v18 release I'll make the Web IDE remove the 'slow writes' it has to add to avoid dropping characters on ESP32, which should make things a lot snappier too. If you use the dev Web IDE from https://espruino.github.io/EspruinoWebIDE/ you can now choose 'Never' for 'Throttle Send' to get it faster before then |
Hi! I just compiled and flashed with your fixes and now it works very well! Thank you so much for the fast response and fixes |
@MaBecker I'm trying to get Bluetooth UART working nicely, and while it works well normally, I'm hitting:
When sending a lot of data over Bluetooth at once (on WROOM32 or normal). As far as I can tell the error isn't actually in the code that's related to UART, but it's triggered by a libc divide function called by something else in an interrupt. I did a quick google and spotted a thread mentioning that |
Actually forget that - I managed to get it working without the timer/interrupt handler and it seems a lot more reliable now! |
HI, I added some questions here earlier that Ive just deleted. As all seems to be well now. |
At the moment (2v17.71) the only wake mode from deep sleep is timer based. ESP32 boards also have the ability to wake by touch as well as by external interrupt but these are not yet implemented in Espruino. I have just submitted PR #2358 which implements wake on external interrupt using ext0 (single pin wakeup) which I hope will be considered favourably. There is a second possible external interrupt wakeup function using ext1 (with bitmask arg for multiple pins) that could also be implemented but I thought I'd wait to see how my first contribution goes. Eventually, wakeup by touch would be nice too. |
The project I'm doing that uses the deep sleep stuff needs to know what has caused any wakeup. Therefore I now have another change ready for the ESP32 implementation which exposes esp-idf's esp_sleep_get_wakeup_cause() function as ESP32.getWakeupCause(). My question is whether to submit this change as a new PR or, since this change affects the same files as my PR #2358, to try rolling the new changes into the existing PR? Thanks for any advice. |
Sorry, only just spotted this and merged - I'd make that a new PR. In general if it's possible to do smallish PRs that's probably better - if I can just glance at the file changes and see clearly nothing will have been broken I'm far more likely to just click merge straight away :) Thanks for these additions. It's hugely helpful to have folks that are willing to contribute fixes when they have problems :) |
Thanks for the merge. I've just submitted PR #2359 to add getWakeupCause(). |
Just merged, thanks! And thanks for the donation too - that was extremely kind of you! |
ESP-IDF is 3.3.6
Collection of observations
functional:
check wifi.save()
neopixel, now working with multiple pins
neopixel strips via different pins
add SDCard support by removing FlashFS pr 1780if you like SDCard support build your own firmware.source code contains
jsWarn()
, 65 matches across 8 files pr 1880hardware SPI is slower than softwarehttps see issue and forum, check this possible Solution
update partitions_espruino.csv pr #1905
add jsuGetFreeStack() pr 1882
add exception if a i2c device is not available pr 1880
add FLASH_BAUD to make process, because different boards need different rates pr 1880
add jshSPISend16()removed as there is now jshSPISendMany()add BLE-UART functionality
BLE-UART fixes (automatically 'flush' data, move console to BLE UART when connected, enable by default(?))
add jshSPISendMany() pr 1886 & pr 1888
I2C access on wrong address, check issue 1480 for details
allow to remove BLUETOOTH from ESP32 board files pr #1944
ESP32 hardware SPI receive broken since 2v06 check issue 1963 for details
Problem with NRF.setScan() check issue 2138
Wifi.getHostByName() needs sometimes more than one call details
Possible ESP32 hanging WiFi scan issue #1939
improve shiftOut, check issue 1915 for details
NRF.updateServices() needs fixing issue 2292
add touch sensor
BLE/NRF error , check issue 2493, issue 2292
documentation:
add list of pins that can be use with setWatch() pr 543
update SPI section
add I2C section
remove SDCard function from ESP32 page
add neopixel
update flash-map-and-access
add sample and link to https
update setHostname
Last Update: 09/03/2024
The text was updated successfully, but these errors were encountered: