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.
If the build system finds a file named mbed_config.h, it will automatically
define a HAVE_MBED_CONFIG_H macro. Various libraries/components can use
this mechanism to provide compile-time configuration for user projects.
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.
A new hooks mechanism (hooks.py) allows various targets to customize
part(s) of the build process. This was implemented to allow generation of
custom binary images for the EA LPC4088 target, but it should be generic
enough to allow other such customizations in the future. For now, only the
'binary' step is hooked in toolchains/arm.py.
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."
Bogdan Marinescu
0xc0170
hototogi
Mihail Stoyanov
Andreas Rebert
Bogdan Marinescu
dinau
Adam Green
pbrier
Emilio Monti
Joe Turner