-
|
Moddable has its own simulator, but I'm interested in running my embedded code within a Linux Docker container. This is for the purposes of CI/CD automation testing and regular development. However, the current simulator seems to be mainly geared towards UI development and isn't able to run within Docker (which lacks a GUI environment). What I need is to be able to run a headless simulator inside Docker, with the ability to view the simulator's log output and UART communication within the simulator, whether this be through some sort of networking or virtual serial port. Could you provide me with some suggestions on how I might be able to achieve this? One approach I'm considering is running the image generated by Moddable in the QEMU provided by ESP. I would also appreciate any discussion on the advantages and disadvantages of this approach as compared to directly using Moddable's simulator. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
I made some progress on the QEMU path. By changing the external flash from QIO to DIO, it works out of the box.
|
Beta Was this translation helpful? Give feedback.
-
|
I'm impressed you have QEMU running! It would be great if you could teach the rest of us how to do that. Please. Yes, XS and the Moddable SDK run happily on an ESP8266, which only has about 45 KB of free memory total. We run VMs as small as 8KB for specialized purposes. So, 200 KB is plenty. Of course, the memory needs really depend on your project. All that said, depending on what you are testing you may still be able to use the simulator. It should still launch on a headless system. You can use xsbug-log ( |
Beta Was this translation helpful? Give feedback.
-
|
Okay, I've successfully managed to get everything running on QEMU, albeit with some tweaks and irregularities. Here are the details:
but this was not recognized. Hence, I had to manually patch the
However, there's some peculiar behavior in the ESP32 system. Let's consider the following code: void loop_task(void *pvParameter)
{
printf("#2=====%s:%s:%d: %dKB free memory\n", __FILE__, __func__, __LINE__, esp_get_free_heap_size() / 1024);
// XS initialization code
}
void app_main() {
printf("#1=====%s:%s:%d: %dKB free memory\n", __FILE__, __func__, __LINE__, esp_get_free_heap_size() / 1024);
xTaskCreate(loop_task, "main", kStack, NULL, 4, NULL);
}The #1 spot reports approximately 4MB of free memory, while the #2 spot reports only about 200KB. Interestingly, I found that if I continuously query inside the loop_task, it eventually recognizes more memory... like this: I'm unsure whether this is an ESP-IDF issue or it's related to QEMU. However, this workaround does function. I can prepare a flash with Mod host and an XS mod, and run them in QEMU. Notice that the XS engine has approximately 4MB of memory. Here's a sample output: |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for posting the details! I want to give that a try. I'm sure others will find it useful. Regarding the bizarre PSRAM behavior, did you consider opening an issue to report it? Something definitely seems wrong there. Regarding the SDKCONFIGPATH, the BUILD section defines the equivalent of environment variables so there can only be a single SDKCONFIGPATH. In your case, that is owned by the port |
Beta Was this translation helpful? Give feedback.
-
|
Also, I prepared a Dockerfile that packed Moddable and QEMU togheter: And this is a bash file runs "hello world" sample on QEMU (build using mcconfig, prepare the qemu image, launch qemu with the image) #!/bin/bash
set -e
ROOT="/root/moddable/examples"
PROJ_NAME="helloworld"
PROJ_ROOT=$MODDABLE/build/tmp/esp32/nodemcu/instrument/$PROJ_NAME
IDF_PROJ_ROOT=$PROJ_ROOT/xsProj-esp32
echo "=== Building esp32 binary ==="
cd $ROOT/$PROJ_NAME
mcconfig -i -p esp32/nodemcu # Notice we do not have -m flag, so it will not try to deploy to the device
echo $PROJ_ROOT
cd $PROJ_ROOT
# Patch sdkconfig.mc
sdkconfig_mc_FILE=$IDF_PROJ_ROOT/sdkconfig.mc
sed -i 's/CONFIG_ESPTOOLPY_FLASHMODE_QIO=y/CONFIG_ESPTOOLPY_FLASHMODE_QIO=n/g' $sdkconfig_mc_FILE
sed -i 's/CONFIG_ESPTOOLPY_FLASHMODE_DIO=n/CONFIG_ESPTOOLPY_FLASHMODE_DIO=y/g' $sdkconfig_mc_FILE
sed -i 's/CONFIG_ESPTOOLPY_FLASHMODE="qio"/CONFIG_ESPTOOLPY_FLASHMODE="dio"/g' $sdkconfig_mc_FILE
sed -i 's/CONFIG_ESP32_SPIRAM_SUPPORT=n/CONFIG_ESP32_SPIRAM_SUPPORT=y/g' $sdkconfig_mc_FILE
echo 'CONFIG_SPIRAM_BANKSWITCH_ENABLE=n' >> $sdkconfig_mc_FILE
# Patch main.c
main_c_FILE=$IDF_PROJ_ROOT/main/main.c
cp $ROOT/$PROJ_NAME/main.c $main_c_FILE
make build
echo "=== Merge Flash file ==="
cd $IDF_PROJ_ROOT/build
esptool.py --chip esp32 merge_bin --fill-flash-size 4MB -o merged_flash_image.bin @flash_args
MERGED_BIN=$IDF_PROJ_ROOT/build/merged_flash_image.bin
echo "=== Launching QEMU ==="
echo $MERGED_BIN
/opt/qemu/bin/qemu-system-xtensa -nographic -machine esp32 -drive file=$MERGED_BIN,if=mtd,format=raw -m 4M |
Beta Was this translation helpful? Give feedback.
Okay, I've successfully managed to get everything running on QEMU, albeit with some tweaks and irregularities. Here are the details:
https://github.com/espressif/qemu/releases/download/esp-develop-8.0.0-20230522/esp-qemu-xtensa-softmmu-develop_8.0.0_20230522-x86_64-linux-gnu.tar.bz2.esp32/nodemcudevice target as the basis for the build.[Glitch #1] I attempted to adjust the ESP-IDF project settings using
but this was not recognized. Hence, I had to manua…