Changes in branch ESP32-v3.0 (disable/enable BLE and Wifi)

Bluetooth on ESP32 eats a lot of memory. Only 2500 JsVars are available with Bluetooth and Wifi.
Just pushed a version to branch ESP-v3.0 with new commands to bypass this problem for those that need more memory instead of BLE or Wifi :

• ESP32.enableBLE(false/true) , adds about 1900 additional JsVars
  
• ESP32.enableWifi/false/true) , adds about 3800 additional JsVars
  
• ESP32.getState() , flags are added for BLE/Wifi status
  
  

Default is BLE and Wifi are enbaled.
If you don't need one of them in your application:

• type command to disable (argument = false)
  
• this status is saved in NVS (special storage area of ESP32)
  
• any saved source is deleted. This needs to be done to avoid overflow in JsVars
  
• ESP32 board performs a restart
  
• during restart status in NVS is checked, and based on that available RAM for JsVars is calculated
  From now on, the board starts according to enabled/disabled protocols.
  To go back to original, you can flash all memory, or use the ESP32.enable-functions with true.
  
  

To get this function running, a new mode for allocationg memory for JsVars is added. Please see ESP32.py in boards directory.

@Gordon, could you please take a closer look to changes in jsvar.h and jsvar.c
@wilberforce, I've never had the problem with hot chips, could you please check with your boards

Thanks! Looks good!

Do you think you could:

• Not do extern unsigned int jsVarsSize; (as someone might be tempted to change it on the fly!). Instead just make it an argument to jsvInit if VARIABLES_MODE_MALLOC is set?
  
• Don't add variables_mode or change scripts/build_platform_config.py, but instead just add DEFINES+=-DVARIABLES_MODE_MALLOC like this: https://github.com/espruino/Espruino/blob/ESP32-v3.0/boards/PUCKJS.py#L44
  
  

I'm happy to make those changes if you want me to though.

Please feel free to make any changes.
It will save my time.
And you don't have to doublecheck my changes ;-)

Ok, just done - and I brought it up to date as well

Thanks for this guys.

I've pulled and done a build....

The vars have increased after:

>ESP32.enableBLE(false);
Erasing saved code.
Done!

>process.memory();
={ "free": 4238, "usage": 62, "total": 4300, "history": 4,
  "gc": 0, "gctime": 3.282 }

WARNING: Bluetooth is disabled per ESP32.enableBLE(false)
WARNING: has simple connection not implemented yet

The last message suggests that some intialisation code is still running?

The NRF object is still visible - I'm not sure if this is an issue or not.

Do you want to continue the conversation here or on github?

@wilberforce, lets go to github for next changes, thats ok for me.
You mentioned somewhere about hot chip with BLE supported firmware.
Is this still the case if you disable BLE ?

Short and quick answer here.

• message will go away with changes for UART.
  
• NRF object and Bluetooth object are still available. Still searching for a nice idea, .... As Gordon mentioned, there would be a backdoor to access them even they are set to nothing. And adding an "IfBLEenabled()" to all functions looks like an oversized solution to me.
  

@JumJum

With regards to the hot chip - normally there is no heat when you touch with a finger and when I tried the ble firmware first time - it felt slightly warm - nothing to be concerned about!

http://forum.espruino.com/conversations/320632/#comment14237159
The version I downloaded runs with approx. 120 gr. C,
taken with E.getTemperature ().

120 degrees C??? wow, I'm impressed it even works at that. I'm impressed it even senses temperatures that high!

Do you have any others that do it? It could just be your board/chip is faulty.

The only way to get temperature on ESP32 is a sensless function.
Your finger is much more helpful to get temperatur os the chip
temprature_sens_read() and no, its not a typo ;-)
Description from Espressif guys is
temprature_sens_read (sic.) returns ADC counts. To convert these into degrees C you would need to perform some kind of calibration by measuring the temperature with an external tool.

Yes, I read about it afterwards.
In other words, it is the number of numbers displayed and explains why the other esp32 shows 160.
I also read that each esp32 should be calibrated for temperature.

The last downloaded version is espruino_1v99.36_esp32.tgz, but it shows something else when I reset.

____ _
| __ | ___ ___ ___ _ _ | _ | ___ ___
| __ | _ - | . | _ | | | | | . |
| ____ | ___ | _ | _ | | ___ | _ | _ | _ | ___ |
          | _ | espruino.com
  1v96.3765 (c) 2018 G.Williams
Espruino is open source. Our work is supported
Kun ved salg af officielle boards og donationer:
http://espruino.com/Donate

You mean the Kun ved salg af officielle boards og donationer?

The fact that it's reporting 1v96.3765 but you uploaded a binary named espruino_1v99.36 looks pretty strange...

Can you check process.env and let me know the commit hash?

Hmm, your screenshot shows some strange words (danish ?)
Did you download binary from Espruino Server, or compile by yourself ?
Just downloaded from http://www.espruino.com/binaries/travis/master/espruino_1v99.175_esp32.tgz
and get what I expected (1v99.175)

Sorry, it was my fault, I did not change folders in my batch file, so I flashed an older version, now it's okay.
I did not see that the text was translated into Danish, once more sorry.
Now I'm up to running with the new version.

>reset();
=undefined
WARNING: --- gap_setScan 0
WARNING: Scan stop failed
WARNING: set rssi scan not implemeted yet
WARNING: has central connection not implemented yet
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 1v99.175 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
>process.env
={
  "VERSION": "1v99.175",
  "GIT_COMMIT": "fe5afe9",
  "BOARD": "ESP32",
  "FLASH": 0, "RAM": 524288,
  "SERIAL": "d8a01d40-9f94",
  "CONSOLE": "Serial1",
  "MODULES": "Flash,Storage,fs," ... "r,crypto,neopixel",
  "EXPTR": 1073485300 }
> 

Glad it's sorted. Having said that I took a look at the Travis builds anyway and it was possible for other people's GitHub code to get uploaded there by Travis (if they'd set up Travis or made a Pull Request) and I have now fixed that and deleted the offending files.