Search results for:

I would liken this to saying operating systems based on Linux are open source, except when you start adding binary blobs like nvidia or printer drivers.

In this situation it is more like asking for open source firmware running inside your wi-fi card or inside usb bluetooth dongle when running Linux. Or asking for source of GSM/3G/4G/5G baseband firmware in your Android mobile phone.

Fortunately unlike with Nvidia in this case Nordic is quite open and participates in Zephyr as I linked before so there is fully open source BLE stack. Two in fact - Zephyr and Apache NimBLE that Pinetime guys are using.

If I read it right, the answer to my question is "no".

Well I tried to answer in practical way to the question that was asked in very philosophical "Richard Stallman"'s way. Yes the bluetooth stack that is currently running in the watch is not open source. And so is not the hardware, both its design (PCB) and the chips used (and Pintetime is same in this). You can draw the line between open and closed anywhere. If you decided bluetooth stack is where it matters then so be it :-)

bluetooth stack so called SoftDevice is provided from Nordic as a binary but it is fully documented and comes as part of the sdk and there is no issue to rebuild espruino from source with this. You can of course flash any other software over swd port using any opensource bluetooth stack like nimble used in mynewt or the one in Zephyr if you are opensource purist. Nordic also provides alternative SDK with Zephyr https://developer.nordicsemi.com/nRF_Con­nect_SDK/doc/latest/nrf/ug_ble_controlle­r.html where BLE stack is open source but this one is not used in Espruino for practical reasons. The binary stack works very well and is easy to work with, also it is certified by Bluetooth SIG and supported by Nordic, more details here https://www.nordicsemi.com/Products/Deve­lopment-software/S140 .

Basing your purchase decision on this is a bit strange since the watch is running javascript and bluetooth stack is several layers deep below.

Anyway if you would wish to port Espruino to Zephyr or Mynewt/nimble you certaily can.

In windows with WSL (1 not 2) I am using openocd build for windows to attach to the device via any of stlink/cmsis-dap/jlink usb dongles and then use gdb from linux command line e.g. arm-none-eabi-gdb espruino_2v10.83_E104BT5032A.elf -ex "target remote :3333" when run like this it will stop the code and I can investigate the state (backtrace, frame info, print, ...)
I can also open another connection to openocd from another command window (telnet localhost 4444) and use mix of openocd and gdb commands concurrently - openocd can read/write memory while the program is running and can restart the running program reset run without gdb noticing.

I guess VSCode with wsl integration could possibly debug the source via arm-none-eabi-gdb too but never tried this.

The key is the elf file, that one contains both the binary and symbols and links to source code files. Never used SES but quick googling gave this https://forum.segger.com/index.php/Threa­d/3487-Debug-elf-built-by-external-gcc-t­oolchain/

BTW it is not possible to single step nrf52 code once bluetooth is running, the softdevice has strict timing requirements so you cannot pause such code and continue, you can have breakpoint to investigate single issue but then you need to reboot.

However if you run NRF.sleep() to disable bluetooth before attaching debugger or remove BLUETOOTH module from build it should work.

You mean that the android app could act as BLE http proxy to do basically any REST call to the internet via the app? like this https://www.espruino.com/BLE+HTTP+Proxy ?

try to have the source files inside wsl, I see paths like /mnt/c/Users/robin/Espruino this is asking for trouble due to differencies in filename case sensitivity and windows file timestamps, see also https://docs.microsoft.com/en-us/windows­/wsl/filesystems (and someone having similar issues here )

since you also installed random stuff on windows side of things I'd try also to disable windows-wsl interoperability so you know only linux native stuff is run for 'make', 'arm-none-eabi-gcc' etc, not mixed windows/linux. This is configured in /etc/wsl.conf

$ cat /etc/wsl.conf
# after change run in powershell Restart-Service LxssManager
[interop]
enabled=false
appendWindowsPath=false

you can see if you have windows path prepended by running echo $PATH you should see only linux paths there. The easiest temporary fix for this is also to just change your path variable - before running make try something like export PATH=/home/robin/.local/bin:/usr/local/s­bin:/usr/local/bin:/usr/sbin:/usr/bin:/s­bin:/bin and exlude paths pointing to windows - /mnt/c/whatever

it is not that much or only about the data you get but about the algorithm you use to analyze that data, check the never ending step counting thread which has some promising results. so maybe the heart rate will be similar success in future

Heart rate is actually very similar problem, you search for periodic beats (instead of steps in step counting) and try to filter out the noise. In the heart rate case the noise is also movement of the watch on your wrist/skin when checking for pulses.

I think some proprietary libraries from HR sensor manufacturers try to correlate HR data with data from accelerometer to compensate the movement or at least ignore data temporarily when the movement is likely to affect the data a lot.

Still the new sensor has something to tune and configure via i2c unlike the old that just provided analog value without any way to configure it.

would it be feasible to receive info from a BLE chest band?

definitely yes

