How is the ULP coprocessor going to be programmed?

[uhrheber]

What is the designated way of programming the ULP?
Will there be a separate compiler/assembler for it?
From what I've read, the bootloader is already able to write to the rtc memory?

What processor type is it anyway? Anything already known, or a completely proprietary core?

Thanks
Uhrheber

[ESP_igrr]

ULP processor is a simple FSM, with 4 general purpose registers, plus some arithmetic, memory, and branch instructions.
It can read and write to RTC slow memory (although writes are very limited, e.g. you can't write a full 32 bit word with an arbitrary value), it can also read and write RTC registers (again limited, you can only use literal values for these instructions, reads and writes from a register are not supported). It does have indirect addressing for memory reads and writes, and it is possible to set up a stack and function calls. Documentation for the ULP instruction set has been written but needs some editing. Then we will release it in the TRM.

Regarding programming:
We don't have a toolchain for the ULP yet. I have started writing an LLVM backend for it, but LLVM has a bit of a learning curve to it, and also ULP is not the highest thing on the priority list, so I haven't got far yet.
I do have a way to generate ULP instructions using C macros. This may be used to write programs for the ULP with an assembly-like syntax. I can put this into ESP-IDF if someone is interested.
Full C toolchain for the ULP will probably take some time.

[ESP_krzychb]

ESP-WROVER V1 (aka DevKitJ) has XO2 32.768KHz circuit build in. Has it been put in place to clock the ULP Processor?

[uhrheber]

I do have a way to generate ULP instructions using C macros. This may be used to write programs for the ULP with an assembly-like syntax. I can put this into ESP-IDF if someone is interested.

That would be nice. I grew up with 8051 and PIC assembler, so no problem here.
As I'm planning to use the ESP32 in battery powered home automation sensors, it'd be great to let the ULP do some decisions before waking up the power hungry main cores.

[rudi ;-)]

..
I can put this into ESP-IDF if someone is interested.
..

1+
would be great
txs

best wishes
rudi

[ESP_igrr]

Regarding 32kHz crystal: RTC domain has several clock sources, crystal is one of them. Another one is 150kHz RC oscillator. Currently RC oscillator is used by default. There will be a way to configure which one of them to use.

Regarding ULP macros, okay, we'll put them into the ESP-IDF.

[rudi ;-)]

...
Regarding ULP macros, okay, we'll put them into the ESP-IDF.

Initial support for generation of ULP coprocessor code..

thanks!!!

best wishes
rudi

[jeromeh]

@uhrheber, how is your progress of using ULP for your project? Is is smooth? I'm trying to use esp32 on batter powered device too, but run into many different problems.

I do have a way to generate ULP instructions using C macros. This may be used to write programs for the ULP with an assembly-like syntax. I can put this into ESP-IDF if someone is interested.

That would be nice. I grew up with 8051 and PIC assembler, so no problem here.
As I'm planning to use the ESP32 in battery powered home automation sensors, it'd be great to let the ULP do some decisions before waking up the power hungry main cores.

[tomtor]

Regarding programming:
We don't have a toolchain for the ULP yet. I have started writing an LLVM backend for it, but LLVM has a bit of a learning curve to it, and also ULP is not the highest thing on the priority list, so I haven't got far yet.
I do have a way to generate ULP instructions using C macros. This may be used to write programs for the ULP with an assembly-like syntax. I can put this into ESP-IDF if someone is interested.
Full C toolchain for the ULP will probably take some time.

I gained some experience with an ULP DHT-22 driver.

Any plans on placing the partial finished LLVM on github? I would like to contribute code.

An alternative for me would be to write a set of preprocessor macros to handle stack operations and subroutine calls in ULP assembler.

To access the PC for subroutine calls/returns one can store a register and the high 16 bits will contain the current PC shifted left 5 bits. It is not clear what purpose the 5 bit shift has. After loading the stored PC value by using a 2 byte offset, the register has to be shifted 5 bits before the value can be used in a jump.

Is this 5 bit shift caused by keeping the ULP circuitry at a minimum?

Edit: the readthedocs html docu specify that a signed byte offset can be used to read data, but the Pdf hardware manual specifies an offset in 32bit words. I believe the latter is correct and this means that subroutines/functions are impossible with the published instruction set, because there is no way to return to the caller of a routine...

[ESP_igrr]

Which sentence in readthedocs are you referring to (regarding 'the readthedocs html docu specify that a signed byte offset can be used to read data')?

Instructions indeed take offsets expressed in 32-bit words. However when you write assembly code, you should use offsets expressed in bytes, and assembler will convert them into words.