C-preprocessor-like macros?

[ThomasWaldmann]

Moved the "assembler macros" discussion to #40.

Below, let's discuss about C-preprocessor-like macros.

[ThomasWaldmann]

the official assembler toolchain has also these macros (in soc_ulp.h):

• READ_RTC_REG, WRITE_RTC_REG
• READ_RTC_FIELD, WRITE_RTC_FIELD

[mattytrentini]

Yes, I think we need a replacement for these. A few implementation options off the top of my head:

1. Actually run the source through a (probably rudimentary) C preprocessor
2. Extend the parser to know about those specific macros and replace them
3. Extend the opcodes to introduce new higher-level commands that don't actually exist in the ulp

I think 1) will be too heavy-weight. There are even existing C preprocessors implemented in Python that could be used but they are all complex and memory intensive. Suspect it'll be very hard to work within the memory constraints of a microcontroller.

2 could work. Perhaps makes sense to explicitly call it before src_to_binary:

binary = src_to_binary(replace_macros(source))

replace_macros would drop the includes and carefully replace the macros defined by Espressif.

The attractive part of 3 is that it could make the code quite elegant. But the commands would be specific to py-esp32-ulp and it could be misleading to users; it wouldn't be clear how they mapped to ULP instructions.

Worth noting that 1 & 2 have a huge benefit of being compatible with existing ULP code.

I think I'm leaning toward option 2...

[mattytrentini]

I'm also a little confused with the implementation of the Espressif macros. It appears like the address passed in to the macro should be a 32bit address but by the time the macro is expanded the value is offset and divided by 4:

// GPIO2 LED ON
WRITE_RTC_REG(RTC_GPIO_OUT_REG, RTC_GPIO_OUT_DATA_S + 12, 1, 1)

Expands with (from soc_ulp.h):

#define WRITE_RTC_REG(rtc_reg, low_bit, bit_width, value) \
    REG_WR (((rtc_reg) - DR_REG_RTCCNTL_BASE) / 4), ((low_bit) + (bit_width) - 1), (low_bit), ((value) & 0xff)

to:

REG_WR ((0x3ff48400 - 0x3ff48000) / 4, ((14 + 12), (14 + 12), (1 & 0xff)))

It just looks...wrong. Your compatibility test takes the raw 0x3ff48000 address.

Am I missing something?

[ThomasWaldmann]

The compat test were just written to use all opcodes with some (more or less random) parameters.

It could well be that some params do not make sense at all. And all it tests right now is that the official assembler output is same as the py-esp32-ulp output (not that the code makes sense or works).

[ThomasWaldmann]

I think option 1) is out of question due to the reasons you already mentioned.

Option 2) [good compatibility] and 3) [ease of implementation] seem to be good options.

[lazyoldjack]

As a potential user, option 2 looks the best to me, though I have to admit to currently knowing very little about these macros, except for the fact that I need to use them in my ULP code to read and write pins. It's a shame this project is so quiet because I'm sure that there are many ESP32 users who need the simplicity of MicroPython for a load of complex stuff but still need the ease of just including a snippet of ULP code in their project to save on battery power.

If there is anything I can do to help advance this issue, please let me know, though I fear I won't be much use except for testing.

[ThomasWaldmann]

Yeah, not many contributors here (not even me right now). Maybe it needs more advertisement in the esp32 community.

Advancing this stuff == making a pull request.

[lazyoldjack]

OK, so Matty wrote the code for the ULP WAKE instruction in MicroPython, so that's a big improvement to ULP use imho because MP can be restarted based on an ULP algorithm. I (and others) have tested it and it works with py-esp32-ulp. Hurrah. 🥳

I think the difficulty of performing IO etc. without the macros will have put off many of the potential users of ULP code in MP, so I am going to look to see if I can understand what's involved in adding them, but as Matty will tell you, I didn't get very far with trying to work out the code for the WAKE instruction so don't hold your breath! 😸

Thanks again for making such a great tool. I think when the macros work, there might be a possibility of getting Andreas Spiess to create a feature video on py-esp32-ulp, especially if I can furnish him with some working examples and that is likely to generate a lot more interest.

[lazyoldjack]

... and another excellent use of the ULP is if you want to perform some bit bashing, because it is far less subject to timing interference than the main cores that are under the influence of RTOS. Here is a colour coded persistence trace of an RTCIO pin being bashed in the ULP; I never saw one pulse out of place.

I guess that's why some folks have tried to use it for audio.

[ThomasWaldmann]

Fixed by #43.