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
Critical Code section
Re: Critical Code section
Code: Select all
portMUX_TYPE myMutex = portMUX_INITIALIZER_UNLOCKED;
taskENTER_CRITICAL(&myMutex);
//critical section
taskEXIT_CRITICAL(&myMutex);
or
Code: Select all
uint32_t volatile register ilevel = XTOS_DISABLE_ALL_INTERRUPTS;
//critical section
XTOS_RESTORE_INTLEVEL(ilevel);
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
Re: Critical Code section
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)f.h-f.s. wrote:from xtruntime.hCode: Select all
uint32_t volatile register ilevel = XTOS_DISABLE_ALL_INTERRUPTS; //critical section XTOS_RESTORE_INTLEVEL(ilevel);
Re: Critical Code section
This one only disables C callable interrupts (level 3 or lower) on the current core.urbanze wrote: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)f.h-f.s. wrote:from xtruntime.hCode: Select all
uint32_t volatile register ilevel = XTOS_DISABLE_ALL_INTERRUPTS; //critical section XTOS_RESTORE_INTLEVEL(ilevel);
You will have to go for
taskENTER_CRITICAL disables C callable interrupts (on the current core) and locks the mutex by the current core.f.h-f.s. wrote:Code: Select all
portMUX_TYPE myMutex = portMUX_INITIALIZER_UNLOCKED; taskENTER_CRITICAL(&myMutex); //critical section taskEXIT_CRITICAL(&myMutex);
-
- Posts: 9043
- Joined: Thu Nov 26, 2015 4:08 am
Re: Critical Code section
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.
Who is online
Users browsing this forum: No registered users and 154 guests