ESP32 platform questions

[tve]

I have a bunch of esp32 platform questions that I don't find answered in the docs or by quickly glancing at source code. If there are docs I should read I would appreciate pointers!

• Cores: do I assume correctly that on dual-core CPUs XS uses only the app core and that the other core is only used by esp-idf tasks?
• Async SPI: as far as I can tell, the SPI implementation uses the esp-idf driver, I don't understand enough about the JavaScript/XS tasks to figure out whether, when one task performs a long SPI transaction (like sending a frame buffer to a screen) other tasks can run?
• In the SPI implementation I see that buffers are copied, e.g. modSpiLoadBufferAsIs, is this due to the compacting garbage collection, or is there another reason?
• Does the run-time support SPIRAM? If so, how long does a minimal garbage collection cycle take?
• How is the split of RAM between esp-idf and XS handled? E.g., esp-idf needs to have a heap for stuff like network buffers. Does XS allocate one big chunk at start-up? Or does it incrementally allocate chunks from esp-idf? Does it ever free them?
• Is the esp32 put to sleep when no tasks are running?
• Can the cpu clock freq be changed, e.g. to 80Mhz to conserve power?

[phoddie]

I have a bunch of esp32 platform questions that I don't find answered in the docs or by quickly glancing at source code.

You are asking deep question across a broad range of topics. A quick glance is unlikely to provide answers.

Cores: do I assume correctly that on dual-core CPUs XS uses only the app core and that the other core is only used by esp-idf tasks?

No. The FreeRTOS scheduler determines when tasks run and on which core. The main XS virtual machine is one task. Others XS virtual machines be created in separates tasks using web workers (documentation).

Async SPI: as far as I can tell, the SPI implementation uses the esp-idf driver, I don't understand enough about the JavaScript/XS tasks to figure out whether, when one task performs a long SPI transaction (like sending a frame buffer to a screen) other tasks can run?

The FreeRTOS scheduler allows other tasks to run.

Does the run-time support SPIRAM?

SPIRAM is not a runtime feature of the Moddable SDK. It is a capability of the ESP-IDF. XS and the Moddable SDK are able to make use of all the memory provided on the device by the ESP-IDF. The M5Paper platform target is an example of an ESP32 device that supports SPIRAM.

If so, how long does a minimal garbage collection cycle take?

Your mileage may vary. The size of the heaps and what they contain cause GC times to vary significantly.

How is the split of RAM between esp-idf and XS handled? E.g., esp-idf needs to have a heap for stuff like network buffers. Does XS allocate one big chunk at start-up? Or does it incrementally allocate chunks from esp-idf? Does it ever free them?

XS memory is configured in the project's manifest (documentation).

Is the esp32 put to sleep when no tasks are running?

That depends on the ESP-IDF and how it is configured. When there is no work to do, the Moddable SDK is idle (no busy loops).

Can the cpu clock freq be changed, e.g. to 80Mhz to conserve power?

Yes. The ESP-IDF has features to configure these behaviors.

[phoddie]

...other javascript tasks...

"tasks" here is ambiguous. A web worker allows JavaScript to run in a separate FreeRTOS task. I think you are asking something like "is JavaScript execution blocked in the virtual machine that initiated the asynchronous SPI write?", but I'm not certain.

• Asynchronous SPI writes are asynchronous: they return more-or-less immediately.
• Synchronous SPI writes are synchronous: they block until complete.

As a rule, asynchronous SPI writes are not initiated from scripts (they could be, just not generally the case). They are used most commonly when rendering graphics to displays connected with SPI.

[phoddie]

On reflection, I think the reason you are asking questions about SPI is because the LoRa driver communicates using SPI. That uses the ECMA-419 SPI class. Those SPI read and write calls are synchronous-only today. As you noted, the underlying native SPI code does support asynchronous communication. There are plans to support asynchronous I/O in the ECMA-419 SPI class in the future.

That said, the LoRa transactions are small enough that performing them synchronously is generally not a problem. If you really want to avoid blocking there, you can perform the LoRa operations in a worker, at which point they are often running on a separate core, which is as non-blocking as you can get.

[tve]

Apologies, I didn't want to send you into a guessing game. I was asking mostly because of display transfers. For small transfers like for the LoRa radio async tends to be counter-productive. The esp-idf API already has pretty high overhead, at least it used to.
From your reply I saw that https://github.com/Moddable-OpenSource/moddable/blob/public/modules/pins/spi/esp32/modSPI.h#L39 distinguishes between sync & async.

Would you mind commenting on "In the SPI implementation I see that buffers are copied, e.g. modSpiLoadBufferAsIs, is this due to the compacting garbage collection, or is there another reason?", I'm just wondering whether I'm missing something.

You are asking deep question across a broad range of topics. A quick glance is unlikely to provide answers.

😆 You don't know all the questions I'm not asking 'cause I found an answer 🤣 I'm just trying to gauge how much I'm going to have to put in in order to do the projects I'd like to do using Moddable...

[phoddie]

Would you mind commenting on "In the SPI implementation I see that buffers are copied, e.g. modSpiLoadBufferAsIs, is this due to the compacting garbage collection, or is there another reason?", I'm just wondering whether I'm missing something.

As I recall, it is due to a requirement in the ESP-IDF that the buffers be allocated as DMA-capable. It has been awhile and the ESP-IDF may have changed since. Note that it does not make a full copy of the buffer. It copies it in chunks into the DMA buffers as they empty, so it doesn't add much memory overhead.

[tve]

Ah, right, IIRC SPIRAM isn't DMA-capable and some other segments aren't either. Thanks!