• AVR Freaks

Atomic bitfield change macro

Page: < 12 Showing page 2 of 2
Author
saj
Junior Member
  • Total Posts : 114
  • Reward points : 0
  • Joined: 2008/06/20 03:13:30
  • Location: UK
  • Status: offline
RE: Atomic bitfield change macro 2008/12/04 18:21:18 (permalink)
0
Any thoughts on the ports.h peripherals library file shipped with pic32 compiler? 
 
There's various ways to set/toggle/clear ports (http://www.johnloomis.org/microchip/docs/32-bit-Peripheral-Library-Guide.pdf)
 
for example
mPORTASetBits

mPORTAClearBits

mPORTAReadLatchBit

mPORTAReadLatchBit
 
and so on...
 
Are these atomic?  ISR safe?  Have you had any experience with these and others ?
 
Saj
#21
PICinAway
New Member
  • Total Posts : 1
  • Reward points : 0
  • Joined: 2009/11/21 15:55:23
  • Location: 0
  • Status: offline
RE: Atomic bitfield change macro 2009/11/21 16:01:04 (permalink)
0
ORIGINAL: aschen0866

ORIGINAL: hg12345

universal  fast & compact code:

#define ChangeBitsHW(Dest,New,Mask)     asm volatile ("mov.w #%1,w1         \n" \
                                                                          ";disi #3                    \n   ;??????????"\
                                                                          "xor.w %2,WREG         \n" \
                                                                          "and.w w1,w0,w0        \n" \
                                                                          "xor.w %2                  \n" \
                                                                          : :  "a"(New) , "g"(Mask), "T"(Dest) : "w1" );



I don't see how this macro can be safe noticed that w1 and w0 might have already been used by the calling routine. Am I missing something with this inline assembly?

You might want to refer to the inline macro section of the compiler manual :)

There is one thing missing for absolute safety in the macro, but the compiler is aware of the macro's use of w1 and takes it into account.  The last line of the macro not only tells the compiler what types of objects to allow when the macro is used, but also what is modified by the macro.  In the case of w1, it's inclusion at the end of the last line after the last semicolon tells the compiler that W1 is clobbered - so it takes that into account.

While usually w0 is considered scratch, to be 100% safe even with compiler changes, w0 should be included with w1 in the list of clobbered registers.
#22
Page: < 12 Showing page 2 of 2
Jump to:
© 2020 APG vNext Commercial Version 4.5