Avatar for fanoush

fanoush

Member since Jul 2018 • Last active Jul 2024

Most recent activity

  • in Bangle.js
    Avatar for fanoush

    I'd take it but only if no one else really wants it. If anyone else wants it, then please take it as I already have many other devices to play with. I even do have one Bangle 1 that I did not take apart so I can test everything except stuff that may brick the device like the DFU bootloader.

    So the only use for me for this device would be the rare occasion when I want to test changes in Bangle 1 DFU bootloader. One such change I wanted to test is this https://github.com/espruino/Espruino/com­mit/a55878ab0bfa557476bd45a8d78527f5fc6f­8511 - the firmware upgrade from SPI flash feature which is there for Bangle 2 but is not there for Bangle 1. But otherwise the device would sit in the drawer unused.

  • in Bangle.js
    Avatar for fanoush

    hcitool lescan may show it if the watch is advertising. It is not advertising by default when something is connected to it but this can be changed (via whenConnected option of NRF.setAdvertising).

  • in Other Boards
    Avatar for fanoush

    As for SWD - there are official docs from ARM but recently I found very nice document that describes SWD a bit better and there is even example source code for all needed bits
    Google for "AN11553 Serial Wire Debug (SWD) programming specification" currently it is here
    https://community.nxp.com/pwmxy87654/att­achments/pwmxy87654/lpc/55224/1/SWD%20Pr­ogramming%20AN11553.pdf

    as for the CMSIS-DAP binary not working, that is strange, should work in all STM32F103 based dongles that come with STM32 STLINK V2 firmware (= must have same compatible pinout). I flashed it to many such clones and so far it always worked, maybe you are not erasing flash before flashing the binary? Not sure what DAPlink is but other USB dongles from aliexpress that already come with some CMSIS-DAP firmware may have different pinout.

    the swd.js I have there is not latest version, it is a bit slow and experimental, I have other version with more code moved to native Inline C code but that needs modified Inline C compiler to recompile from source so I did not publish it there but it is here https://gist.github.com/fanoush/4a5dcf77­7503461297cedf7e21e3c6b3 I tried to call JS GPIO Pin functions from native code to have platform independent way to do GPIO (so that same Inline C binary blob would run on nrf52 and STM32). But maybe the JIT is now good enough to replace it.

  • in Other Boards
    Avatar for fanoush

    Maybe checking E.getAnalogVRef() going below 3.3V could signal empty battery.

    Since that time I had simple interval checking voltage every second and toggling LED if it is below 3.27V and today I noticed it started blinking and voltage is 3.18V now. So it lasted about 2 months on single charge just advertising and sitting on table (Date() says February 25 1970), that is very similar to smartwatches like Magic3. And even if I can't measure battery voltage directly the getAnalogVRef can be used to detect low battery when it gets below 3.3V.

  • in Bangle.js
    Avatar for fanoush

    from the post I was guessing the nrf53 issue was not Espruino related at all and it was just a random nrf53 question

  • in Bangle.js
    Avatar for fanoush

    It is a compromise between RAM requirements of bluetooth stack and compatibility and speed, 128 (=MTU131) should be plenty for anything. speed can be affected by other parameters too like connection interval, it is not so clearcut that more is better in this case. you can change it in board file but it also needs tuning of APP RAM BASE
    https://github.com/espruino/Espruino/blo­b/master/boards/BANGLEJS2.py#L51
    when you set the base too low firmware will not start. you should also decrease variables for same amount of bytes (1 JS variable is 13 bytes). as Bangle supports multiple connections, increasing MTU by 128 needs many times more of RAM to support that.

  • in Bangle.js
    Avatar for fanoush

    https://github.com/espruino/Espruino/com­mit/5be8869ae36b7d9fe955e1b1071b9f8a58a0­38cf

    v21.124
    This is the culprit, but I have no idea why, it doesn't seem like it should be the culprit.

    Good find. The first change looks harmless if the SYSCLK_FREQ is divisible by 1000 (which it maybe is - 64000000 for nrf52?). but the second is now multiplication by small floating point number with low precision so maybe that may be the cause.

  • in General
    Avatar for fanoush

    If you only care about BLE then any nrf52 device you have is basically the same regarding radio power consumption. The power efficiency is slightly improved when using external 32kHz crystal and when builtin DC/DC converter is enabled (Bangle 2 has both) but the difference is not so big. The best device is one where you can actually measure the current. However I am not aware of any Espruino device that could measure it by itself. Maybe the 52832DK 52840DK Nordic devboards have something.

    My guess is that lowest power consumption would be when maintaining connection with long connection interval. Scanning for advertising may draw more on the scanning side as the radio receiver must be enabled for longer time. With a connection both sides are synchronized and wake only briefly and exactly when needed to maintain connection or send/receive data.

    Basic stuff can be estimated even with simple multimeter if it can measure down to few microamps. However the power draw is dynamic so the meter will jump or show some average.

  • in General
    Avatar for fanoush

    Yes it is possible :-)

Actions