Critical Code section

[kilobyte_ch]

Hello

I need a critical code section inside my esp-idf project. Cricital means that during a short time the timing should be 100% reproducable. I'm using nop's to time it. But I see big variations when WiFi is turned on or other tasks are running. No surprise. But I'm asking how can I disable "everything" to get this short section reproducable and then turn everything on again?

Thanks

[f.h-f.s.]

Code: Select all

portMUX_TYPE myMutex = portMUX_INITIALIZER_UNLOCKED;
taskENTER_CRITICAL(&myMutex);
//critical section
taskEXIT_CRITICAL(&myMutex);

from FreeRTOS/task.h & FreeRTOS/portmacro.h
or

Code: Select all

uint32_t volatile register ilevel = XTOS_DISABLE_ALL_INTERRUPTS;
//critical section
XTOS_RESTORE_INTLEVEL(ilevel);

from xtruntime.h

You can read the cpu ticks with

Code: Select all

uint32_t r;
asm volatile("rsr %0, ccount" : "=r"(r));//read special register cpu tick count

[urbanze]

Code: Select all

uint32_t volatile register ilevel = XTOS_DISABLE_ALL_INTERRUPTS;
//critical section
XTOS_RESTORE_INTLEVEL(ilevel);

from xtruntime.h

This critical section disable mutual cpu acess? I need to prevent both core to acess same "line in code" with more fast way possible... (Without method of freertos like semphr)

[michprev]

Code: Select all

uint32_t volatile register ilevel = XTOS_DISABLE_ALL_INTERRUPTS;
//critical section
XTOS_RESTORE_INTLEVEL(ilevel);

from xtruntime.h

This critical section disable mutual cpu acess? I need to prevent both core to acess same "line in code" with more fast way possible... (Without method of freertos like semphr)

This one only disables C callable interrupts (level 3 or lower) on the current core.

You will have to go for

Code: Select all

portMUX_TYPE myMutex = portMUX_INITIALIZER_UNLOCKED;
taskENTER_CRITICAL(&myMutex);
//critical section
taskEXIT_CRITICAL(&myMutex);

taskENTER_CRITICAL disables C callable interrupts (on the current core) and locks the mutex by the current core.

[ESP_Sprite]

Note that it's very hard to guarantee 100% precise CPU timings: you always run the risk of the other CPU, a DMA access, a lingering value in the CPU load/store unit or something else delaying a memory fetch and delaying your code. What issue exactly are you trying to solve? Chances are very large that there's a better solution than doing NOP delaying.