> -----Original Message----- > From: avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org] On > Behalf Of Erik Walthinsen > Sent: Friday, November 30, 2012 9:38 AM > To: avr-libc-dev@nongnu.org > Subject: Re: [avr-libc-dev] 1.8.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.
Good feedback! > > 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, Cool! Do you have any public links to your talk? > 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. I know that ARM GCC has a similar switch. IIRC, it only selects the core. > > 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 terms of the code, yes it is, I think, better layered. But that's mainly because GCC is quite a mess. I'm not sure if LLVM necessarily solves the problem any better. FYI, there's an open source project that adds the AVR backend to LLVM. It's currently on SourceForge (name: avr-llvm). > 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. Guys, the main point of this thread is to get avr-libc 1.8.1 out the door. I'll I was asking for was help with the avr-libc bug list. I understand the desire to reorganize the world to make it sane. I'd like that, too. Yes, it's a big task. If anyone is really serious about doing that, then let's put a plan together that can actually be worked on. Maybe that would be a good reason to move avr-libc to 2.0. But I'd really like to have an avr-libc 1.8.1 release. Eric Weddington _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
