More useful support for low-end ARM architecture

[Joern Rennecke]

On 11 November 2014 16:22, Joey Ye <joey.ye.cc@gmail.com> wrote:
> Markus,
>
> -mmcu probably will not work for ARM architectured MCUs. Reason are
> * Confusion. -mcpu is encouraged and already widely used for ARM
> architectures. Introducing -mmcu will be very confusing.

It' just a matter of bundling specifications.  -mcpu specifies an
architecture and
tuning option.
-mmcu specifies that (it you have an -mcpu option, you best translate
it to that,
otherwise you can skip that step), plus additional things that pertain the the
parts an mcu consists of besides an mcu.

> * Expensive effort. Either supporting none, or supporting all. There
> are large number of MCUs from ARM eco-system partners. Supporting all
> of them is a large project.
> * Maintance nightmare. Having GCC developers to input and maintain
> vendor specific configurations is inefficient and error-prone.
> * Failed schedule dependence. Having -mmcu actually means whenever
> there is a new MCU introduced into market, GCC has to be updated to
> describe it. Given GCC's release cycle (once per year) and the
> frequency of MCU release (could be tens each year), GCC will never be
> able to catch up.

These kinds of issues were why I re-implemented the avr -mmcu option
with the SELF_SPEC mechanism to read a device-specific spec file.

As long as a new mcu can be described with the existing toolchain facilities
(e.g. a new combination of existing I/O support, some different parameters
 describing RAM / flash sizes), a new spec file can be distributed together
with a few hardware-specific library/crt files to support a new mcu with
an existing compiler.

> Further more all the board/MCU specific configurations are already
> described in CMSIS and variant of GUI based toolchain for ARM MCU.
> Replicating then in GCC does not sounds a right thing to do for me.

Yes, better to have a script that translates this info into a suitable spec file
and copies any required files in the appropriate installation places.
Not sure what kind of Copyright/licensing issues that would entail, though.