On 08.12.2011 11:19, Bernard Fouché wrote: > > 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.
Following your reference (0x20000000) I am referring to AHB RAM (actual base addresses are slightly different). [snip] > 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. Instead of using raw memory it is possible to define a bit-band section within ahb_sram_bank0 or ahb_sram_bank1 region. Then with section __attribute__ you can instruct linker to store the variables in that section. I find it convenient because you don't need to take care for required space. On a second thought you don't even need a special section. You can use the existing ones: .ahb_sram0 or .ahb_sram1. Then for bit-band alias addresses you can use your macros. Ilija -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
