[En-Nut-Discussion] Do we need something like sbv/sbi to complement sbi/cbi?

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Sun Jan 1 17:26:50 CET 2012


Hello,

a happy new year to all!

>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz at googlemail.com> writes:

    Ulrich> Hi!  Am 29.12.2011 17:11, schrieb Uwe Bonnes:
    >> Hello,
    >> 
    >> in Ulrich's devnut_m3n, some function used sbi( ) and cbi()
    >> 
    >> Obvious, the stm libraries define register bits with their bit value
    >> #define TIM_SR_UIF ((uint16_t)0x0001) and not bit positions like
    >> #define TIM_SR_UIF_BIT 0
    >> 
    Ulrich> There is a discrepancy in the usage of these defines. I prefer
    Ulrich> the bitmask instead of the bitnumber while a good compiler
    Ulrich> should translate both things to the correct value without adding
    Ulrich> extra code.  But sometimes I prefer the bit number again....

But I see one major obstacle: 
The ST provided headers mostly only define bit values, not the bit position.

As I don't know of a macro to invert the BV() macro, we have to add bit
position defines to the header files.
Should these definitions go into stm32_<device>.h?

    Ulrich> If you need to setup a device and you have 10 lines of _BV() |
    Ulrich> _BV() | _BV... it is unreadable code...  But if you need to set
    Ulrich> a bit fast / atomic it is best to use the bitband area but the
    Ulrich> macros need the bit number for address calculation.  The impact
    Ulrich> is pretty high if you switch an SPI-Select by old style gpio |=
    Ulrich> _BV(cs) or via bitband.

Aggreed

    Ulrich> So you cannot define a stric rule of how to declare register
    Ulrich> bits. For configuration masks are comfortable, for toggling and
    Ulrich> fast switching numbers are needed.

...
    Ulrich> Please look at the stm32_gpio.c and it's relevant .h file.  All
    Ulrich> gpio functions are single cycle single access regardless of
    Ulrich> their names.

    Ulrich> Using the bitband functions as a reference any Cortex Register
    Ulrich> can be access atomic for switching single bits in it.

Isn't the STM GPIO a bad example. With the BSRR registers, atomic access is
also possible without bit banding...
So i think  e.g.
#define GpioPinSetHigh(bank, bit) \
    GPIOMEM(GPIOBITBAND((bank+GPIOBBREG_BSRR), (int)bit)) = 1
could be happily replaced with
#define GpioPinSetHigh(bank, bit) GPIOMEM(GPIOBBREG_BSRR, BV(bit))
and
#define GpioPinSetLow(bank, bit)  GPIOMEM(GPIOBBREG_BSRR, BV(bit+16))

But for other devices the remark about bitbanding still holds.

    >> The s/cbi macro expands in devnut_m3n expands like #define cbi(_reg,
    >> _bit) outr(_reg, inr(_reg) & ~_BV(_bit)) and was used like cbi(
    >> &TIM->SR, TIM_SR_UIF ); and so things got wrong.

    Ulrich> You can check the bitband access from gpio and transfer it to
    Ulrich> any register of the Cortex. It is importand that the bitband
    Ulrich> macros expect the bit-number not the bit mask.

Again, the ST Headers mostly lake the Bit number and only define the
bitvalue

    >>  The coding style rules say that direct register access like
    TIM2-> SR |= TIM_SR_UIF
    >> is deprecated. So either explicit writing outr(_reg, inr(_reg) &
    >> _mask) is needed, or some macros to do so. In my tree I added
    >> 
    Ulrich> For Cortex it doesn't make any difference and it is the
    Ulrich> preferred method to use register pointers as ARM architecture in
    Ulrich> general does not need any inr or outr things.

    >> #define sbv(_reg, _mask) outr(_reg, inr(_reg) | _mask) #define
    >> cbv(_reg, _mask) outr(_reg, inr(_reg) & ~_mask) #define
    >> bv_is_set(_reg, _mask) ((inr(_reg) & _mask)) != 0)
    >> 
    Ulrich> For compatibility or coding style ( even I hate this typing
    Ulrich> overhead making code unreadable) you can substitude inr( reg) by
    Ulrich> (reg) and outr( reg, v) by (reg) = (v)

But http://www.ethernut.de/en/documents/programming-style-guide.html tells:

"Don't use the IOREG = value, value = IOREG notation
 Use outb(), outw(), outr(), inb(), inw() or inr(). 
 This allows trapping and emulation."

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

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------



More information about the En-Nut-Discussion mailing list