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

[Ole Reinhardt]

Hi Uwe,

I suspect you are on the wrong track. In my understanding assigning the
value of one variable to another will result at least in one load and
one store operation on ARM.

Even more, if one of the variables uses indirect addressing (like in
your example)


I tested the following simple example:

volatile uint32_t a = 10;
volatile uint32_t b = 0;
b = a;


The following code was produced by the compiler:

    volatile uint32_t a = 10;
    8234:       e3a0300a        mov     r3, #10
    8238:       e50b3008        str     r3, [fp, #-8]
    volatile uint32_t b = 0;
    823c:       e3a03000        mov     r3, #0
    8240:       e50b300c        str     r3, [fp, #-12]

    b = a;
    8244:       e51b3008        ldr     r3, [fp, #-8]
    8248:       e50b300c        str     r3, [fp, #-12]


Instead of writing such error prone hacks, I would suggest to only
disable single interrupts instead of disabling the whole interrupt
handling, wherever possible.

For example in the STM32 OWI Bus driver you could replace the

NutEnterCritical() / NutExitCritical() by

NutIrqDisable(&STM32_OWITIMER_SIG);
NutIrqEnable(&STM32_OWITIMER_SIG);

Best regards,

Ole


Am 17.11.2015 11:10, schrieb Uwe Bonnes:
> Hello,
> 
> in our common code we use a lot of protection when accessing multi-byte
> variables in drivers in user code when these variable can be changed by an
> interrupt:
> E.g. in dev/usart.c:UsartFlushOutput()
>         NutEnterCritical();
>         rc = rbf->rbf_cnt;
>         NutExitCritical();
> However this access is atomic per se as long as the native bus width can
> carry the variable. So on any of the 32-bit machines we support, these
> critical sections are not needed. I propose to provide another machine
> dependant call so that the usage above would change to something like
>         NutEnterCriticalAccess();
>         rc = rbf->rbf_cnt;
>         NutExitCriticalAccess();
> 
> On 8 bit machines these functions would resolve to NutEnterCritical()
> and on 32-bit machines these functions would be empty defines.
> 
> Am I on a wrong track?
> Any objections to provide the new functions in common code?
> 
> Probably changing existing drivers to use these new functions is prone to
> colateral damage. Any opinions if it is worth to do that change?
> 
> 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