Is it safe to use unused register address space?

[boarchuz]

It occurs to me that it would be possible to use the REG_RD and REG_WR instructions in a ULP program to effectively carve out some address space for custom purposes. I have a ULP program with a lot of boolean-type variables which are very expensive in terms of RTC memory (4 bytes each), where these REG instructions would provide a far more efficient and convenient alternative.

I've just had a quick look at the address space accessible to those instructions, and, in particular, there appears to be a huge amount of unused(?) space in the RTC_I2C_REG range: 878 contiguous bytes right up to the beginning of REG_IO_MUX, if I'm not mistaken. (0x3ff48c92 - 0x3ff49000)
Actually, I see that's now punctuated with a date code register in esp-idf 4.0, but the point stands...

Am I mistaken? Is it ok to read and write whatever I like in there?

Given how much there is to spare, I wonder if it might even be considered reserving and defining a range in esp-idf for this or any other custom purpose in a safe, future-proof way (eg. RTC_I2C_USER_DEFINED0_REG...RTC_I2C_USER_DEFINED7_REG)?

[WiFive]

Are there actual functional registers there or do the other registers just have duplicate access at those addresses? Why don't you just pack your bit flags together?

[boarchuz]

Are there actual functional registers there or do the other registers just have duplicate access at those addresses?

To my untrained eye it seems that from the end of the addresses here: https://github.com/espressif/esp-idf/bl ... reg.h#L275
up until the next 'base' defined here: https://github.com/espressif/esp-idf/bl ... /soc.h#L51
is ripe for the taking. There are other apparently free chunks too, nothing unique about this one.

I don't know much about how this works though, that's why I'm asking around.

Why don't you just pack your bit flags together?

There are pros and cons but ultimately it doesn't really make much of a difference because you then need additional instructions to manipulate the bits. And each instruction is itself a 32-bit word. Either you burn through RTC slow memory on more variables, or more instructions to manipulate fewer variables. Pick your poison.

The REG instructions allow setting, clearing, reading individual bits or ranges in a single instruction, and without the need for an offset register.
Suppose I wanted to set bit 0:

Code: Select all

move r3, my_bits
ld r2, r3, 0
or r2, r2, (1 << 0)
st r2, r3, 0
// vs
WRITE_RTC_REG(MY_BITS_REG, 0, 1, 1)

Granted that's an extreme example but you can see why I'm interested in exploring the option.

[WiFive]

Just because there is address space does not mean there is a physical memory element there.

You can use macros/calls/subroutines to set and check bits and you don't have to duplicate the instructions everywhere.

[boarchuz]

Just because there is address space does not mean there is a physical memory element there.

I'm not ready to give up on this yet but it looks like I've got some reading to do...
Thanks again for your help.

*******************************************************************************************
Ok I just had a tinker and you're right on all counts.

These addresses are duplicated within their respective range (eg. the highest offset within REG_RTCIO is < 0x100 so access to those registers is repeated four times over the 0x400 range from DR_REG_RTCIO_BASE (0x3ff48400) to the next (DR_REG_SENS_BASE at 0x3ff48800). So that significantly reduces the space I was referring to as "unused"...
And then you're also right that those "unused"/undefined addresses within that range do not appear to be mapped to physical memory: writing a value does nothing, read always returns 0.

So I'm going to pick out some registers that I do not need for their reserved purpose (eg. touch thresholds or I2C slave addresses) and co-opt them for custom usage.