Search results for:

Thanks Gordon. Seems good now. I did have to jump in and delete the two json files as they were still there when I tried to add an alarm after doing the firmware update.

Also, would be good to add the banglejs instruction link to this page: https://www.espruino.com/Download

Thanks for tracking that down, I'm pretty sure I'm getting the same thing. The alarm stops saving sometimes, but when I delete alarm.json the alarm I was trying to add reappears of its own accord.

It's happy now that it's merged. 👍

Alright, thanks, I'll have a go with a fresh download and see how it goes.

I'll put it in when I get home. I'm not really sure about the "uarte" issue though, I don't know if the change I made should be somewhere else or should be altogether different. (I'm pretty sure it shouldn't be in the SDK where I have done it though...)

jsiSetConsoleDevice was only being called once, so it looked like it's something to do with Espruino->Bluetooth rather than something weird happening with the serial or USB ports. Figured it was a buffer not being cleared somewhere so I scanned through likely files until I found a candidate. Changed this in targets/nrf5x/bluetooth.c and it came good:

[#if](https://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);
    if (err_code == NRF_SUCCESS) nuxTxBufLength=0; //<- added this line
[#elif](https://forum.espruino.com/searc­h/?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

Interesting. I've loaded this onto a Particle Xenon to give the nrf52840 a spin (gave up on writing stuff for it in C. Nothing wrong with the Particle stuff, I've just been spoiled by Espruino :P). I can connect via serial and use the console, then I can switch it over to USB and use it there. However, I'm also getting the lines of:

><- Serial1
><- Serial1
><- Serial1

when trying the bluetooth UART. If I switch to USB, then try to connect via bluetooth, I get this instead:

><- USB
><- USB
><- USB

I'm connecting via the Bluefruit app on Android. Having some issues getting the espruino cli talking to it at the moment, the noble module seems to have some bugs but isn't being maintained any more.

Tossing "#define NRFX_UARTE_ENABLED 0" into nrf_drv_uart.h seems to have got it working. Probably not the best way of dealing with it, but I haven't managed to narrow down where it should be...

@urish I've had a go at compiling this but I've hit a wall and was wondering if you remember whether there was something extra that you did to get it to compile? I grabbed that branch from the repo, copied all of SDK_15.0.0 into targetlibs/nrf5x_15, copied all of the micro-ecc repository into the external/micro-ecc folder and then ran make clean && BOARD=NRF52840DK RELEASE=1 make. I'm running into this:

/tmp/ccwJqUDl.ltrans0.ltrans.o: In function `nrf_drv_uart_tx':
/home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:516: undefined reference to `nrfx_uarte_tx'
/tmp/ccwJqUDl.ltrans0.ltrans.o: In function `nrf_drv_uart_tx_abort':
/home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:549: undefined reference to `nrfx_uarte_tx_abort'
/tmp/ccwJqUDl.ltrans9.ltrans.o: In function `nrf_drv_uart_uninit.constprop.241':
/home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:466: undefined reference to `nrfx_uarte_uninit'
/tmp/ccwJqUDl.ltrans9.ltrans.o: In function `nrf_drv_uart_rx.constprop.202':
/home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.h:565: undefined reference to `nrfx_uarte_rx'
/tmp/ccwJqUDl.ltrans9.ltrans.o: In function `nrf_drv_uart_init':
/home/steven/projects/Espruino-NRF52840/­targetlibs/nrf5x_15/integration/nrfx/leg­acy/nrf_drv_uart.c:124: undefined reference to `nrfx_uarte_init'
collect2: error: ld returned 1 exit status
make/targets/ARM.make:2: recipe for target 'espruino_1v99_nrf52840.elf' failed
make: *** [espruino_1v99_nrf52840.elf] Error 1

Which isn't making sense as sdk_config.h has this:

[#define](https://forum.espruino.com/sea­rch/?q=%23define) NRFX_UARTE_ENABLED 0
[#define](https://forum.espruino.com/sea­rch/?q=%23define) NRFX_UARTE0_ENABLED 0

I don't think it's that no one's interested in boards with smd prototyping areas (or in free boards for that matter). I think there's a few other factors, you're also looking for people who:

• want to solder and not just use breadboards/jumpers
  
• are up for trying a non-official board
  
• don't need something wireless (Gordon's last three boards were all Wi-Fi/Bluetooth)
  
• are comfortable with flashing firmware
  
• don't want something tiny
  
• don't already have a preferred board for prototyping
  
• browse this forum frequently
  
  

There are probably few people fulfilling all of the above. :/

Hmm, not sure about that one. The code looks good, but the error message is indicating some of the code didn't make it, no idea why, I've never had an issue with sending code (to official boards) before. Might need @Gordon 's help. I'd recommend power cycling both your computer and the Pixl if you try again in the meantime, might be a Bluetooth connection issue.

No problem. :) Yeah, I've seen a few other people miss that before. FYI, the left side is running commands directly on the board via a console, if a module isn't on the board yet, the board can't grab it. The right side will search your code for "require" and send the modules you need to the board before uploading your code.

Hi Nick, are you typing this into the left hand side or right hand side of the IDE? Most modules aren't built into the firmware, the IDE loads it onto the board when you upload code from the right hand side. You could try typing the same code into the right hand side, or type

require("DS18B20") 

into the right hand side and click upload, which will load the module, then type your code into the left hand side.

All good, thanks for looking. 👍

It's in the spec and I've seen it done, it doesn't seem to be a common thing though. Most devices only have a single temperature reading, magnetometer or whatever.

I was looking at how to have a bunch of generic I/O using the standard characteristics. No big deal for me to use 128 bit UUIDs or do it some other way, I was just trying not to reinvent the wheel.

BLE seems to support multiple of the same UUID for services and characteristics, for example you could use the automation IO service with 4 digital characteristics. With Espruino, specifying the services as an object seems to prevent that as the keys won't be unique, ie:

NRF.setServices({
  0x1815: { // automation
    0x2A56: { // digital
      readable: true,
      value : 1,
    },
    0x2A56 { // digital --> gets ignored as it's a duplicate key
      readable: true,
      value: 0
    }
  }
});

Is there any way around this?

I definitely swapped the ch340g pins a few times to be sure. Not sure if I swapped the pins on the pl2303hx, but both pins had the same voltage on when measured. All good for me now that I found one that works, but could be a bit harder to work out for someone who doesn't have a pile of random usb-uart modules lying around.

I flashed the espruino_1v97.99_nrf52832.hex travis build to an MDBT42Q module to give it a spin but couldn't connect via serial. I can connect to it via BLE but serial just wasn't working. I found the notes about it needing to see 3.3V on D8 so I checked it out and found that my CH340G (clone?) only had about 1.7V on RXD. I grabbed another USB-serial module, this time a PL2303HX (clone?) and found only about 0.6V on RXD. Finally tried a CP2102 (clone?) and it worked fine with 3.3V on RXD in idle.

My reference devices are all off aliexpress and not necessarily reliable adherers to good UART practices, but detecting full voltage on that pin might not be a good indicator of when a serial connection is there. Maybe checking for >0.5V using the ADC would be more reliable? I imagine this would affect a puck-js as well, I can't test on mine because I've got the pins already soldered to something.

Not a fan of the arduino footprint. It's a trade-off between being compatible with loads of shields and otherwise being quite useless with the irregular spacing and not breadboardable. My current favorite form-factor is the adafruit feather, but I think they've already got an nrf52 board...

Sounds like a good way to handle the situation. Your work is appreciated @Gordon, it's amazing that Espruino is all done by one person.

Having any sort of paid service at all might result in a sizeable revenue stream. I'm sure there are plenty of people on here that feel like they get a lot more value out of espruino boards and software than the cost of buying a board or two. Being able to sign up to a service that you don't 100% need, but is cool and makes you feel you're giving back can work.

Maybe something like a basic/silver/whatever membership could give you a vote on newest features, early access, forum badge and all that. Then a gold/premium membership might get you priority support, automatic custom builds, fancier forum badge.

I don't need a cool forum badge, but I'd sign up for one to support Espruino because it's awesome...

Thanks for another year of awesome @Gordon, have a great holiday!

@user70533 the espruino website has a lot of info for getting started. http://www.espruino.com/Modules shows how to use modules and http://www.espruino.com/Reference has details about everything built-in. On the whole, I've been able to easily port code between node and espruino and just replace the modules and their calls with equivalents, it didn't take long to get used to. Definitely a lot easier, more powerful and faster than making a jump to writing c for arduino, and having a command line to work with on your microcontroller is amazing!

For reference, I think this the last time espruino with freertos was attempted:
http://forum.espruino.com/conversations/­276160/#comment12578162

I'm not sure that node-red is really used for "application development". I'd actually consider it closer to something like ladder logic (which definitely isn't fading from the scene). It's more about having some inputs and outputs and visually and clearly defining the logic connecting them, rather than trying to skip out on coding.