avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] 1.8.1?


From: Erik Walthinsen
Subject: Re: [avr-libc-dev] 1.8.1?
Date: Fri, 30 Nov 2012 08:38:24 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1

On 11/29/2012 11:20 PM, Joerg Wunsch wrote:
Still, if it's not the IDE that does it on their behalf, most of those
professional ARM developers are hosed.  They solely rely on their
(often payware, like CodeSourcery) IDE to do it for them.  If the IDE
doesn't do it, they are standing in about the same rain as an AVR
developer whose device is not supported by the toolchain.

I've looked at using a number of ARM chips (stm32, Freescale MC13224, and others) and constantly run into that problem. I will not use an IDE let alone a manufacturer's IDE, so I have to try to figure out all the arcana for that chip and hope I can get it working in one of the 17 "generic" Cortex toolchains, or roll my own. It's insane, especially when the manuf seems to provide multiple incompatible sets of files.

The AVR approach is somewhat more user-friendly, in that you can add
a single -mmcu option, and then compile your sources the same simple
way as you would e.g. be able to compile code for your host computer.

I gave a talk at DEFCON this last year about MC13224-based 6LowPAN hardware we're trying to get moving, and while I doubt most of the audience understood exactly what I was talking about here, the "-mmcu" function of the avr toolchain is *by far* the best lead AVR has on ARM at this point, for that exact reason.

However, that's not the way the GNU tools would currently work.  And
no, the GCC specs file wasn't really an alternative: first, it would
not work for binutils anyway.  Then, it's got an incomprehensible
syntax (even for seasoned developers), and changes were needed in many
places to add a single device.  In order to be really able to offload
new device support to the end user, it has to be a one-liner (or
perhaps, a one-record addition, like to an XML file), and it must be
possible to do this at run-time, without recompilation.

Honestly I've got to wonder if LLVM does this any better. I know basically nothing about it except that it's not quite up to GCC's standards yet, but it might have potential and be more properly layered.

In the meantime I've built a python script that very carefully goes into all the files in gcc, binutils, and avr-libc that have references to the Xmega parts, and pulls from a master list I derived from Digikey to rewrite all those sections. It's a very poor substitute and doesn't scale to any of the other chips, but it should get the Xmega patch put together with the least possible inconsistency...

For avr-libc, this would be even harder though, as some of the device
support is really compiled in right now.  But I think if the other
tools agreed on such a central device definition file, we could start
an effort to generalize avr-libc as well (perhaps accompanied by a
script that recreates some of the device-dependant header files from a
template file, based on those device definitions).

I think extending AVR-style -mmcu into the ARM world is absolutely possible, *iff* there is a shift in how devices are described as you suggest. Short of entirely new instruction sets, it should be possible to *trivially* define a new processor in the same style as avrdude does currently, and have *all* the tools reference it at run-time. The only thing the toolchain should need a recompile for is new family opcodes, or updated optimizations.

Would it be even remotely practical to do this within the existing binutils/gcc/avr-libc setup? It seems to me that if there were a way of removing the individual devices from the entire binutils/gcc codebase in favor of *nothing* but the "families" (avr5, avr6, atxmega5, etc.) and rewrite the -mmcu handling so it looks at a directory containing the relevant config, crt, linker, and even header files for each chip and hands them off internally (and to binutils) as appropriate.

Basically it would be a thin *top*-level wrapper (inside gcc getopts) around what Johann suggests that people do now (which I've done *once* in coercing gcc to compile to the attiny15), rather than having the -mmcu decisions made all the way down the stack.

Unfortunately as I've said before, I know *very* little about the structure of either binutils or gcc, having only been exposed to the tiny bits that I'm messing with now.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]