Avatar for fanoush

fanoush

Member since Jul 2018 • Last active Apr 2020
  • 5 conversations
  • 267 comments

Most recent activity

  • in Other Boards
    Avatar for fanoush

    The only issue is that I cannot connect to it from Chromium running on Raspberry Pi 4 both for SDK14 build an SDK15 build (maybe related to Bluetooth 5) while it works with SDK12 build.

    Recently I tried espruino on particle xenon (nrf52840) and I had same issues with conecting from Raspberry Pi 3 and 4 and found solution/workaround for this strange error. I cleared bluez cache in /var/lib/blueooth as per https://stackoverflow.com/a/43541073 and problem is gone. I had cached files for various devices more than year old there. Not really sure why Bluez caches stuff like this for so long (or at all). So now I can connect to any softdevice version used with espruino without issues.

    BTW I understand how it might affect things when switching different bluetooth versions (4 to 5) for same device and MAC address, however with particle xenon this was first connection ever that was failing, yet clearing the cache somehow helped too.

  • in Other Boards
    Avatar for fanoush

    its' default mode is still analog. I have no idea how to use input floating mode as default

    yes so that's fine, as I tried to explain in post #4, this is what espruino shows when pin is floating (i.e. is not set to input nor output)

  • in Other Boards
    Avatar for fanoush

    I was wondering if I could write it in inlineC

    yes

    to speed up the thing.

    Not sure your example would benefit from it. you can configure pins for output once and not each time and then you just set five of them, that doesn't look like expensive operation, see also https://www.espruino.com/Performance if speed is important.

    Anyway fastest way to do this is to write OUT,OUTSET or OUTCLR GPIO register directly from javascript via poke32 command. So you can prepare the value and write all pins via single write (OUT) or two writes (OUTCLR,OUTSET). See the help here

    So e.g. to clear pins 23456 via single write you'd write value 4+8+16+32+64 to OUTCLR via poke32(124,0x50000000+0x50c) or to set them to 1 you'd write same value to 0x50000508. When writing OUT register you'd need to take care of pins you don't want to change by reading the value before.

  • in Other Boards
    Avatar for fanoush

    oh, and to topic title name - input mode is not floating, input mode (at least on nrf52) is sensing the input and draws some power, to save battery it should be in disconnected mode if not used, then it is really floating. On powerup it is in such mode if not used.

  • in Other Boards
    Avatar for fanoush

    It will switch to input mode, try with pin.getMode() to see after calling digitalRead.

    Also there is now no explicit mode name to set it to be disconnected/floating again (e.g. like pin.mode("disconnected")). on nrf52 devices analogRead does that. In fact floating pins on nrf52 are reported as "analog" (even for pins 4-27 that cannot be used for analog reading) and pin.mode("analog") seems to set it floating/disconnected - at least on nrf52 platform.

  • in Other Boards
    Avatar for fanoush

    OK, so I removed #else and added similar code to two cases above

     [#elif](http://forum.espruino.com/search­/?q=%23elif) NRF_SD_BLE_API_VERSION==5
        uint32_t err_code = ble_nus_string_send(&m_nus, nusTxBuf, &nuxTxBufLength);
        if (err_code == NRF_SUCCESS) nuxTxBufLength=0; // everything sent Ok
     [#endif](http://forum.espruino.com/searc­h/?q=%23endif)
    

    and it seems to work fine, no lost characters and webide can connect. Then the nuxTxBufLength=0; // everything sent Ok is same for all three cases so final version is

        // We have data - try and send it
    
     [#if](http://forum.espruino.com/search/?­q=%23if) NRF_SD_BLE_API_VERSION>5
        uint32_t err_code = ble_nus_data_send(&m_nus, nusTxBuf, &nuxTxBufLength, m_peripheral_conn_handle);
     [#elif](http://forum.espruino.com/search­/?q=%23elif) NRF_SD_BLE_API_VERSION<5
        uint32_t err_code = ble_nus_string_send(&m_nus, nusTxBuf, nuxTxBufLength);
     [#else](http://forum.espruino.com/search­/?q=%23else)
        uint32_t err_code = ble_nus_string_send(&m_nus, nusTxBuf, &nuxTxBufLength);
     [#endif](http://forum.espruino.com/searc­h/?q=%23endif)
        if (err_code == NRF_SUCCESS) {
          nuxTxBufLength=0; // everything sent Ok
          bleStatus |= BLE_IS_SENDING;
        } else if (err_code==NRF_ERROR_INVALID_STATE) {
    
  • in Other Boards
    Avatar for fanoush

    Thanks for the hint, looks like for =5 it falls back to #else so I'll try <= or >= to do one of the other cases to see if it helps or look into what #else does exactly (as it looks quite different).

  • in Other Boards
    Avatar for fanoush

    But the code is just taken from git release and does not have a single line change. I am assuming that it should compile straightforward.

    from the compiler output it looks like some parts were compiled for different arm cpu, so maybe you tried to build it first without some options selecting nrf51 , 'make clean' will remove that

    BTW, you said s110 is not harder to add in current Esprunio? What is the procedure?

    The procedure is basically to become Espruino developer :-) Go over the github source and search (github search box in upper left corner) for S130 and S132 and possibly also NRF_SD_BLE_API_VERSION to get the picture of the complexity.

  • in Other Boards
    Avatar for fanoush

    tried same build just with NRF_SDK15=1 instead of NRF_SDK14=1 and I don't see that issue, webide connects fine from my android phone and process.env looks fine. The only issue is that I cannot connect to it from Chromium running on Raspberry Pi 4 both for SDK14 build an SDK15 build (maybe related to Bluetooth 5) while it works with SDK12 build. Console shows

    >>> Connecting to Espruino NRF52832DK
    BT>  Device Name:       Espruino NRF52832DK
    BT>  Device ID:         TNUKC6eQJyfyydDlywFgIQ==
    >>> Connected to BLE
    BT> Connected
    >>> Configuring BLE...
    BT> Got service
    >>> Configuring BLE....
    BT> RX characteristic:{}
    BT> ERROR: NotSupportedError: GATT operation not permitted.
    BT> Disconnected (gattserverdisconnected)
    ERROR: [notify_error] Connection Failed.
    >>> Connection Failed.
    
Actions