Creating a target

[tve]

#989
If you've got questions while creating your new target, please lets start a different discussion topic for that.

You know me already 😆

Is it a "target" or a "platform" or a "sub platform" that I'm creating? I'm passing it to mcconfig's -p option, right? But in the source tree that stuff is under esp32/targets...

Copy the whole heltec_lora_32 directory to, let's say, custom. Then your build target would be esp32/custom.

Where? In the moddable source tree? I don't see anywhere I can specify where my sub-platform definitions live. How does that fare when I upgrade the moddable SDK? Assumes upgrade==git pull I guess...

I notice one definition of SPI pins in
https://github.com/Moddable-OpenSource/moddable/blob/public/build/devices/esp32/targets/heltec_lora_32/manifest.json#L17-L21
and a slightly different one in
https://github.com/Moddable-OpenSource/moddable/blob/public/build/devices/esp32/targets/heltec_lora_32/host/provider.js#L84-L91
(the SCK/clock pin in particular). Where are the defines in the manifest.json used?

So I took a stab at the sub-platform definition, looks pretty straight-forward. But of course I fat fingered something and the esp32 is in a boot loop...

• xsbug briefly flashes a "main" tab about once a second, setting the break-on-start pref doesn't change that
• serial console at 115200 baud shows a repeating

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:344
load:0x40078000,len:13488
load:0x40080400,len:3520
entry 0x400805d0
gBB␋Jb!@+b�%�^�y+Kb+RD���ets Jun  8 2016 00:22:57

• serial console at 460800 shows the xsbug protocol, a repeating:

<?xs-3FFC5E00?>
x<�x␀�x��x␀��x�x<␏x��x␀�␀�␀�␀����␀�x␀␡����␀�␀�␀�������������x<�����x�␀�x␀x�␀�x␀��x
 �x␀�x���␀�␀x�␀x␀�␀x���x<�x<␏x<�␀x␀x<␏x<␏x<��x<␏␀x��x<␏␀x␀�x<␏x␞�␀x��␀x��x��x␀�x��
 ␀�␀x<␀����␀�␀x���x<␀x<␏x�x�x<�␀x<␀x��x<␀x<␏x<�␀x␀␡�x<␀x��x<␀�x�x<�␀x��x��x␀�x<␏x␞
 <�␀�x␀�␀x��x��x��x<��x��x��x<��x␀x���␀�␀�␀x�␀���x<␀x<␏x�x�x<␏␀x<���␀�␀x<␏�x<␏�x<�
 �x␀�␀x␀␡�x�x�x�x<␀�x��x��x���␀�␀x␀�␀�␀x�x␀�x�x<␀�x��x��x���␀�␀x␀�␀�␀x�␀�x�x<␀�x��
x��x���␀�␀x␀�␀�␀x��␀x��x␀��x<␀�x��x��x���␀�␀x␀�␀�␀x�␀�x␀␇�x�x<␀�x��x��x���␀�␀x␀�␀�
 x���x␀x�x<␀�x��x��x���␀�␀x␀�␀�x�␀�x␀x��x��x␀␇�x<␏�x���␀␀x<��x��x␀␡<�␀��␀x␀␡�x��x�
 x�x�x␀�␀�x<��x��x���x␀␡�x�␀�x␀␀�x��x<␀x␀␇�x���␀�␀x�����x��x��x␀�␀����␀�␀x�␀�x<␏�x
 �x������␀��␀��x�␀�x␀␀�x��x<␀x␀␇�x���␀�␀x␀��␀�␀����␀�␀�␀�␀�␀x�␀�x<␏�x��x���x␀␡����
 ��␀�␀�x�␀�x␀␀�x��x<␀x␀␇�x���␀�␀x␀��␀�␀�␀�␀�␀��␀�␀�␀x�␀�x<␏�x��x������x<�����␀�x�␀
 x␀x<�x��x␀�x��x<�x␀�␀�␀x␀��␀�␀�␀�␀�x<��␀�x␀�x�␀�x␀<?xs-00000000?>

<?xs.3FFC5E00?>
<xsbug><login name="main" value="XS"/></xsbug>

I'm gonna go back and see what I fat-fingered, but I wonder how one finds out what happens when the esp32 crashes? I'm used to seeing the ESP-IDF crash info, which typ. includes an error messages and backtrace info.

[andycarle]

Is it a "target" or a "platform" or a "sub platform" that I'm creating? I'm passing it to mcconfig's -p option, right? But in the source tree that stuff is under esp32/targets...

You're creating a subplatform of the esp32 platform. We generally use "target" to refer to either a platform (e.g. -p esp8266) or a platform/subplatform combination (e.g. -p esp32/moddable_two). You are correct that the esp32/targets folder probably should actually be named esp32/subplatforms. The historical reasons that it is not are not especially interesting.

Where? In the moddable source tree? I don't see anywhere I can specify where my sub-platform definitions live. How does that fare when I upgrade the moddable SDK? Assumes upgrade==git pull I guess...

We generally do just drop them into build/devices/esp32/targets, yes. I think that symlinks will work there too, but I'm not positive of that and am not in a position to test at the moment.

Where are the defines in the manifest.json used?

Defines ripple through to native (C) code. See the Using defines in manifests document for details. In this case, I suspect that those defines in the manifest were erroneously carried over from another platform.

I'm gonna go back and see what I fat-fingered, but I wonder how one finds out what happens when the esp32 crashes? I'm used to seeing the ESP-IDF crash info, which typ. includes an error messages and backtrace info.

The ESP-IDF log output and the Moddable SDK xsbug output are not always compatible with each other. When diagnosing native crashes, we often use instrumented builds instead (-i instead of -d to mcconfig). You can also tweak the SDKCONFIG of your project a bit and force logging into a release build.

[nickthiru]

Defines ripple through to native (C) code. See the Using defines in manifests document for details. In this case, I suspect that those defines in the manifest were erroneously carried over from another platform.

Am I correct in understanding that, in line with the new API (Ecma TC53) for communicating with input/output hardware and sensors, we should use the provider.js files as a "central place" to import hardware comm protocols, configure pin settings, etc., and then accessing the settings using the devices object in our mod? So, in the case of creating a "custom" target, we shouldn't use the defines object in a manifest.json like we did with the old API i.e. modules/pins, yes?

[phoddie]

Generally, yes. One consequence of ECMA-419 (created by TC53) is that a lot of the configuration moves into JavaScript. I'm very happy with how that has worked out, but it is surely a bit different to set-up a new device target.

[nickthiru]

@phoddie Noted; thanks.