Re: bit band macro names from Cortex-M3
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Le 08/12/2011 10:54, Ilija Kocho a écrit :
I don't understand your comment: in the Cortex-M3, bit band allows manipulating a single bit inside a 32 bits value in the peripheral area and in some parts of the internal MCU RAM. There is no allocation issue, it's just a very handy memory remapping feature that maps 32 megs of fake address space for each mega of 'real' addresses concerned. The LPC17XX chips have two such areas, one for the upper 16/32KB of internal RAM (the GPIO pin block is mapped in the same area), one for all MCU peripherals.Another way to specify bit-band area is by means of sections. Then you declare ordinary variables with section attribute and ld will allocate just enough memory for bit-band space. Ilija
For instance, in my use case, which was wrong, it should have been*(volatile cyg_uint32 *)CYGHWR_HAL_LPC17XX_BITBAND_PERI(ADC_CR,chan->channel)=1;
It replaces: x=ADC_CR; x|=(1<<chan->channel); ADC_CR=xIn ISR/DSR processing it's a clear win, every single single bit read-modify-write operation in peripheral registers can be replaced with a single bit band operation much faster to do, without involving any shift operation. It's even more secure if ever the involved peripheral register can have bits changing of state during a classical read-modify-write operation.
And AFAIK, the compiler/linker can't be aware of the bit band feature: it's a MCU option provided by ARM and the chip designer chooses to implement it or not, so the -mcpu=cortex-m3 can't consider it as a feature always available for all Cortex-M3 chips. I don't see how one could benefit from bit-band without explicitly using some kind of macro/function.
Bernard -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss