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

[Uwe Bonnes]

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:

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

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

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

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

Well, code for STM32 e.g. must also run an MO(+) where unaligned access is
not implemented. Otherwise, the compiler always will put variables on aligned
locations unless asked not to do so by the packed attribute. NutOs uses
packed only in few places, mainly for Net packages payload, but not for
volatile state variables.

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

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

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

My intention was to provide this facility and use only in new code. To
provide a control block configured usart driver, dev/usart.c doesn't work
and dev/usart_cb.c also doesn't fit well, especially if you want to run the
uart with dma. So I am experimenting with some new dev/usart_xxx where I
would like to use the new infrastructure. Touching existing code is not my
intention.

Nathans solution is fine, but needs a complement to read a volatile state
variable. Implementing is not a problem, but choosing a sensible
name. Proposals are welcome, also for the name of the new usart driver.

Bye

-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------