With recent merges nrf51 should have more free ram +488 bytes for recent MICROBIT1 build ~= 40 variables or more room in stack. Also some flash was saved during the process so even stock MICROBIT1 build can have 5 flash pages for storage now.

I don't have any microbit 1 so can't test but now also the hardware i2c can be removed from the build so current microbit sensor code could use software i2c possibly saving some further tiny bits of ram and flash (and even power?).

As for my build for generic nrf51 module I am back to using 300 variables and listing and viewing files in storage in WebIDE works :) Also I have 6 pages of storage with some extra features enabled like arrow functions, Inline C, watchdog

there is the microbit v1 and there is some thread about NRF51TAG here http://forum.espruino.com/conversations/­320879/ also some fitness tracker attempts here http://forum.espruino.com/conversations/­342982/

Is anyone still using it?

Just made a fresh 2.10 build for bare nrf51 module with 16K RAM and found it somehow broken. Also the number of variables in Microbit V1 board file proved to be quite unrealistic, I had to go far below 300 to let webide connect and read board info as the board JSON would not print due to low stack.

I tried some additional trimming to enable some other features (like native code via inline C or arrow functions to enable button to view storage files in WebIDE - It calls require('Storage').list().forEach(x=>pri­nt(JSON.stringify(x))); ). Again with that complex expression I had to reduce variables even more to 250 to allow even more stack so the JSON.stringify(x) inside that forEach would still produce some data instead of " ... "

Then with various builds I triggered unaligned jsVars array so it would crash completely at startup with new compact variables code. And when I got it somehow into shape and tried some bluetooth scanning code (NRF.findDevices, NRF.setScan) it again crashed/freezed/disconnected randomly so I noticed that nrf51 code path disables interrupts completely when working with JS variables which the SoftDevice doesn't like. After fixing that, NRF.findDevices would still not work correctly. It triggers low memory condition making console unusable with flood of "interrupted" messages even with simple NRF.findDevices((x)=>print(x),1000) with ~15 devices around. So looked into .data and .bss segment size usage and managed to reduce some usage to go up with variable to current 286 and 8 flash pages for Storage.

Now pasting simple code like

E.setFlags({pretokenise:1});

function findDevices(cb){
  var devs = {};
  var nonew=0;
  function add(x){
    if (!devs) return;
    if (x.id in devs) {
      if (++nonew>30) {NRF.setScan(undefined);setTimeout(()=>{­cb(devs);devs=undefined;},0);}
    } else {devs[x.id]=x.name;nonew=0;}
  }
  NRF.setScan(add,{active:true});
}

findDevices((x)=>print(x));

does not crash or produce console errors and finds all my devices around even when the function is in RAM. But adding any more code pushes it over the edge (like enabling watchdog and kicking it from setInterval). Moving the code to flash would certainly make it better, however not sure whether with ~290 variables I could e.g. draw to small OLED display while also having some bluetooth code there (=51822 fitness tracker usage).

Anyway, wanted to ask, is anyone still trying to use microbit v1 or any other 51822 device with Espruino? If yes, what use cases still work for you? Maybe some old Espruino versions are better?

I found there are some cheap 51822 boards on aliexpress claiming to have the QFAC 32K RAM variant so ordered few to test how usable that would be. However the 16K version module I have seems barely usable for any a bit more advanced code.

EDIT: boards from aliexpress arrived, they have QFAA with 16kB despite description and images claiming QFAC/32kB :-(
item link removed

Just looked and there isn't a startup_stm32f401xx.o file just a startup_stm32f401xx.s

Isn't arm-none-eabi-gcc: Command not found message in plain English? It cannot compile startup_stm32f401xx.s into startup_stm32f401xx.o without compiler.

You should run the provision script with board name that exists there i.e. PICO_R1_3
there is no boards/PICO.py file

If you are on Windows 10 then I'd suggest to do it in WSL - Windows subsystem for Winux with some Ubuntu inside. I have Ubuntu 18.04 in WSL1 and Ubuntu 20.04 in WSL2 and both builds Espruino, WSL1 with older Ubuntu is probably easier to setup.

see https://wiki.ubuntu.com/WSL

If you already have WSL (previously called Bash on Windows) (because of /mnt/c/Users/robin/Espruino?) then I don't understand why you try to install gcc toolchain on windows side. Maybe even running Espruino provision script would get it for you?

Or are you using mingw? Then I'd recommend installing WSL instead , version 1 should be enough. Mingw is good for building linux/posix stuff as windows native binaries, you don't need that with Espruino and WSL gives you better compatibility.

As for VSCode on windows side - there is WSL remoting plugin for VSCode so you can have Espruino inside WSL linux distro and VSCode can connect to it for editing and working with GIT. The ubuntu wiki page mentions it too.

Today I received the BW16 from https://www.aliexpress.com/item/10050013­20366011.html both the bare module and the board (total $9.70 with VAT+shipping). It arrived flashed with AT based firmware

# ATSV
[ATSV] OK:v2.4.1,amebaD v6.0a(Aug 14 2019)

and AT commands from https://github.com/ambiot/ambd_sdk/blob/­master/doc/AN0075%20Realtek%20Ameba-all%­20at%20command%20v2.0.pdf work.
can scan and connect to my 5GHz AP and ping some site on internet
can light up RGB led via ATSG=W,PA_x,1 where x = 12,13,14
so overall not bad :-)

