renamed RAM bit-banding macros

[in4lio]

... to indicate that you need pass them a memory address (pointer) in contrast with PER bit-banding macros which take an address themselves

[in4lio]

do { } while(0) is a standard way to define a macro that expands into a compound statement. Of course, in our case, we have only one statement and able to use ( ... ) as it's done. But, look to the next construction:

(BIT_PER(a,b) = 0)

it can easily be misinterpreted as:

(BIT_PER(a,b) == 0)

The following variant is more concrete:

do { \
    BIT_PER(a,b) = 0; \
} while ( 0 )

Another way is to use ({ ... }) but it's only gcc extension.

Concerning the renaming...

This group of macros is not a part of original API and have been added to the library a short time ago, from R Max version. Neither the library nor examples use them.

Yesterday, I spent a whole day in the search why the variable SystemCoreClock become corrupted in certain cases. The bug was trivial, I got used to write SET_BIT_PER(var, ...) and in one place I automatically wrote SET_BIT_RAM(var, ...) instead of SET_BIT_RAM(&var, ...), the macro accepts var without a single warning... As result the bit was changed in SystemCoreClock not in the var.

So, we have a number of macros with similar names SET_BIT_PER vs SET_BIT_RAM but must use them in different ways. Unfortunately, just change the parameter name is not enough, we can easily miss the difference which is visible only in the implementation of macro.

[eldarkg]

@in4lio I think we shouldn't to make things complex if it isn't need. CLR_BIT_RAM macro name says that it "clear bit in RAM" and doesn't return boolean (not misinterpreted). I think next looks good and simple:

CLR_BIT_RAM_P(pa,b)    (BIT_RAM(pa,b) = 0x00000000)

And param name pa says that his type is a pointer. I am OK with macro name CLR_BIT_RAM_P. ({ ... }) block have slightly another behaviour. It return his last operator result.

[in4lio]

Done.

[eldarkg]

Thanks.