Re: NutEnterCritical vs NutEnterCriticalAccess()

>>>>> "Dušan" == Dušan  <[email protected]> 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
-- 
Uwe Bonnes                bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion