Avatar for JumJum


Member since Oct 2013 • Last active Dec 2017
  • 95 conversations

Most recent activity

  • in ESP32
    Avatar for JumJum

    There are 22 breaking changes in this version. Not talking about changes in components, that we already know. In a first test, I don't even get Hello-World example running.
    With other words, it may take some time to get Espruino running again.

    • 1 comment
  • in ESP32
    Avatar for JumJum

    @wilberforce already did

  • in ESP32
    Avatar for JumJum

    Gordon did some changes in Bluetooth libs to support changes for other boards.
    Actual version in ESP32 branch supports this in a very early version.
    To get more take a look to md files in targets/esp32/docs/bluetooth

    There is also a minor change which helps for problems around jshGetTime. Hopefully this also helps for the DigitalPulse crash

    Bad news: no binary available.
    Espressif, ths guys behind ESP32 promised a new version before Chines next Year. And its a lot of work to get automatic generation running for new versions. I'm pretty sure @wilberforce, he is the one who knows how to do, will not waste his time for weekly changes.

    If you want to create your own binary, take a look to docs. There you will find a lot.
    To put some water into wine, ESP-IDF is under heavy construction. Expect changes that generate some errors during compiling.

    Anyway, there have been some guys asking how they could help to port Bluetooth to Espruino for ESP32. Its a good time now to start ;-)

  • in ESP32
    Avatar for JumJum

    In actual branch for ESP32 is a change in jshGetSystemTime() to fix problems with ESP32 internal time routine

  • in Porting to new Devices
    Avatar for JumJum

    During porting jswrap_nrf_bluetooth_updateServices to ESP32, I found calls to nrf relevant functions.
    ESP32 uses different walks through all of this. Most common point is use of UUIDs and handles.

    Searching for a better solution, found this jsvObjectGetChild(execInfo.hiddenRoot,"B­LE_SVC_D",0);
    Idea now is to move UUIDs and handles to this object to be more general. Value is already there.

    For testing of concept, this function was born. In my eyes it looks very complex.
    So I've 2 questions:

    • whats your feedback to hold uuids and handle in BLE_SVC_D
    • is there a better way to read value from BLE_SVC_D ?

    JsVar *jswrap_ESP32_get_Char_Value(JsVar *serviceUUID,JsVar *charUUID){
        JsVar *serviceKey; JsvObjectIterator serviceIt; JsVar *serviceData;
        JsVar *servicesData = jsvObjectGetChild(execInfo.hiddenRoot,"B­LE_SVC_D",0);
        JsVar *charKey; JsvObjectIterator charIt; JsVar *charData;
        JsVar *value;
            serviceKey = jsvObjectIteratorGetKey(&serviceIt);
                serviceData = jsvObjectIteratorGetValue(&serviceIt);
                    charKey = jsvObjectIteratorGetKey(&charIt);
                        charData = jsvObjectIteratorGetValue(&charIt);
                        value = jsvObjectGetChild(charData,"value",0);
        return value;
  • in Porting to new Devices
    Avatar for JumJum

    Sometimes, I would like to have the option using onRead. This would help to read/calculate/whatever this value, only if somebody(the client) asks for it.
    Anyway, since nRF does not support this in an easy way, I'll remove it from ESP32 port.

    Only way to set a new value I know about is nrf.updateServices, correct ?
    And the only way to read a value after being written by client is to keep track with onWrite, correct ?

    Description is always writable as far as I can see. Puck.js ignores writing a description. It could be done on ESP32, but I don't see a reason doing that.
    I'll keep it similiar to Puck.js and last not least its less work for me ;-)