https://hackaday.io/project/181344/
Some of them just uses the case/schematics and Arduino libraries. And some others successfully built their application with Moddable.
A tweet list below shows their unique works based on my robot.
https://togetter.com/li/1759098
I'll keep providing the firmware in JavaScript for scalability and ease of robot application development.
I've been digging through docs and i am stumped although I'm sure the answer is in there somewhere.
Is it possible to write configs/preferences to a partition at flash time? If I compiled a moddable program that accepts preferences, I may make it easier
to do fleet provisioning if I can flash configs when I flash the compiled moddable program.
esptool.py.
I'm basically attempting to recreate this flow:
https://www.youtube.com/watch?v=ZsD59Tg2oCQ
for multiple devices, they're using esptool-js I believe
Yes, it is. Socket is implemented for all the simulators on macOS, Windows, and Linux. That allows just about all the network modules to work. For example, you can run the httpget example:
cd $MODDABLE/examples/network/http/httpget
mcconfig -d -mYou can run the WebSocket examples the same way. Unfortunately.... the websocketclient example currently throws an exception because the echo server it uses was recently shut down. But, the example is still correct... if you can find another echo server. ;)
cd $MODDABLE/examples/network/websocket/websocketclient
mcconfig -d -mlet device = compartment.importNow(info.path).default;
Great. So, in this JS file that is loaded by the mcsim (let's call it device.js), which contains code describing the interface and behavior of the simulator (making use of DeviceBehavior and DeviceWorker imported from DevicePane), I just can't import any module. In the beginning of the file, if I for example write
import { Client } from "websocket"xsbug will raise an error in the mcsim/main.js file when trying to load this device.js file in the reloadDevices function saying that module websocket can't be found.
Right, you can't do that. ;)
What you are overlooking is that within mcsim there are two completely separate JavaScript virtual machines. There is one for mcsim itself, which includes Piu and a handful of other modules from the Moddable SDK. The other virtual machine is for the hosted Moddable SDK project running in the simulator. That project includes whatever modules from the Moddable SDK that your project manifest uses, such as WebSockets. There might be a way to modify mcsim to include some other modules. But, we've never tried because we didn't intend for it to be used that way.
The simulator already has a communication path for you to use. Here's an easy way to see that.
Add these lines at the end of $MODDABLE/examples/helloworld/main.js:
screen.onMessage = function(msg) {
msg = JSON.parse(msg);
screen.postMessage(JSON.stringify({led: msg.button}));
}Then on the command line, do this:
cd $MODDABLE/examples/helloworld
mcconfig -d -m -p simulator/moddable_twoNow you can blink the light in the simulator, as shown below.
mcsim simulator is still considered experimental and so we haven't documented it yet. That said, it works well and we use it on nearly every client project we do, so maybe it is finally time to retire the venerable screen test (our original and still default simulator) and make the switch.
mcsim is pretty obscure. How did you happen across that and decide to start working with it? It is great that you did.
mcsim for simulation, but is kind of outdated. So I'm working on another project that uses Screen Test and this aforementioned WebSocket/HTML workaround to control the screen. So basically I'm working on the latter in order to fully migrate the simulation to mcsim, having all user interactions embedded on it and establishing its communication to the main application, which works fine now.
Hi @phoddie - been a while (just under a year!) but I'm finally back on my Moddable project. I had a simple question about destructors in XS in C. I see that the (xsMachine) isn't passed to the destructor (the object is the first parameter; perhaps it's in another parameter?) I currently store it in my object in the constructor, and then access it in the destructor like this:
void xs_example_destructor(void *data)
{
xsMachine *the = ((test *)data)->the;
xsTrace("In destructor\n");
}It seems to be working in my very simple tests, but I was concerned I may be accessing a pointer (to the) that could be freed / invalid at this time. Is this the correct way to access the or is there a better way (or, not allowed at all)?
the is not passed to the destructor. The destructor is invoked from deep within the garbage collector, which is a time when it is not safe to call XS. It might work sometimes. But, it isn't safe. None of the destructors in the Moddable SDK call XS in C APIs for that reason.