## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
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:

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. 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? Chris @cmidgley I have the CPP file in the manifest/build, but of course I get errors on including Arduino.h. I added the CPLUS_INCLUDE_PATH to reference the Arduino includes, but then run into issues with missing defines / configuration. For example, currently it fails with: # cc LoRa.cpp.o cc1plus.exe: warning: command line option '-Wno-implicit-function-declaration' is valid for C/ObjC but not for C++ cc1plus.exe: warning: command line option '-std=gnu99' is valid for C/ObjC but not for C++ In file included from c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/avr/pgmspace.h:90, from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:28, from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14, from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4: c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/avr/io.h:711:6: warning: #warning "device type not defined" [-Wcpp] # warning "device type not defined" ^~~~~~~ In file included from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/USBAPI.h:25, from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:234, from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14, from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4: c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/avr/eeprom.h:41:3: warning: #warning "Device does not have EEPROM available." [-Wcpp] # warning "Device does not have EEPROM available." ^~~~~~~ In file included from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/USBAPI.h:27, from c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:234, from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14, from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4: c:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include/util/delay.h:92:3: warning: #warning "F_CPU not defined for <util/delay.h>" [-Wcpp] # warning "F_CPU not defined for <util/delay.h>" ^~~~~~~ In file included from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src/LoRa.h:14, from c:\Users\chris\Documents\Personal\poolidea\modtest\arduino-LoRa\src\LoRa.cpp:4: c:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:258:10: fatal error: pins_arduino.h: No such file or directory #include "pins_arduino.h" ^~~~~~~~~~~~~~~~ compilation terminated. I know the pins_arduino.h is just an include path, but the missing defines are more likely indicative of a more serious setup issue and likely I'm driving off the edge of a cliff....! Peter Hoddie @phoddie I'm skeptical that you are going to get Arduino code compiling under IDF. But that's your challenge. You can use the recipes feature of mcconfig to set additional build flags for certain files. It is an obscure feature, but it is also why our ESP8266 build works at all. The recipes named in the manifest are contained in$MODDABLE/tools/mcconfig, for example this is the strings-in-flash used on Mac and Linux builds.
Chris
@cmidgley
Thanks for the hint to recipes - I'll check it out. I know it's "possible" to get Arduino / ESP-IDF to work together, but was hoping to hear it was something you/others have done w/Moddable. Given that feedback, I'll refocus on porting to ESP-IDF. Thanks, Peter!