Search results for:

Compiling without Bluetooth is working.
Heap size with BLE : 76500
Heap size without BLE: 54500
Means we could have 1350 jsVars more in a version without Bluetooth

Next tested with default of 3000 jsVars. Starting and some first small tests work fine.
I would be happy with 3000 jsVars, anyway others could require more.
My advice in that case would be to use a WROVER board which could have much more

Checked compiling with out Bluetooth and ran into problems.
A lot of ifdef need to be added to main.c, jshardware.c, .....
Working on that now

I will not fight for OTA, its a big idea, but at the end, there are a lot of limitations.
For example, I would not like to load a new binary over Bluetooth ;-)

Having a lot of jsvar sizes based on used hardware is something which needs to be checked.
ESP-IDF is complex in that point. In actual version, BLE is always started, as WIFI is.

Following some discussions around ESP8266, I would prefer to have one binary only. Otherwise a lot of confusion could appear, "which binary is running on which board ?".

Most of sdk config changes are not available in ESP 2.1

@wilberforce, I'm on latest on github, not on pre release.
There are a lot of changes since that release.
Latest download on my side is some days ago.

Yes, lets use github for more

Has been a long time since last push to github, but today its done.
I'm a lazy guy in documentation :-(
Let me copy commit message here:

First of all, thanks to Gordons help in SW, discussions, hints, .... …
…and last not least 2 PUCK's
Without Gordons support, this port would have never happened.
General:

• Status from my point of view is still early.
  
• Server, Client, Advertising can be used, and are running at least with a Puck or NRF-connect on the other side
  
• waiting for ESP-IDf V3, and waiting and....
  
• Bluetooth needs much memory, size of binary is 1172 right now
  
• vars need to be reduced to 2000, for boards with wrover module this can be extended to 20000 or more
  
• some minor but helpful changes in core sources of Espruino
  
  

Added:

• GATTC support
  
• Advertising
  
• support malloc for vars, instead of static allocation
  
• use of additional 4mb PSRAM (if available) to have 20000 vars
  
• support lists in ifdef for Javasript wrapper, so "ifdef" : "NRF52,ESP32" are possible
  
• some more documents, should be more, but I'm a lazy guy :-(
  
• new manual for install
  
• lot of internal changes to make it more C-style
  Open items
  
• much more testing and testers
  
• no support for BlueTooth UART
  
• several NRF commands are not supported
  
• reset of Bluetooth and UART in jshreset crashes from time to time, therefore UART reset is switched off
  
