[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 #5 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-01-26 18:32:19 GMT ---
I did more reading on the topic (chapter 5, page 88 of "The Definitive Guide to
the ARM Cortex-M3" by Joseph Yiu, google, datasheets etc.).

Since gcc doesn't know about bit-band the only real advantage of bitband in our
case seems to replace atomic read-modify-write of a single bit, an operation
that requires today to lock/unlock interrupts and/or DSR execution. This would
be completely different with another compiler knowing about the bitband stuff,
but in that case we would not need to care about bitband ;)

SRAM is a problem: on some MCU, all SRAM can be accessed with bitband ops
(STM32 but I looked only at 1 datasheet of this family:
STM32F105xx/STM32F107xx). On other MCU, only parts of SRAM is eligible
(LPC17XX/Kinetis). This is also the case for any MCU with external RAM.

So bitband accesses for RAM can't be easily defined at the arch level, they
could be defined only at platform level, probably by defining a RAM section
with a specific name and then placing explicitly some variables in this
section. But since accessing the concerned RAM also mean using specific macros,
because gcc knows nothing about bitband so it won't optimize accesses to the
declared region, it's more likely this interest mainly the application, or
drivers specific to a platform so RAM bitband ops can be provided by other
means than the common HAL or arch HAL.

GPIO: they can be mapped to peripheral memory or SRAM. However what to do with
a GPIO pin, once the pin is set as a GPIO pin, is quite simple: have the pin
set to 0 or 1. I didn't look in the datasheets of several modern 32bits MCU,
but if ever, for a MCU, setting a pin state requires a read-modify-write on a
register handling more than one pin, then bitband can also solve a problem I've
seen on smaller MCU: one pin is handled by a thread, another pin on the same
port is used by another thread or an interrupt: any access to the involved pin
port must be atomic. LPC17XX, beside bitband, provides registers that allow
clearing/setting a particular pin without troubling the other pins on the same
port, so in that case bitband isn't interesting. But if one knows of a MCU that
have no such registers, then bitband is an excellent solution because we are
back to the problem of setting a single bit's value atomically.

All in all, the only situation common to any M3/M4 MCU is when accessing a
peripheral register, for operations clearing/setting a single bit, and
especially if updating this bit must be done atomically.

GPIO handling could be done also, but if there is no real need for it...

New proposal (I'm ready to be flamed), higher level macros describe what they
must do, not how they do it:

- common HAL offers:

(I propose the common hal to allow code re-use for drivers while having drivers
unaware of the bitband feature)

 - HAL_PERIPHERAL_BIT_SET(address,bit_number,bit_value): set a bit's value in a
peripheral register. Without bit-band it does a read-modify-write sequence with
HAL_READ/WRITE_UINT32(). However since this macro does not provide any real
gain even with bitband ops, it could be avoided.

 - HAL_PERIPHERAL_BIT_SET_ATOMIC(ptr_to_lock_function,
                                 ptr_to_unlock_function,
                                 address,
                                 bit_number,
                                 bit_value)

   Without bitband, it does the job of HAL_PERIPHERAL_BIT_SET() but bordered
with calls to the lock/unlock function (Function arguments could be removed and
have the macro to always use ISR lock/unlock, or the macro name could state if
it is atomic regarding ISR, DSR or thread, choose whatever fits eCos the most).

- cortex-M HAL (cdl) has interface 'HAL_PERIPHERAL_BITBAND'.

- cortex-M HAL (include) defines bitband macros for peripheral area, so macro
names won't change between different platforms. The peripheral macro could be
what I initially proposed.

- LPC17XX/STM32 and other concerned MCU implement this interface. Platforms
having chips without bitband (M0, M1, M4 without bb option) do not.

- LPC17XX platform also includes SRAM & GPIO macros, to avoid users
re-inventing the wheel (and using different names) if they need the macros.
Kinetis/STM32/Anything users/maintainers choose to do the same or not.

- When 'HAL_PERIPHERAL_BITBAND' is implemented, HAL_PERIPHERAL_BIT_SET{_ATOMIC}
resolve(s) to bitband op(s) in the peripheral area only.

- GPIO / SRAM bitband accesses are let to user code and/or platform specific
drivers.

   Bernard

-- 
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.