On Wed, Nov 12, 2014 at 1:47 AM, Joern Rennecke <joern.renne...@embecosm.com> wrote: > On 11 November 2014 16:22, Joey Ye <joey.ye...@gmail.com> wrote: >> * 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. Indeed. Took a look at the patch and I have to say it is a quite smart idea.
> >> 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 I would think of a separate project, where people can add new NCU configuration there independent to GCC. Thanks, Joey