• discuss how changes in core sources, mainly lib/bluetooth/* can be reduced
  
• some people offered help in forums, good time to start now ;-)
  
  

Changes to be committed:

modified:   boards/ESP32.py
modified:   libs/bluetooth/bluetooth.h
modified:   libs/bluetooth/bluetooth_utils.c
modified:   libs/bluetooth/jswrap_bluetooth.c
modified:   libs/bluetooth/jswrap_bluetooth.h
modified:   make/family/ESP32.make
modified:   make/targets/ESP32.make
modified:   scripts/build_platform_config.py
modified:   scripts/common.py
modified:   src/jsvar.c
modified:   src/jsvar.h
modified:   targets/esp32/BLE/esp32_bluetooth_utils.c
modified:   targets/esp32/BLE/esp32_bluetooth_utils.h
modified:   targets/esp32/BLE/esp32_gap_func.c
modified:   targets/esp32/BLE/esp32_gap_func.h
modified:   targets/esp32/BLE/esp32_gattc_func.c
modified:   targets/esp32/BLE/esp32_gattc_func.h
modified:   targets/esp32/BLE/esp32_gatts_func.c
modified:   targets/esp32/BLE/esp32_gatts_func.h
modified:   targets/esp32/bluetooth.c
modified:   targets/esp32/docs/Bluetooth/sdkconfig
modified:   targets/esp32/jshardware.c
modified:   targets/esp32/jswrap_esp32.c
modified:   targets/esp32/jswrap_esp32.h
modified:   targets/esp32/main.c

flow control for ESP32 is set to UART_HW_FLOWCTRL_DISABLE
Just checked all options for flow control

• UART_HW_FLOWCTRL_DISABLE
  
• UART_HW_FLOWCTRL_RTS
  
• UART_HW_FLOWCTRL_CTS
  
• UART_HW_FLOWCTRL_CTS_RTS
  
• UART_HW_FLOWCTRL_MAX
  
  

All with RTS don't work.
All others have same speed.

Yes, thats the point, thanks a lot.

Its driving me crazy, why is this not working ?

void myTest(){
  JsVar *r = jsvNewFromString("hugo");
  jsWarn("type:%t\n",r);
  jsWarn("r:%v\n",r);
  jsWarn("json:%j\n",r);
}

I get this
WARNING: type:undefined
WARNING: r:
WARNING: json:undefined

hmmm, I could implement something similiar. But IMHO, the word weird woule be a good description for that.
On the other hand, a totally new ble_uuid_t, I agree, could have a lot of side effects.

Could it be an option for a first step to add a uuid128 field to ble_uuid_t(bluetooth.h) for non NRF52 boards ?
Uuid and type would stay the way they are used today. For NRF52 everything would stay the way it is now.
Some more ifdef lines (in bleUUIDEqual,bleVarToUUID) would use this field for 128bit uuids. For 16/32 bit uuids, this could be filled with standard mask (00000000-0000-1000-8000-00805F9B34FB or 16/32 uuids into)

I've some problems in understanding handling of uuids in Espruino.
AFAIK, ble_uuid_t is used to work with uuids
ble_uuid_t.uuid is a 16 bit value only, and type can be unknown, 16 bit and 128 bit
What happens with the full uuid for 128 bit ?

For ESP32 we have a struct , which supports 16/32/128 bit uuids
In actual port for ESP32 only 16 bit is supported. This was fine for first steps into the new world, but should not be the end of the story.
Any recommendation, how we get this together ?

typedef struct {
[#define](https://forum.espruino.com/search/?q=%23define) ESP_UUID_LEN_16     2
[#define](https://forum.espruino.com/search/?q=%23define) ESP_UUID_LEN_32     4
[#define](https://forum.espruino.com/search/?q=%23define) ESP_UUID_LEN_128    16
    uint16_t len;							/*!< UUID length, 16bit, 32bit or 128bit */
    union {
        uint16_t    uuid16;
        uint32_t    uuid32;
        uint8_t     uuid128[ESP_UUID_LEN_128];
    } uuid;									/*!< UUID */
} __attribute__((packed)) esp_bt_uuid_t;

@Gordon,
changing jsvInit to use size as a parameter would be easy.
But there are some other boards, that also use jsvInit, they would need to be changed too. Something that I would not like to do.
AFAIK, C does not support optional parameters. If somebody knows better, I'm still on first part of learning curve, please give me a hint.
@DrAzzy, I'm pretty sure, sooner or later there will be someone to run out of memory, even with 64K :-)

I got it running this way.
Simple board gives me 2000 vars
Board with additional PSRAM gives me 20000 vars.
@DrAzzy, we could use 65500 here too

ESP32.py

 'variables'                : 2000,
 'variables_psram'          : 20000,
 'variables_mode'           : "malloc",             ESP32 uses malloc

jsvar.h

extern unsigned int jsVarsSize;

jsvar.c

