Avatar for JumJum


Member since Oct 2013 • Last active Feb 2018
  • 101 conversations

Most recent activity

  • in Porting to new Devices
    Avatar for JumJum

    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)

  • in Porting to new Devices
    Avatar for JumJum

    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](http://forum.espruino.com/sear­ch/?q=%23define) ESP_UUID_LEN_16     2
    [#define](http://forum.espruino.com/sear­ch/?q=%23define) ESP_UUID_LEN_32     4
    [#define](http://forum.espruino.com/sear­ch/?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;
  • in Porting to new Devices
    Avatar for JumJum

    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 :-)

  • in Porting to new Devices
    Avatar for JumJum

    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


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


    extern unsigned int jsVarsSize;


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


    if board.info["variables_mode"]:
      codeOut('#define VARIABLES_MODE_'+board.info["variables_m­ode"].upper() + ' // mode for allocating memory, standard is statically assigned');
      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
  • in Porting to new Devices
    Avatar for JumJum

    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...

  • in Porting to new Devices
    Avatar for JumJum

    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.

  • in Porting to new Devices
    Avatar for JumJum

    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.