[En-Nut-Discussion] NutEnterCritical vs NutEnterCriticalAccess()
bon at elektron.ikp.physik.tu-darmstadt.de
Thu Nov 19 11:55:29 CET 2015
>>>>> "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> 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> 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
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
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.
Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
More information about the En-Nut-Discussion