You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Einzenheim
@allObjects
The easy way to start and to get a feeling for the Espruino programming and implementation model is to take an Espruino board - such as the PICO - and write a module in JavaScript talking to the API of the DWM1001C module. You incrementally add API function by function and wrap it in a method / function the way it best serves a JavaScript usage context. This will not only get you very familiar w/ (constraints of) Espruino but also with the constraints of the DWM1001C module.
DWM1001C module was developed w/ a very specific purpose in mind and it shows it's full potential using Decawave's firmware. Afaiu, Decawave's firmware takes care of all the intrinsics that go with handling the accelerometer and UWB communication... in addition to what has to go on for BLE. The firmware runs on the nordic nrf52 chip. Even though the nrf52 chip is quite powerful, I'm not sure if - first - it has enough dynamic resources left - cycles - that can handle another two main tasks that are usually going on in an Espruino context - and second - has enough static resources left - memory, timers, etc. - that Espruino requires. And if it has, you have to wonder how much is then left for the actual application on the chip.
You may know that Espruino is also available on other boards that are mainly for communication - Wifi in this case - such as https://espressif.com 's ESP8266... a very popular and very affordable thing. The challenge there is that unique to communication timing matters a lot and therefore anything with communication has highest priority... and not much is left for anything else - last but not least, it is just a single processor / cpu / core. You find countless examples where things are tried in such frugal context but hit a wall when it is just too much to fit in to the 'window' left open for other things, such as the Espruino eco-system and the application. Not for nothing did https://espressif.com come up with the ESP32: it has two cores and lots more of memory and os-like firmware to become a platform for applications than rather 'just' a 'communication' module with some additional useful application components and firm/software.
Even if you achieve Espruino eco system to run on Decawave's DWM1001C module, the application has also to 'dance around' the underlaying constraints. That would be the same when you would have to care about the specifics outside of the Browser in your Web app - exactly the opposite what is pursued with JavaScript in a browser: independence of the layers underneath. This independence has it's price... and that's static and dynamic resources.
Last but not least you have to consider how licensing is involved. As much as open components are used as you can read at https://www.decawave.com/dwm1001-dw10001-dev-and-mdek1001-documents-source-code-android-application-firmware-image/ , there is a binary, not open licensed components and the requirement of always to be tied to Decawave devices / hardware.
The conversation's title is
which tells me to write a (node js like) JavaScript / software module to interface Decawave's DWM1001C module from an Espruino eco system. The module then becomes part of https://espruiono.con/modules library to expose DWM1001C module's function thru an API in JavaScript - like a language binding.