Search results for:

Hi,
This is a bit of an app-store policy question:
I wrote an STL viewer app (STL is a relatively simple file format for representing 3d models and is often used in the hobbyist 3d printing realm). The app can read ASCII formatted STL files and displays a shaded 3d view of its contents that can be rotated around on the watch screen (see attached image).
I concede this is probably not the most useful app for a smartwatch, but perhaps it is still worth adding to the app store.
However, to get even marginally useful framerates for all but the very simplest models, I ended up doing a lot of the linear algebra and data manipulations in inline C using 32 bit floats and the processor's FPU (thanks to @fanoush for figuring out how to do that). For the FPU code to compile I had to host my own local Espruino compiler.
Therefore, in order for others to install the app on their watch the app store version would have to contain a binary blob of the compiled routines (encapsulated in a base64 string). Obviously I would provide the C code as well, but it would be much harder for the casual user to play around with the code than with a strictly JS-only app.
Any thoughts on this?
Thanks,
Marko

Hi,
Is there a limit to the number of arguments that can be passed to an inlined C function?
I get a message

Uncaught Error: Error Parsing signature at argument number 6

when attempting to set up an inline C function with 6 arguments. Everything appears fine up to 4 arguments.
Thanks,
Marko

Hi,
I am trying to use a local copy of your Espruino compiler hosted on github in an attempt to play with float32 FPU operations on a Bangle (inspired by a forum post by @fanoush here), but I am running into a few issues.
It seems that the code in the repository has not been updated since January 2019 and does not know about board type BANGLEJS (easy enough to add).
When attempting to point the web IDE to my (running) local copy at localhost:32766 I always get the error message "Error contacting server. Unable to compile code right now.". I can see on the localhost console that the compiler received and compiled the code, and it even outputs a binary blob (to the console) that, when cut and pasted appropriately into the IDE works perfectly, but it does not seem to communicate back the IDE.
Am I missing something obvious? My JS and node.js knowledge is pretty limited, so it is entirely possible that I am doing something boneheaded here...
Thanks,
Marko

Thanks. The C indeed wasn't optimized, but since I don't want to copy the whole file into RAM I probably won't pursue this path going forward anyways...

JavaScript novice and tinkerer.

Thanks, Gordon.
I did check the address returned by E.getAddressOf, it seems that, as you write, E.toString moves it into RAM, but it still does not seem contiguous (by examining it via peek8).
At any rate, I just tried to speed up the line counting, but I will stick to doing it in JS since I do not want to incur the cost of copying the whole file to RAM.
Thanks again for your quick reply. The Espruino ecosystem is an impressive piece of software!
Marko

In a piece of code I am working on I am trying to count the number of newline characters '\n' (i.e. the number of lines) in a string read from storage via something like the following:

var c = E.compiledC(`
// int sum(int, int)
int sum(int len, unsigned char *data){
  int s = 0;
  while (len--)
    if (*(data++)=='\n') s++;
  return s;
}
`);

function readFile(fn) {
  var fb = require("Storage").read(fn);
  var nlines = c.sum(fb.length, E.getAddressOf(E.toString(fb),true));
//  for (var i=0; i<fb.length; ++i) if (fb[i]=="\n") nlines++;
  return nlines;
}

Unfortunately my understanding of how the string returned from the require("Storage").read() call is stored in memory is clearly flawed since I am not at all getting the results I am expecting.
I am reading in a text file that I uploaded to storage via the web ide; the string is read in correctly, as confirmed by outputting it via console.log or using any of the other string functions on it. However, the internal representation of the chunk of memory is clearly not simple ASCII.
Or is the memory returned by read() simply not contiguous?
Thanks for any advise,
Marko

Quick update:
I was able to get it to work by starting up the hrm one second after GPS startup (via 'setTimeout') and by reducing the calls to 'draw()' to once a second (instead of every 500ms; not sure if this second change was strictly necessary).
It seems that the system gets overwhelmed when too many potentially call-back producing services get started simultaneously?

Hi,
I have noticed that the BangleRun app does not seem to be able to acquire a GPS fix or measure heart rates. When the app starts up, the green hrm LED briefly lights up (presumably per the call to Bangle.setHRMPower(1) in the app), but then goes off almost instantly. For a brief moment, the message 'fifo_full' flashes on the bottom of the screen in red and disappears. Furthermore, the GPS receiver never seems to acquire a position fix (admittedly I only waited - outside, with a clear view of the sky - for about 10 minutes, but other apps demonstrable get a fix more quickly; incidentally is every call to Bangle.setGPSPower(1) a cold start or a warm start of the ublox chipset?).
I don't know if these two events (the fifo message and the turning off of the hrm) are related, but I suspect they might be.
I am running firmware version 2v05.171.
Any advise on what might be causing this?
Thanks,
Marko