[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