MPU_xTaskGetTickCount ... Why MPU ..?

The function wrapper for MPU version to get tick count is in portable/Common/mpu_wrappers.c.

I don’t understand, why … Why do I need at all, raising the privilege? The call returns by copy the value of the counter, and to do this it for some reason, raises (unequivocally) the privilege.

On my platform (ARM …), this is an SWI or similar exception, and this jump is no where ‘cheap’ considering all I want, is just the copy of this unisigned int. (Which, irrelevantly for the question, also happens to be native enough to be atomic, all in all, fast access).

So why do I have this performance hit? … Why this does not directly invoke xTaskGetTickCount, why would anyone place it in a section of flash where ‘user’ mode cannot invoke this?

TickType_t MPU_xTaskGetTickCount( void ) /* FREERTOS_SYSTEM_CALL */
TickType_t xReturn;
BaseType_t xRunningPrivileged = xPortRaisePrivilege();
xReturn = xTaskGetTickCount();
vPortResetPrivilege( xRunningPrivileged );
return xReturn;

The variable that holds the tick count is privileged data - meaning it can only be accessed by code running in privileged mode.

And the reason it shouldn’t just be a read-only access for all but kernel …?

Several Problems:

There is currently no region set aside for ‘read-only’, so a new region would need to be created for it, costing:

  • A precious region out of the limited number for each restricted task
  • Carving out a full region ‘page’ for the small list of variables that should be available read-only to everyone. A moderate memory cost.
  • A significant design issue of deciding WHAT data should be in this region to make the cost more reasonable, and one size doesn’t always fit all.

Putting the variable in such a region can’t easily be done in ‘Standard C’ but would need some sort of macro from the port layer, and the format needed to do this for all compilers might not be that readable (it isn’t as standardized in location as function modifiers).

I can’t quite remember the details - but it might be possible to define a tick hook function that keeps a copy of the tick count in user memory. That would increase the execution time of each tick interrupt - so which overhead is best will depend on how many times you want to read the tick count value.

Ok, I understand issues you wrote about.

About tick hook or copying to user: I would think that, once you already in the tick interrupt, copying over one word to another memory location (without any extra runmode switching) is a significantly cheaper overhead than excepting/interrupting from each user task to do this.

I would think no ‘hook’ even: just plain if user #define’ed do copy, extern userTick , copy to it. Crude? Maybe, but overhead of one word copying is low

Overall I get your points, but didn’t realize until now I have to watch out how many times I check the RTOS tick time.