[#ifdef](https://forum.espruino.com/search/?q=%23ifdef) RESIZABLE_JSVARS
JsVar **jsVarBlocks = 0;
unsigned int jsVarsSize = 0;
[#define](https://forum.espruino.com/search/?q=%23define) JSVAR_BLOCK_SIZE 4096
[#define](https://forum.espruino.com/search/?q=%23define) JSVAR_BLOCK_SHIFT 12
[#else](https://forum.espruino.com/search/?q=%23else)
[#ifdef](https://forum.espruino.com/search/?q=%23ifdef) VARIABLES_MODE_MALLOC
unsigned int jsVarsSize = 0;
JsVar *jsVars = NULL;
[#else](https://forum.espruino.com/search/?q=%23else)
JsVar jsVars[JSVAR_CACHE_SIZE];
unsigned int jsVarsSize = JSVAR_CACHE_SIZE;
[#endif](https://forum.espruino.com/search/?q=%23endif) //end VARIABLES_MODE_ALLOC
[#endif](https://forum.espruino.com/search/?q=%23endif)
......
void jsvInit() {
[#ifdef](https://forum.espruino.com/search/?q=%23ifdef) RESIZABLE_JSVARS
  jsVarsSize = JSVAR_BLOCK_SIZE;
  jsVarBlocks = malloc(sizeof(JsVar*)); // just 1
  jsVarBlocks[0] = malloc(sizeof(JsVar) * JSVAR_BLOCK_SIZE);
[#else](https://forum.espruino.com/search/?q=%23else)
[#ifdef](https://forum.espruino.com/search/?q=%23ifdef) VARIABLES_MODE_MALLOC
  jsVars = (JsVar *)malloc(sizeof(JsVar) * jsVarsSize);
[#endif](https://forum.espruino.com/search/?q=%23endif)
[#endif](https://forum.espruino.com/search/?q=%23endif) 
  jsVarFirstEmpty = jsvInitJsVars(1/*first*/, jsVarsSize);
  jsvSoftInit();
}

build_platform_config.py

if board.info["variables_mode"]:
  codeOut('#define VARIABLES_MODE_'+board.info["variables_mode"].upper() + ' // mode for allocating memory, standard is statically assigned');
  codeOut('');
...
  if board.chip["class"]=="ESP32":
    codeOut("#define JSVAR_CACHE_SIZE_PSRAM          "+str(board.info['variables_psram'])+" // Number of Javascript variables in RAM for boards with additional RAM (like ESP32 WROVER)");

last not least in main.c

  if(esp_get_free_heap_size() > 0x300000) jsVarsSize = JSVAR_CACHE_SIZE_PSRAM;  // looks like 4MB SPI_RAM is enabled for heap, pretty sure there is a better way, but for now ....
  else jsVarsSize = JSVAR_CACHE_SIZE;   // number of variables for boards without additional SPI RAM
  jsvInit();     // Initialize the variables

Could we move definition for jsVarBlocks, jsVarsSize and jsVars into jsvars.h ?
Other option would be to add a function to jsvar.c to set jsVarsSize from main.c

As always, if you have any better idea...

@wilberforce,
thats correct, I'm looking for one firmware running on all (known) ESP32 boards.
Right now, I need a change in ESP-IDF.
In actual version there is an option to use psram, but if no psram is found during startup, it aborts.
Better would be an option (choice) with abort or log missing psram only.
Just tested this, but its a change in ESP-IDF, so they need to accept.

Hardcoded value was for easy testing only :)

Hmmm, I could move the functionality to assign jsVarSize into function main of jshardware.c.
In there would be a switch based on heap size (or psram recognition) to assign "small memory VarSize" or "big memory VarSize"
Both values should be in ESP32.py.
Hmmm, have to check how these values will make it to platform_config.h. This should be no problem.
AFAIK Everything could be done without changes in jsvInit(jsvar.c), but I would prefer to make it more general. Means adding one more definition in ESP32.py, something like "board defined jsVarSize". This way we would add a more general functionality for other boards in the future.

What would you prefer ? Or is there another(better) option, which did not come to my mind ?
Anyway, I've a starting point now for more testing.

Hmm, for ESP32 I would prefer simple malloc solution.
I checked this in a first simple test(see code at the end) and in a first test it works fine.
But doing board specific changes in jsvar.c is not my favourite solution.

Anyway I'm still confused about the impact of 32bits.
In internals link and in source of jsvar I only find 12 byte or 16 byte.
There is a note JsVars for 32 bit refs are similar, but what does this mean ?
Same for build_platform_config.py, which checks for less than 1024 only.
In which case would we need 24 bytes instead of 16 ?

BTW is there a limit for variables ? I can see ESPRUINOWIFI has 7135.
What would happen with 10000 or 50000 jsvars ?
It's a kind of theoretical question, but having 4MB heap, .....

#ifdef RESIZABLE_JSVARS JsVar
**jsVarBlocks = 0;
unsigned int jsVarsSize = 0;
#define JSVAR_BLOCK_SIZE 4096
#define JSVAR_BLOCK_SHIFT 12
#else
#ifdef ESP32
JsVar *jsVars = NULL;
unsigned int jsVarsSize = 0;
#else
JsVar jsVars[JSVAR_CACHE_SIZE];
unsigned int jsVarsSize = JSVAR_CACHE_SIZE;
#endif
#endif

and this:

void jsvInit() {
#ifdef RESIZABLE_JSVARS
jsVarsSize = JSVAR_BLOCK_SIZE;
jsVarBlocks = malloc(sizeof(JsVar*)); // just 1
jsVarBlocks[0] = malloc(sizeof(JsVar) * JSVAR_BLOCK_SIZE);
#endif
#ifdef ESP32
jsVars = (JsVar *)malloc(33600);
jsVarsSize = 2100;
#endif
jsVarFirstEmpty = jsvInitJsVars(1/first/, jsVarsSize);
jsvSoftInit();
}

hmm, we have 2 versions_

• esp32 wroom, here we fight for each byte
  
• esp32 wrover, here we have plenty of memory
  I would support one solution which supports all.
  
  

Would it be possible to replace static allocated block with malloc allocated block ?
In that case it wouldn't be resizable, between us, I would pay this price :-).
My understanding of JsVars is poor, would 32 bit reference be a problem ?

My expectations for speed is the same. Espruino supports an option to move all WIFI and BLE memory to psram. I'm pretty sure, they would not do this, if its much slower.

AFAIK, RESIZABLE_JSVARS are set for linux only.
Would it be possible to use this for other boards, like ESP32, too ?
I've some boards with additional psram, so memory is available like crazy.
Since psram needs a driver, its not available from start, means cannot be used for statically allocated block

Idea would be to check available heap during init and based on that malloc, memory for JsVars.
There would be a definitions in board.py for large heap and for small heap.

If something sounds as easy as this, usually there are some hidden problems,....
Any comment ?

some weeks ago, I ordered lolin32 pro board
This is a board with ESP32 wrover, which has additional 4mb psram, sdcard and connector for lipo, priced less than 8€
Bad news, this is not available anymore on Aliexpress :-(
Found some chats telling it becomes too hot, which is not the case with mine.

Anyway, with some help from espressif (ESP_ANGUS), I got it working.
Have to figure out eventually, how to handle psram for Espruino

Got an ESP32 wrover board and tried to get Espruino running.
Main idea was to use additional PSRAM for jsvars.
Problem is, I ran into memory problems, exactly the problem I tried to avoid :-(
Espressif told this:

What happened here is that you have filled up your internal memory
with static variables up to the point where there is no room anymore
for the 32K pool of reserved DMA memory.

I've in mind about a similiar problem (for ESP8266 ?).
Any idea, what I can do ?

First of all, BLE is work in progress. From time to time changes are uploaded.
At same time, esp-idf is changed very often.
Since this is my hobby only, please don't expect a full blown up implementation soon.
Your problem seems to be one of those changes in esp-idf. Sequence of calls during setup (and params for release ??) changed.
You could try this

void jsble_init(){
	esp_err_t ret;
    
	ret = esp_bt_controller_mem_release(ESP_BT_MODE_CLASSIC_BT);
	if(ret) {jsWarn("mem release failed:%x\n",ret); return;}
	
	esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT();
    ret = esp_bt_controller_init(&bt_cfg);if(ret) {jsWarn("initialize controller failed:%x\n",ret); return;}

	ret = esp_bt_controller_enable(ESP_BT_MODE_BLE);if(ret) {jsWarn("enable controller failed:%x\n",ret); return;}
	
	ret = esp_bluedroid_init();if (ret) {jsWarn("init bluetooth failed:%x\n",ret);return;}
    
	ret = esp_bluedroid_enable();if (ret) {jsWarn("enable bluetooth failed:%x\n",ret);return;}
	
	ret = esp_ble_gap_register_callback(gap_event_handler);if (ret){jsWarn("gap register error:%x\n", ret);return;}

	ret = esp_ble_gatts_register_callback(gatts_event_handler);if(ret){jsWarn("gatts register error:%x\n", ret);return;}

First of all before returning back to business, a happy new year !!
Hope you enjoyed vacation with your family.
My vacation will start in less than 2 weeks, so let me write some lines before.

Started porting of GATT Client for ESP32 and found a lot usage of CENTRAL_LINK_COUNT
What does CENTRAL_LINK_COUNT stand for ? Is it something like "GATT_CLIENT_ENABLED" ?

In wrapper often is an ifdef NRF52. First I expanded ifdef to support several definitions. This way I could have "ifdef" : "NRF52,ESP32"
But then I walked into the trap of having sd_ble-functions, which are not available for ESP32. To bypass this I defined new wrapper, for example for defintion of BluetoothDevice in an ESP32 specific file, where main change is ifdef to ESP32.

Since major part of source in this new file is copy/paste, this is not my favourite solution. Right now it helps me to go on. Any suggestion, how we should go on for the future ? Should we add some more definitions to bluetooth.h ? Other option would be some ifdefs in core functions, which I would not prefer.

One more point, for me to understand what sd_ble.functions are doing, is different naming. Looks like for NRF connect is used and for ESP32 it is open. Not a big deal, once you know about it. I wonder if there is a general naming convention.

Your description code come on board is wrong is not very helpful.
So check the usual problems:

• powersupply not stable
  
• reset the board manually several times
  
• try with other baudrate for flashing
  
• did you try to flash one of the examples from ESP-IDF ?
  
• last not least, the board could be damaged
  
  

Anyway, sounds like a problem of ESP32 and not of Espruino.
Try to get some help here https://esp32.com/
Please have in mind to give them a more detailled/helpful description of your problem.

Hello @Wilberforce
Tried to compare your sdkConfig with actual and found tons of differences.
Most of them are new to or replaced in V3
There are some left, which could have been changed by you.
Could you please check this list, and mark those, which are changed by you
I would recommend, we build a sdkconfig.default for Espruino. This would make it easy to follow changes in esp-idf

CONFIG_ESPTOOLPY_COMPRESSED=y
CONFIG_ESP32_ENABLE_COREDUMP_TO_UART=y
CONFIG_ESP32_ENABLE_COREDUMP=y
CONFIG_ESP32_CORE_DUMP_UART_DELAY=0
CONFIG_ESP32_CORE_DUMP_LOG_LEVEL=1
CONFIG_ESP32_APPTRACE_DEST_NONE=y
CONFIG_NEWLIB_STDOUT_ADDCR=y
# CONFIG_INT_WDT=
CONFIG_ESP32_DEEP_SLEEP_WAKEUP_DELAY=0
CONFIG_WIFI_ENABLED=y
CONFIG_ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM=0
CONFIG_FATFS_CODEPAGE_ASCII=y
CONFIG_FATFS_CODEPAGE=1
CONFIG_FATFS_MAX_LFN=255
CONFIG_FREERTOS_ASSERT_FAIL_PRINT_CONTINUE=y
CONFIG_FREERTOS_BREAK_ON_SCHEDULER_START_JTAG=y
CONFIG_LWIP_MAX_SOCKETS=10
CONFIG_LWIP_THREAD_LOCAL_STORAGE_INDEX=0
CONFIG_LWIP_SO_RCVBUF=y
CONFIG_LWIP_DHCP_DOES_ARP_CHECK=y
CONFIG_TCPIP_TASK_STACK_SIZE=2560
CONFIG_MBEDTLS_HARDWARE_SHA=y