This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: bit band macro names from Cortex-M3
Le 08/12/2011 10:54, Ilija Kocho a écrit :
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
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.
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=x
In 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