thanks, got it, so LRCK goes nowhere but must be used to enable i2s and some clock is produced there. Then it is indeed not a good idea to connect this to reset pin :-)

So there are couple of pins not connected at all on 52840 dongle, one is P0.16 on the picture posted above.

just tried D16 on dongle clone (E104-BT5040U) and writing 1 or 0 does nothing, reading gives true by default and false when configured as D16.mode("input_pulldown"), so I guess the pin is floating. D23.write(0) reboots to bootloader indeed

I guess you can just pick any pin that's free (for the dongle, maybe one that's on a pad underneath so you don't accidentally use it?)

I never used neopixels so don't know what -DNEOPIXEL_LRCK_PIN=23 does and what this LRCK pin is used for. It is not good idea if it outputs low - that will reset the dongle. Was thinking you really use it for something and connect it to the leds - so not sure what "don't accidentally use it" means :-)

What should the designation be for pins such as 1.10 thru 1.16 ?

1. prefix is +32, 1.10=D42
   

oh, cool, early bird already gone, looks like there is some interest :-)

At this point, powering down is the only option.

The dongle is documented here https://infocenter.nordicsemi.com/topic/­ug_nrf52840_dongle/UG/nrf52840_Dongle/in­tro.html?cp=4_0_5 and there is also link to download schematics. Not sure if it helps but I know that some pins (more than just one) are tied to reset pin so the module can reset itself to bootloader (led is glowing) by setting pin. Maybe that's what happened to you and it is waiting in bootloader?

EDIT:
pins 25,23,21,19 are tied to reset => -DNEOPIXEL_LRCK_PIN=23 in board file is not a good idea with the dongle.

is there any way to activate logs or see a console as in WebIDE?

you can actually connect via WebIDE in different window tab and there are some messages there then, found it by coincidence that I can use webide while connected via https://banglejs.com/apps/ - I guess Chrome reuses same connection. It feels odd, not sure if this is bug or feature.

EDIT: googled for it and found https://stackoverflow.com/questions/6730­6288/pwa-web-bluetooth-api-from-page-to-­another and found similar comment "Accessing the same device from multiple pages is not supported and the fact that it seems to partially work is more of a bug than a feature. "

it is not needed, it goes to sleep automatically once there in nothing to do in event loop

EDIT:
or you can check what bangle poweroff does here https://github.com/espruino/Espruino/blo­b/master/libs/banglejs/jswrap_bangle.c#L­4078
for lowest power state, but not sure this is something you'd want. This wakes up from off state by gpio trigger, not sure if RTC could do it too and whether with RTC turned on it would save something compared to ordinary sleep with advertising off.

Is there any way to set a pin high in the board definition file

not directly but I thought I already provided solution above when you asked for the first time :-)

anyway, without any code you could also make D15 into fake LED or second button and set it as inverted as that could produce initial state being high

spi over the (i2c?) expander may be slow. spi can be shared with otherdevices you just need extra CS pin and have just one of them selected. On P8 smartwatch (or PineTime) the display and flash use shared spi pins and it works pretty well even when espruino code is executed directly from spi flash. It just needs to be careful with CS pins.

needed same thing for ID130 recently https://github.com/fanoush/ds-d6/tree/ma­ster/espruino/DFU/ID130Color see the jswrap stuff and board file, there is method marked init. it should probably go to libs but I put it right next to board file to boards/

for setting pin high this is not best example, better see this https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x/jshardware.c#L688­

yes they are 1:1

well, it builds full hex file automatically that should include softdevice+app+bootloader+bootloader settings with correct app checksum+uicr
so flashing just that one should do it.

just bootloader + app from bin or app hex file is not enough

$ hexinfo.py espruino_2v09.119_SMAB5.hex
- file: 'espruino_2v09.119_SMAB5.hex'
  entry: 0x1000F539
  data:
  - { first: 0x00000000, last: 0x00000963, length: 0x00000964 }
  - { first: 0x00001000, last: 0x0001EBEF, length: 0x0001DBF0 }
  - { first: 0x0001F000, last: 0x00060313, length: 0x00041314 }
  - { first: 0x00078000, last: 0x0007B953, length: 0x00003954 }
  - { first: 0x0007E000, last: 0x0007E322, length: 0x00000323 }
  - { first: 0x0007F000, last: 0x0007F322, length: 0x00000323 }
  - { first: 0x10001014, last: 0x1000101B, length: 0x00000008 }

Looks nice and useful. Is there also color attribute? Or one could separate layouts per color and do g.setColor between.

EDIT: oh yes, there is col,bgCol documented in https://raw.githubusercontent.com/esprui­no/BangleApps/master/modules/Layout.js

However now I see there is lot of "Bangle." calls inside so it is not so universal and reusable for other devices.