The 'testOut.js' file is sent down using c-code in our devices. These are industrial terminals using an ARM CPU. This download works as it should : connecting, waiting for the prompt then copying 'testOut.js' byte by byte down to Bangle.js 2. Bangle.js 2 responds as it should, so nothing wrong there.
It is the 'testOut.js' file that is already 'wrong' : the erroneous bytes C3 B9 C3 B0 are the UTF8 representation for 'ùð' : ( https://onlineunicodetools.com/convert-unicode-to-utf8 ), and not the original F9 Fo. So using another way for download will not change anything I'm afraid.
For now, I've changed my code to avoid strings with binary 'characters', using a btoa-version of the binary values. For the example above, this comes down to :
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.
The 'testOut.js' file is sent down using c-code in our devices. These are industrial terminals using an ARM CPU. This download works as it should : connecting, waiting for the prompt then copying 'testOut.js' byte by byte down to Bangle.js 2. Bangle.js 2 responds as it should, so nothing wrong there.
It is the 'testOut.js' file that is already 'wrong' : the erroneous bytes C3 B9 C3 B0 are the UTF8 representation for 'ùð' : ( https://onlineunicodetools.com/convert-unicode-to-utf8 ), and not the original F9 Fo. So using another way for download will not change anything I'm afraid.
For now, I've changed my code to avoid strings with binary 'characters', using a btoa-version of the binary values. For the example above, this comes down to :
So I'm in the clear for now, but this is a bit of a clumsy workaround of course.