Re: NutEnterCritical vs NutEnterCriticalAccess()

Ole Reinhardt <ole.reinhardt-L1vi/[email protected]>
Newsgroups gmane.comp.hardware.microcontrollers.ethernut
Message-ID <[email protected]>
Hi Nathan,

even with this solution, the variable update itself would still be
non-atomic (load and store), wouldn't it?

Further this adds a lot of extra code that Uwe wanted to avoid?

Btw:

Uwe, what exactly is you intention here? Do you need to save CPU cycles?
Or do you want to avoid global (or local?) interrupt disabling?

If I understand your basic idea a little better, perhaps I have more
ideas for a solution.

Best regards,

Ole


Am 17.11.2015 15:33, schrieb Nathan Moore:
> How about something like the following for each target cpu?
> 
> #define NutCriticalUpdate( VARIABLE, VALUE)              \
>      do {
>          \
>               size_t sz_ = sizeof(typeof(VARIABLE));            \
>               size_t sza_ = sizeof(sig_atomic_t);                    \
>               typeof(VARIABLE) * VP_ = &(VARIABLE);        \
>               typeof(VALUE) VAL_ = (VALUE);                     \
>               if (sz_ == sza_ && is_alligned(VP_)  {               \
>                      *VP_ = VAL_;
>  \
>               } else if (sz_ < sza) {
>   \
>                    /* special consideration for cpu */               \
>               } else {
>        \
>                    NutEnterCritical();
>  \
>                    *VP_ = VAL_;                                            \
>                    NutExitCritical();
>   \
>               }
>         \
>        } while (0)
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
> 

-- 
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
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.