Avatar for ddm

ddm

Member since Sep 2016 • Last active Oct 2016
  • 3 conversations
  • 10 comments

Most recent activity

  • in Porting to new Devices
    Avatar for ddm

    Right! I had not thought of that... :)

    I have 2 goals (not mutually exclusive):

    1. avoid repeating ADC=D1 in every program (convenience)
    2. avoid "burning" JS variables on simple aliases (resource optimisation)

    I guess this solution addresses 1. but would there be a way to address 2. as well ?

  • in Porting to new Devices
    Avatar for ddm

    Assuming that the MCU is already supported by Espruino (STM32, ESP8266, nRF5x etc.), how would one define pin aliases (e.g. ADC=D1) without sacrificing a JS variable (e.g. RAM-constrained board) ?

    It does not seem to be sufficient to add

    devices = {
      'ADC' : { 'pin' : 'D1' },
    };
    

    to MYBOARD.py to have ADC automatically available as a global variable in JS as an alias to D1

    • 10 comments
    • 347 views
  • in Porting to new Devices
    Avatar for ddm

    I'll post further design questions on the issue directly.

  • in Porting to new Devices
    Avatar for ddm

    I could have a stab at a pull request if that helps. The nRF SDK has plenty of example code and I should be able to figure it out.

  • in Porting to new Devices
    Avatar for ddm

    Another possibility would be to set value to some observable object and have updates be automatically reflected in the characteristic but it may overly complicate things.
    An explicit write seems to be simpler to use and document...

  • in Porting to new Devices
    Avatar for ddm

    The first solution seems straightforward to me. It would make using the REPL to test value updates very convenient.

  • in Porting to new Devices
    Avatar for ddm

    The way to expose BLE services on nRF devices is to use NRF.setServices (cf. doc).

    It is possible to set broadcast: true for broadcasting but not notify: true. The fix to make it available is pretty straightforward:

    @ jswrap_bluetooth.c:1420 @ void jswrap_nrf_bluetooth_setServices(JsVar *data) {
           memset(&char_md, 0, sizeof(char_md));
           if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "broadcast", 0)))
             char_md.char_props.broadcast = 1;
           if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "notify", 0)))
             char_md.char_props.notify = 1;
           if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "readable", 0)))
             char_md.char_props.read = 1;
           if (jsvGetBoolAndUnLock(jsvObjectGetChild(c­harVar, "writable", 0))) {
    

    With the above fix, it is possible to set a characteristic to NOTIFY like so:

    NRF.setServices({
      0x0000: {
        0x0001: {
          value : "Hello",
          maxLen : 5,
          readable : true,
          notify : true
        }
      }
    });
    

    However, what would be the best way to update the characteristic's value? Calling NRF.setServices repeatedly does not seem to be the way to go.

  • in General
    Avatar for ddm

    Thank you for clarifying that: I bumped into that exact behaviour today. That said, stepping into the init routines seems to work fine. No luck debugging BLE advertising and services of course...

    I am still trying to figure out how to get around the limitation because it would make adding new Bluetooth and NRF-related JS functions easier.
    Eclipse is a heavy and complex beast but it is free and the ARM support keeps getting better. With a properly configured "debug perspective" you can get a lot done.

Actions