Consider using Worklets for ARC (and similar sensor cores), ie a Sensor Worklet

[kenchris]

In some cases sending IPC from one core to another might not be ideal, so it may be better to use something like a Worklet for writing logic directly on the sensor core.

https://www.w3.org/TR/worklets-1/

I am not sure Worklets are the best solution, but they seem better than existing Workers and new APIs are being ported to them, ie. https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal https://gist.github.com/bfgeek/fb40aeb569e1fc6276b3 etc

App side:

var arc = require("arc");

arc.import('sensor.js').then(function() {
  var node = new SensorWorkletNode({ options... });
  node.postMessage('startYourEngines', { data: "secret stuff" }); 
});

sensor.js: (showing ES6 for simplicity and comparison with existing specs/examples)

registerSensorWorkletProcessor(class extends SensorWorkletProcessor {
  constructor(options) { // Options is structured cloned across.
    this.stuff = null
  }

  onmessage(data) {
    this.stuff = data.stuff;
  }

  // This is invoked by the sensor core at each tick.
  tick(timestamp) {
    // This would work only if extended from SensorWorkletProcessor.
    this.postMessage('ticked!');
  }
});

[grgustaf]

I could be misunderstanding something, but we don't have JavaScript running on the ARC core, and I don't think it's practical to try doing it. It could be done, but it would mean double the JS engine overhead since there would be two copies. The way we fit BLE code on the A101 was to increase the x86 partition size to 256KB, decreasing the ARC partition size to IIRC 40KB. So with this setup there's no room to attempt that on the ARC side. So anyway we just write minimal C code there to service requests from the x86 side.

[poussa]

Yeah, this is not very practical for zephyr.js. It is more a browser api which we dont have. I dont feel we should start adding it just because browsers have it.

[zolkis]

We don't need to do IPC at JS level, we just need to have an async signature for the functions in question (AIO read, I2C operations) with the implementation encapsulating the IPC.

[grgustaf]

OK, yeah that's how things work now. The IPC is invisible to the JS level except in that a synchronous function will actually take some appreciable time, or an async version would take some observable time before coming back with the result.

[kenchris]

@grgustaf good points, but in future this might change and it might be able to, which is why I was thinking that this might make sense. As long as that is not the case, you can disregard this.

@poussa That was never the point :-) Anyway, Worklets are not just a browser API, it is more like a way to have code run elsewhere - where is not really defined (like it is for Workers / that is a design decision), ie, it might run 1) on another thread, 2) on the main thread with other code or 3) somewhere entirely else. It is also supposed to be more lightweight and support a small API surface (at least from browser PoV).

In that sense, if we wanted to have JS or WASM code running on another core, this might be a nice way of doing it.

[kenchris]

@zolkis yes that will work for most cases, but currently the async nature is not always optimal and we then instead need to batch things up. Sometimes it just makes more sense to do things the right place.

So in a perfect world where cores have plenty of RAM, this might be something to explore. Devs can decide where to run code, depending on for instance core frequency, that is how it is in the C API. Some APIs are available across app core and sensor core.

[kenchris]

Maybe with WebAssembly (WASM) the runtime/engine will be smaller (or at least can be compiled). In such a case, we could have WASM support for the ARC core and this could be a way to talk to it. WASM is supposed to talk to the same "native" APIs are JavaScript, but it is smaller, can be interpreted and possible compiled depending on platform. In that case you would just include the .wasm file instead of a .js one, I suppose