Replies: 2 comments 3 replies
-
|
Lots of stuff here. Approaches that get deep into ESP32 specifics are less interesting to me. XS debugging support is flexible enough to do what you want, and do so in a way that is light and portable. I'm just going to share some information about the debugging protocol and xsbug. That should help correct some misunderstandings and, I hope, set you on a path towards a solution. xsbug can support any number of virtual machines. You've seen this when debugging works on ESP32. Each virtual machine connects to xsbug with its own TCP socket. When debugging a device over serial (normal ESP32 case), In the simulator, each virtual machine connects directly to xsbug using a TCP socket. There is support in the ESP32 host for connecting to xsbug over Wi-Fi. It works, though it isn't used often so it may need a little maintenance. (Fun fact: ESP8266 supported debugging over Wi-Fi before debugging over serial) A virtual machine can connect to and disconnect from the debugger at any time. The default behavior is to do this at start-up. Here's a small program that connects/disconnects every 5 seconds. main.js import Timer from "timer";
class Debug {
static isConnected() @ "xs_debug_isConnected"
static connect() @ "xs_debug_connect"
static disconnect() @ "xs_debug_disconnect"
}
let count = 0;
Timer.repeat(() => {
if (Debug.isConnected()) {
trace(`goodbye #${++count}\n`);
Debug.disconnect();
}
else {
Debug.connect();
trace(`hello #${++count}\n`);
}
}, 5000);** debugmethods.c** #include "mc.xs.h" // for xsID_ values
extern xsBooleanValue fxIsConnected(xsMachine* the);
extern xsBooleanValue fxLogin(xsMachine* the);
extern xsBooleanValue fxLogout(xsMachine* the);
void xs_debug_isConnected(xsMachine *the)
{
xsmcSetBoolean(xsResult, fxIsConnected(the));
}
void xs_debug_connect(xsMachine *the)
{
fxLogin(the);
}
void xs_debug_disconnect(xsMachine *the)
{
fxLogout(the);
}manifest.json {
"include": "$(MODDABLE)/examples/manifest_base.json",
"modules": {
"*": [
"./main",
"./debugmethods"
]
}
}If you have multiple ESP32 devices connected to your computer, you can debug those at the same time with xsbug. You'll have to launch serial2xsbug for each in separate console sessions. console session 1 console session 2 etc. Since xsbug connects with TCP sockets, you can also have serial2xsbug connect to xsbug running on another machine: For your scenario, assuming the Wi-Fi debugging support on-device works, you could have MQTT send a command to connect to a debugger running on a specified IP address. |
Beta Was this translation helpful? Give feedback.
-
|
Ah, thanks, this is very helpful! I agree that an XS/JS-level solution is more interesting than esp-idf. I got thrown off about the multiple machines connecting to xsbug by mcconfig. I ran two of those and I believe the makefile kills all other connections. Or maybe I made a mistake. All this seems to indicate that the simplest set-up might be something like this:
The complement to all this would be:
The main issue with a single VM is that breakpoints are terminal since (I assume) the whole VM is stopped. So I really need one VM for the debug link and another for the app. |
Beta Was this translation helpful? Give feedback.
-
Yes. The makefile enforces "one at a time" use of
Yes: breakpoint are breakpoints. They stop the VM. ;) |
Beta Was this translation helpful? Give feedback.
-
|
I've been pondering things and browsing a lot of code... The big issues I see are flow control, halting the VM, and memory usage.
I'm wondering whether a more practical solution would be to just provide remote logging and perhaps On the how-to front I'm a little stuck about how to engineer hooking into the logging and/or debug connection... Starting with logging, it seems that I need to hook/replace An alternative could be to have a #define that causes At a lower level, to hook into the debug protocol I essentially have to duplicate the whole framing and polling machinery in I'm also not clear about a number of things related to the debug connection:
|
Beta Was this translation helpful? Give feedback.
-
|
I don't understand the first part, so I'm going to stick to that.
OK. It seems most of this gets better by using a separate worker for the one MQTT connection. That worker will trigger the breakpoint in the app VM. It will stay alive while the app is stopped at a breakpoint, so can do whatever you like to manage the flow control.
I don't follow this. |
Beta Was this translation helpful? Give feedback.
-
Most of my devices are experimental and in the field. As such they're basically always in debug mode, or ready to have a debugger connected. I'd like to explore how to best connect them to a "management and debugging server/console" over the network. The idea would be that some kernel runs on the device and manages an always-active connection to a server. This connection would be leveraged by logging, debug, and application messages.
I'm considering several options:
C-based kernel
For esp32 devices there is a lot of functionality available in esp-idf. The device could have a thread implemented in C that uses the esp-idf implementations of MQTT or WS to connect to the server. The C code would act as a host to XS, i.e., essentially be a beefed-up version of the current xsHost/xsPlatform. There is already code to run the debug protocol over TCP which could perhaps be leveraged.
The C code would provide MQTT abstractions to XS such that mqtt.js or similar could be tweaked to call into the C-managed MQTT connection instead of using the JavaScript MQTTclient, etc. A similar replacement of the WiFi modules could be provided to at least provide visibility into the WiFi connectivity.
The pros of this approach are:
The cons are:
Kernel as main JS VM
The connection to the server could perhaps also be implemented in the JS main VM. The JS kernel code would start running without debugger connection, connect to wifi and via MQTT to the server, and then start the JS app in a worker VM. It would set-up the debugger connection for the worker VM over MQTT.
Something that is confusing to me is that platform functions like
fxReceive(),fxConnect(), etc. have atxMachineargument, which makes them scoped to a VM yet there is only one serial connection. Is there a logical debug connection per VM and if so where is the multiplexing done.In my use-case what really matters is that the main VM can run without having a debug connection and that worker VMs can have debug connections. Dunno whether that's possible.
The pros of this approach are:
The cons are:
Logging-only implementation
Instead of implementing the xs debug protocol the host portion could hook into
trace()and exception handling and only provide logging functionality. This could be augmented with functionality to load/manage mods and, memory permitting, to runeval()on a remotely sent string. (This is essentially what I've been using for several years with Micropython.)The pros of this approach:
The cons:
xsbug issues
One other issue is that xsbug currently can only talk to one board. With the approach proposed here there could be many boards on the network that all have a debug connection. This raises a number of questions:
The last point is perhaps one of the central ones: what would be needed to allow xsbug to connect to a board that has been running for a while?
Beta Was this translation helpful? Give feedback.
All reactions