[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.
- Re: [avr-libc-dev] 1.8.1?, (continued)
- Re: [avr-libc-dev] 1.8.1?, Weddington, Eric, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Erik Walthinsen, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Weddington, Eric, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Joerg Wunsch, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Weddington, Eric, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Erik Walthinsen, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Georg-Johann Lay, 2012/11/29
- Re: [avr-libc-dev] 1.8.1?, Weddington, Eric, 2012/11/29
- Re: [avr-libc-dev] 1.8.1?, Georg-Johann Lay, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Joerg Wunsch, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?,
Erik Walthinsen <=
- Re: [avr-libc-dev] 1.8.1?, Weddington, Eric, 2012/11/30
- Re: [avr-libc-dev] 1.8.1?, Erik Walthinsen, 2012/11/30