ddm

Most recent activity

• Custom board definition (MYBOARD.py) and pin aliases

  @ddm started

  • 4 comments
  • 2,485 views

  @Gordon replied
• Custom board definition (MYBOARD.py) and pin aliases

  in Porting to new Devices • 8 years, 2 months

  

  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 ?

• Custom board definition (MYBOARD.py) and pin aliases

  in Porting to new Devices • 8 years, 2 months

  

  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

• BLE notifications on nRF devices

  @ddm started

  • 10 comments
  • 4,633 views

  @Gordon replied
• BLE notifications on nRF devices

  in Porting to new Devices • 8 years, 3 months

  

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

• BLE notifications on nRF devices

  in Porting to new Devices • 8 years, 3 months

  

  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.

• BLE notifications on nRF devices

  in Porting to new Devices • 8 years, 3 months

  

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

• BLE notifications on nRF devices

  in Porting to new Devices • 8 years, 3 months

  

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

• BLE notifications on nRF devices

  in Porting to new Devices • 8 years, 3 months

  

  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(charVar, "broadcast", 0)))
           char_md.char_props.broadcast = 1;
         if (jsvGetBoolAndUnLock(jsvObjectGetChild(charVar, "notify", 0)))
           char_md.char_props.notify = 1;
         if (jsvGetBoolAndUnLock(jsvObjectGetChild(charVar, "readable", 0)))
           char_md.char_props.read = 1;
         if (jsvGetBoolAndUnLock(jsvObjectGetChild(charVar, "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.

• Eclipse for native code debugging

  in General • 8 years, 3 months

  

  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.