Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Shinya Ishikawa
    @meganetaaan
    This is kind of open source hardware. Over 20 enthusiasts started building the robot.
    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.
    Peter Hoddie
    @phoddie
    @meganetaaan - that's a big project! Nice work on bringing all that together. it is particularly cool that are you are using mods to quickly install new behaviors. Do you plan to publish documentation on the APIs available to developers creating their own mod?
    Daniel Ashcraft
    @dashcraft

    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.

    Peter Hoddie
    @phoddie
    You can use serial2xsbug to write preferences from the command line. Writing preferences relies on support in the host, which is available in debug builds.
    serial2xsbug /dev/cu.SLAB_USBtoUART 460800 8N1 -pref config.wifi="Moddable Guest"
    If you know the partition address,. you can write directly to it using esptool.py.
    Daniel Ashcraft
    @dashcraft
    Is it possible to set aside the exact partition for preferences? So as to always "know" where that partition address is to write to?

    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

    Peter Hoddie
    @phoddie
    Your project controls the partition map.
    Daniel Ashcraft
    @dashcraft
    Is it just the main.bin file that's needed for ota's?
    Peter Hoddie
    @phoddie
    Yes.
    The OTA can't change the partition map or boot loader, so just the one file is needed.
    Daniel Ashcraft
    @dashcraft
    Sweet, thanks!
    Henrique Bacelar
    @hbacelar8
    Hey everyone. I've been trying to find information on mcsim but it seems it is a bit scarce. Is it possible to use websocket on a mcsim device?
    Peter Hoddie
    @phoddie

    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 -m

    You 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 -m
    Henrique Bacelar
    @hbacelar8
    Hey, thanks for you answer. The thing is: I have a foder called simulators to which I point in order to load the devices on mcsim. On the manifest of my main application, I point to the mcsim.exe as a SIMULATOR so it is launched at simulation.
    The problem is that when I try to import Client from websocket on the JS file inside the simulators fold, xsbug breaks at mcsim/main.js inside the reloadDevices function at the following line
    let device = compartment.importNow(info.path).default;
    throwing the error that module websocket can't be found
    Henrique Bacelar
    @hbacelar8
    Basically, my application works great as a websocket server. I can communicate to it through a local html/js as a client. The problem is using an mcsim device as a client. I'm not able to use modules such as websocket inside it since it can't find it.
    Peter Hoddie
    @phoddie
    The WebSocket client and server are both in the same module. Either you can access neither (the module isn't being built) or both. But you say that you are able to access the server, but not the client?
    Henrique Bacelar
    @hbacelar8
    The mcsim is a moddable project by itself right?
    it is built when building moddable right?
    Henrique Bacelar
    @hbacelar8
    Sorry if I wasn't very clear. Let's focus on mcsim. On mcsim.exe, we can click on load simulators and select a folder containing a JS file and some assets like PNG images to load a custom simulator, right?
    Peter Hoddie
    @phoddie
    All true.
    Henrique Bacelar
    @hbacelar8

    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.

    Henrique Bacelar
    @hbacelar8

    It's like the mcsim project doesn't know the websocket module. I suppose it is that since in the manifest.json of the mcsim project, which can be found on

    $MODDABLE/tools/mcsim/

    doesn't include the manifest_net.json or anything related to the websocket module whatsoever

    Finally, when I try to do so and rebuild moddable, it won't build mcsim
    Peter Hoddie
    @phoddie

    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.

    Henrique Bacelar
    @hbacelar8
    I see. So, is there a way to establish a communication between these two completely separate JavaScript virtual machines? Because my plan was to use the websocket module for that, since on my hosted Moddable SDK project there is a websocket server opened. Currently, I'm sending packets (websocket client) from a complete separate project running on web environment in order to control the display on the simulator. If I could instead use the interaction with the mcsim assets...
    Sorry for extending on it, but any hint would be helpful
    Peter Hoddie
    @phoddie
    Just to be sure I understand, you don't particularly want to use WebSockets. You want to establish some communication between the simulator and the project it is running. The messages could be JSON, for example. Is that correct?
    Henrique Bacelar
    @hbacelar8
    Exactly. I was going to use WebSocket since the project mcsim is running already has a logic where the WebSocket module is used to open a server and receive packets from a web application running at localhost. In this web application, there are buttons created with HTML/CSS/JS that, when clicked, send a packet to the WebSocket server on the project. Now, I wanted to do the same but with the buttons I mapped on a .png layout imported on mcsim. So it doesn't particularly have to be WebSocket (especially now that you confirmed me it doesn't work on mcsim). I just need a way to send some data to the project the simulator is running from the simulator (mcsim) itself.
    Henrique Bacelar
    @hbacelar8
    Hence the need of establishing a communication.
    Peter Hoddie
    @phoddie

    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_two

    Now you can blink the light in the simulator, as shown below.

    blink.gif
    Henrique Bacelar
    @hbacelar8
    Peter, thanks a lot. That worker. I was able to implement it in my project. Is that kind of information documented?
    Peter Hoddie
    @phoddie
    Glad that works! The 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.
    I'm curious -- mcsim is pretty obscure. How did you happen across that and decide to start working with it? It is great that you did.
    Henrique Bacelar
    @hbacelar8
    The company I'm currently working at has a project using Moddable and 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.
    Peter Hoddie
    @phoddie
    Cool, thanks.
    Peter Hoddie
    @phoddie
    Probably worth mentioning.... that outdated project you refer to uses a different mechanism for communication between the simulator and the hosted project, one that is probably a better fit here. But, I can't discuss detail of commercial projects in public forums.
    Chris
    @cmidgley

    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)?

    Peter Hoddie
    @phoddie
    Welcome back!!
    Correct, 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.
    Chris
    @cmidgley
    That was my concern - no problem, it was just for debugging anyway.
    One more Q... any hints/thoughts on how to include an Arduino CPP library (in my case, LoRa library) in the build so I can add the XS to C stubs? I plan on rewriting it to ESP-IDF to avoid the Arduino bloat, but I was hoping to experiment / work with the interface for a bit first to refine how the new API should be designed.
    Peter Hoddie
    @phoddie
    If you just want to trace, you can safely use modLog and friends from most places (including the destructor).
    Chris
    @cmidgley
    Great - that will be a help.
    Peter Hoddie
    @phoddie
    (They are primitive, but that allows them to safely used in more places.)
    Are you asking how to add a C (or C++) source file to your build?