compiler, linker, assembler and binary command lines can now be modified
using the hooks mechanism. Also, '--any_placement=first_fit' linker option
is now used only on LPC4088 using this mechanism, in order to preserve
compatibility with the other targets.
- Linker script is based on LPC1768
number of NVIC is 16 (CORE) + 53 (M4 in LPC43xx) = 69,
therefor, reserve at the top of RAM0 (address:0x10000000)
to relocate NVIC vector table
- startup file is based on startup_ARMCM4.S in CMSIS V3.20
change NVIC name for cortex-M4 of LPC43xx
- add GCC_ARM for LPC4330_M4 in python scripts
- add some descriptions for GCC_ARM
Updated CMSIS DSP to latest version (CMSIS-SP-00300-r3p2-00rel1.zip)
Build system changes to be able to preprocess assembler sources before compiling them:
- GCC: use gcc '-x assembler-with-cpp'
- ARM: preprocess first, then assemble (two separate commands)
- IAR: added macro definitions and include directories to the assembler command line
Removed CORTEX_ARM_SUPPORT restriction for the DSP libraries.
Tested: LPC1768 with ARM, GCC_ARM and IAR, LPC11U24 with ARM.
build_api.py now support macros defined at compile time, so build.py and
make.py can be used like this:
$ make.py/build.py <options> -DMACRO1 -DMACRO2=VALUE2 ...
Initial support (activate with "-o analyze"). Not working well with IAR
for now (partially because of a bug in goannac++ which was reported to
Red Lizzard).
The dependency file generated by GCC might contain more than one
dependency listed on a single line, which wasn't taken into account by the
GCC dependency fille interpreter. This commit fixes this issue.
In gcc4mbed, I have been running with "-Wall -Wextra" and then
disabling a couple of noisy warnings that result. In particular, I
disable the unused-parameter and missing-field-initializers warnings.
The first commonly goes off for implementation of virtual methods or
other overridable functions where not all parameters are required for
every override. I don't find the second warning to be all that useful
anyway since missing structure field initializers will be set to 0
according to the C language specification. The RTOS code uses this
language feature and I see no reason that it shouldn't :)
From Adam Green, regarding using -fno-delete-null-pointer-checks:
"I would argue that on Cortex-M processors, it is more dangerous to not
have it. The compiler can actually generate incorrect code because it is
making an incorrect assumption (that reads from a NULL pointer will throw
an exception.) The GCC for ARM developers should actually never enable
the delete-null-pointer-checks optimization for Cortex-M processors.
There is a comment in the GCC manual that indicates, "Some targets,
especially embedded ones, disable this option [delete-null-pointer-checks]
at all levels." Not having this flag is pretty risky on the current
versions of GCC_ARM. Just to clarify, this flag doesn't enable an
optimization...it disables an unsafe optimization."
dinau
Emilio Monti
Bogdan Marinescu
0xc0170
hototogi
Andreas Rebert
Bogdan Marinescu
Adam Green
pbrier
Joe Turner