1. added the possibility to redirect stderr to stdout in utils.run_cmd
2. synch.py now calls the above run_cmd in redirect mode instead of the
old 'cmd' that doesn't intercept standard streams. This makes it easier
for an external tool to intercept the output of 'hg'.
There were lots of overlaps in the code for LPC810 and LPC812, including
duplicated source files. This commit adds a TARGET_LPC81X_COMMON folder in
both HAL and CMSIS, this folder keeps common code for the targets.
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.
1. Added: GCC_CR toolchain ID for LPC2368. (targets.py)
2. Modified: Startup codes for GCC_ARM and GCC_CR toolchain.
3. Verified: "ticker" and "basic" test program works well, so far.
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."