[En-Nut-Discussion] NutEnterCritical vs NutEnterCriticalAccess()

[Ole Reinhardt]

Hi Uwe,

ok, I think I now understand your basic idea. And yes, you are right,
that on AVR some variable modifications take two or more instructions.

On ARM assigning one variable to another still needs two instructions
(load from memory to register, and store register to memory), but indeed
the variable content can not be modified in between, so that (from this
point of view) the assignment is still atomic.

Unfortunately I see a big risk to introduce hard to track bugs, by
loosing the overview about all possible side-effects of compiler
optimisations etc.

Nathan pointed out some problems in his code snipped quite well: For
example alignment of variables needs to be taken into account as well.

So I just fear, that a waterproof solution (with alignment checks etc.)
might need to carefully check every single change twice.

>From the syntactical point of view, I would prefer Nathans solution with
a "NutCristicalUpdate" macro. This would reduce lines of code and gives
us the option to implement platform specific solutions.

Have you just made a list of files, where such changes would be needed /
helpfull?

Best regards,

Ole


Am 18.11.2015 17:51, schrieb Uwe Bonnes:
>>>>>> "Dušan" == Dušan  <dferbas at etech.cz> writes:
> 
>     Dušan> Hi Uwe, I noticed your attempt to optimize NutEnterCritical().
> 
> Optimizing NutEnterCritical() is not my attempt.
> 
> Look at following pseudo code
> 
> volatile uint32_t interrupt_variable;
> ...
>    uint32_t local_variable;
> 
>    NutEnterCritical();
>    local_variable = interrupt_variable;
>    NutExitCritical();
> 
>    ...
>    NutEnterCritical();
>    interrupt_variable = local_variable;
>    NutExitCritical();
> 
> Such code is e.g. used in dev/usart.c. The protection of the access is
> needed when this code is compiled for AVR8. However the protection is not
> needed when compiling on a 32-bit platforms.
> In other places, NutEnterCritical() and NutExitCritical() is however needed
> when compiling for 32-bit platforms. So I proposed to use other functions
> for the use case in the peudo code given above. The new functions could be
> empty defines on 32-bit platforms and resolve to NutEnterCritical() and
> NutExitCritical() else. When these functions are available, at least code
> for new drivers in common code could use it.
> 
> It there anything flawed in this approach that is more flawed than the
> present situation?
> 
> Bye
> 

-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de