[Bug 1001442] LPC17XX bit band macro proposal

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001442

--- Comment #3 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-01-10 14:51:19 GMT ---
(In reply to comment #2)
> Perhaps the macros (especially for RAM but others could be considered) could
> have generic stem CORTEXM rather than LPC17XX. Could they be applied at
> architecture level?

I've checked on the ARM site: 

- on Cortex-M3, bit banding is described as a feature always available (the
word 'option' is not used) :
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/Behcjiic.html

- on Cortex-M4, bit banding is described as an optional feature:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439c/Behcjiic.html

eCos uses 'cortex-m' to describe the architecture generally and does not make
difference between M0/M3/M4, etc. Now maybe all chip manufacturers will
implement bit band?

However if bit banding is provided, it's always at the same place, it seems
that it has been designed mostly for peripherals registers or for peripherals
that maps into RAM, like the GPIO pins in the LPC17XX.

> 
> Also, could we consider defining a USER_SECTION for bit-band area? Then we
> shall have an easy way to put objects there by just __attribute__ing.
> USER_SECTION can be added to present ldi scripts without breaking
> compatibility.

This is necessary if one wants to use bit band for RAM, for instance to place
device descriptors or buffers at location that allow bit banding.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.