attribute register or DRAM_ATTR

[stoumk]

Code: Untitled.c Select all

register uint32_t var1 = 123;

DRAM_ATTR uint32_t var2 = 123;

IRAM_ATTR uint32_t var3 = 123;

I usually use "register", but in ESP32 do I need to use DRAM_ATTR to get the same effect?
Can I use IRAM_ATTR on variables or structures?

[MicroController]

I usually use "register"

You most likely shouldn't.

to get the same effect?

The desired effect being...?

[Sprite]

They do different things. 'register' hints at the compiler that it may be a good idea to allocate a variable in a register (but note that for modern compilers, it's very unlikely that the compiler cares about the hint)

IRAM_ATTR and DRAM_ATTR change the memory type where the thing is allocated: in 32-bit-only memory or in 'standard' memory. DRAM_ATTR is the default, so there's no use in adding it; IRAM_ATTR generally is used for functions and I'm not even sure if it has any effect on variables. IRAM variables come with a bunch of gotchas, though; you'd only need them in very specific circumstances and only when you know what you're doing.

Generally, I'd agree with MicroController: unless you have a very specific and well-defined reason to, you shouldn't use any of these attributes on variables, period.

[stoumk]

My goal: to get the fastest possible calculations
I measure the period of the pin, do the calculation and raise another pin.

[MicroController]

My goal: to get the fastest possible calculations

Ok.
As Sprite said, compilers today are pretty good especially when it comes to register allocation. The compiler is well aware that accessing RAM is more expensive than bare register access and it can and will reduce RAM accesses very efficiently.

If you can share your time-critical function code we may be able to give you a hint on potential manual optimizations, if there are any.

Also, I find it useful and instructive to use the Compiler Explorer to quickly experiment and see which variations of a piece of code generate what assembler output.

[stoumk]

line 104

Code: Untitled.c Select all

#define GPIO_Set(x)             REG_WRITE(GPIO_OUT_W1TS_REG, 1<<x) 

#define GPIO_Clear(x)           REG_WRITE(GPIO_OUT_W1TC_REG, 1<<x) 

#define GPIO_IN_Read(x)         REG_READ(GPIO_IN_REG) & (1 << x) 

#define GPIO_IN_ReadAll()       REG_READ(GPIO_IN_REG) 

#define GPIO_IN_ReadAll2()      REG_READ(GPIO_IN1_REG)  



#define DEF_PIN_1 GPIO_NUM_16

#define DEF_PIN_2 GPIO_NUM_17



#if CONFIG_ESP32_DEFAULT_CPU_FREQ_80

#define NS_PER_CLK 12.5F

#endif

#if CONFIG_ESP32_DEFAULT_CPU_FREQ_160

#define NS_PER_CLK 6.25F

#endif

#if CONFIG_ESP32_DEFAULT_CPU_FREQ_240

#define NS_PER_CLK 4.166F

#endif



typedef struct

{

    uint32_t _us;

    uint32_t delay_ns;

    float kef;

} TimingsMath_t;

volatile TimingsMath_t DRAM_ATTR TimingsMath[20];



typedef struct

{

    uint32_t _us;

    uint32_t delay_ns; 

    float kef;

} Delay_t;



void IRAM_ATTR Core1_( void* p) { 



    portDISABLE_INTERRUPTS();  



    for (;;) { 

        uint32_t gpioValue = 0;

        uint8_t sensor_1_status = 0;

        uint8_t sensor_2_status = 0;

          

        Delay_t tablePoint[20];

        for (size_t i = 0; i < 20; i++)

        { // copy

            tablePoint[i]._us = TimingsMath[i]._us;

            tablePoint[i].delay_ns = TimingsMath[i].delay_ns;

            tablePoint[i].kef = TimingsMath[i].kef;

        } 



        register uint32_t _dT_us_prev_sens1  = 120UL;

        register uint32_t _dT_us_prev_sens2  = 120UL;

        register uint32_t _dT_us_current  = 1000000;

        register uint32_t _dT_us_first  = 120000;

        register uint32_t _baseDelay_ns = 11111; 

        register uint32_t delay_us = 11111; 

        uint8_t _start = 4;

         

        register float kefK = 0;

  

        int8_t active_pin_ = -1;    

        for (;;){  

            gpioValue = GPIO_IN_ReadAll(); //10tik@160MHz(6,25ns) 7tik@80MHz(8,75ns) 



            if( ((gpioValue >> 22) & 1) == 1){ 

                sensor_1_status = 5; 

            } 

            if(sensor_1_status && --sensor_1_status == 0){  



                _dT_us_current = micros() - _dT_us_prev_sens1; 

                _dT_us_prev_sens1 = micros();  

                active_pin_ = DEF_PIN_1;

            } 

            



            if( ((gpioValue >> 23) & 1) == 1){ //   HIGT/

                sensor_2_status = 5;

            } 

            if(sensor_2_status && --sensor_2_status == 0){

            

                _dT_us_current = micros() - _dT_us_prev_sens2;

                _dT_us_prev_sens2 = micros();  

                active_pin_ = DEF_PIN_2  ;

            }





            if(_start > 0){

                --_start;  

                continue; 

            }





            for (int8_t i = 19; i >= 0 ; i--) 

            {   

                if( _dT_us_current <= tablePoint[i]._us ){

                    _dT_us_first = tablePoint[i]._us;

                    _baseDelay_ns = tablePoint[i].delay_ns; 

                    kefK = tablePoint[i].kef;

                    break;

                } 

            }

            

            delay_us = (_baseDelay_ns - (uint32_t)((float)(_dT_us_first - _dT_us_current) *kefK)) /1000 ;   



            // uint32_t ccnt_st_ = XTHAL_GET_CCOUNT(); // 6,25ns

            // while( (XTHAL_GET_CCOUNT() - ccnt_st_ ) < delay_us/NS_PER_CLK ); // 1000ns/6,25=160clk  

            esp_rom_delay_us( delay_us ); 

             

            GPIO_Set(active_pin_); 

            

            esp_rom_delay_us(50); 

            GPIO_Clear(active_pin_);

            esp_rom_delay_us(150); 

            active_pin_ = -1; 

        }

    }

    vTaskDelete(NULL);

}

[Sprite]

I'd try to get rid of those floats if you can. It's usually a fair bit faster to use fixed-point integer logic. Another hint: profile. Unless you know how fast a given iteration of your code runs, it's impossible to see if an optimization actually optimized stuff or made it worse.

[MicroController]

Definitely get rid of floating point calculations in the critical loop.

Agreeing with Sprite again, you can use XTHAL_GET_CCOUNT() or esp_cpu_get_cycle_count() to measure the (average) time of an iteration (excluding esp_rom_delay_us(...) of course) and see if/how much it improves.

Some minor suggestions:
- Call micros() only once per iteration
- Check if you can pull the initial delay (_start) to before the actual processing loop.
- Use 32-bit integer variables instead of 8- or 16-bit
- Comparing to 0 may be faster than to non-zero values: if ( (x&1) == 1 ) -> if ( (x&1) != 0 )

[stoumk]

Thanks. I tried to take measurements in this way. In any case, I get 1 tick for different inputs to the formula.

Code: Untitled.c Select all

start = XTHAL_GET_CCOUNT();

delay_us = (_baseDelay_ns - (uint32_t)((float)(_dT_us_first - _dT_us_current) *kefK)) /1000 ;  

start2 = XTHAL_GET_CCOUNT();

startDiff = start2 - start  ;

portENABLE_INTERRUPTS(); 

printf("bench:\t%lu\n", startDiff);

portDISABLE_INTERRUPTS();   

UPDATE:
portGET_RUN_TIME_COUNTER_VALUE instead of XTHAL_GET_CCOUNT gives 12-16 ticks

[MicroController]

Two thoughts:
1. XTHAL_GET_CCOUNT seems to be defined to do a direct register read, while portGET_RUN_TIME_COUNTER_VALUE (confusingly) maps to the ROM function xthal_get_ccount(); hence, you'd get more accurate results from XTHAL_GET_CCOUNT,
BUT
2. This kind of micro-benchmark may be foiled by the compiler: The compiler is allowed to re-order instructions/operations under certain conditions; in this case, the compiler may (and probably does) re-order your calculation to before or after the timed period - because it cannot see a dependency between start, start2 and delay_us. (There is no way the CPU could have actually done your calculation in 1 clock cycle...)

You can either try and time a bigger section of code, e.g. most of a full iteration, or use some 'hacks' to 'fool' the compiler,
e.g.

Code: Select all

// Make the compiler believe that some volatile magic happens to "value"
// to prevent reordering of code/expression w.r.t. other "volatiles".
static uint32_t vltle(uint32_t value) {
    // This assembly is empty (does nothing), but tells the compiler that it may have changed ("+r") the contents of "value"
    asm volatile ( "\n" : "+r" (value) );
    return value;
}

...
start = XTHAL_GET_CCOUNT();
delay_us = vltle( (_baseDelay_ns - (uint32_t)((float)( vltle( _dT_us_first ) - _dT_us_current) *kefK)) /1000  );
start2 = XTHAL_GET_CCOUNT();

(vltle used twice above to ensure that the calculation does not "start" before the first XTHAL_GET_CCOUNT and has produced its result before the second XTHAL_GET_CCOUNT)