Thinking ahead... avr-gcc support for unsupported xmega's

Go To Last Post
43 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. I'm just thinking a bit ahead because I'm not yet ready to jump into the Xmegas. But looking at specs, the Atxmega128a3u is perfect for my upcoming project.

I took a look, and the latest release of avr-gcc doesn't list it as a supported device. The only "u" device supported is the 128a1u (which doesn't seem to be commercially available)

Is it a matter of waiting? Or is it a matter of changing a config file somewhere? (ie. can I add support myself?)

Thanks for help.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What version of avr-gcc are you talking about? The one that comes with WinAVR or the one that comes with AS5/6? The AS5/6 one will probably have support for newer chips before WinAVR (and might already have support).

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh... well, neither. I guess I just meant plain up gnu gcc (was going by this list). I figured since WinAVR hasn't been updated since 2010 that it wouldn't support it. I'd assume AS would, but... well, I don't like AS. Its way too "do it our way or else!" :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What platform are you running on? Windows? Linux? Something else?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My primary setup is Win 7-64. I have VMware running with Ubuntu (whatever the latest stable release was as of last week).

Anyway, I found this thread where a guy by the name of cjoe12 posted his build for Centos. Provided he knows what he's doing... going through his patch files I can see how he added support for the latest chips and I guess I can adopt that. That's sketchy at best without knowing his sources.

I wish I could just "get" AS, honestly. I've downloaded and installed it probably a dozen times and an hour in without accomplishing ANYTHING AT ALL... I end up throwing my hands up and uninstalling it and going back to WinAVR. I'm sure version 6 would have support for their own chips.

- Steven

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I wish I could just "get" AS, honestly. I've downloaded and installed it probably a dozen times and an hour in without accomplishing ANYTHING AT ALL... I end up throwing my hands up and uninstalling it and going back to WinAVR. I'm sure version 6 would have support for their own chips.

Nothing says you have to use the AS5/AS6 IDE to use the toolchain within it? If you want to ditch the bloat from your hard drive simply take a copy of \Program Files\Atmel\AVR Studio N.N\extensions\Atmel\AVRGCC\N.N.N\AvrToolchain\ and that includes the complete toolchain for both avr and avr32. Wherever you put it add the .\bin\ directory to your PATH then you can just "make" from the command line or point an IDE (like AS4, Eclipse, Code::Blocks, etc.) at it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If you want to ditch the bloat from your hard drive simply take a copy of \Program Files\Atmel\AVR Studio N.N\extensions\Atmel\AVRGCC\N.N.N\AvrToolchain\ and that includes the complete toolchain for both avr and avr32. Wherever you put it add the .\bin\ directory to your PATH then you can just "make" from the command line or point an IDE (like AS4, Eclipse, Code::Blocks, etc.) at it.

Or just download and install the standalone toolchain:

http://www.atmel.com/tools/ATMEL...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah but he said he already had it installed. No point downloading yet another N hundred megabytes! ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

s_mack wrote:
[Atxmega128a3u in avr-gcc]

Is it a matter of waiting? Or is it a matter of changing a config file somewhere? (ie. can I add support myself?)

The latest release series of gcc supports something between 1E3 and 1E4 devices and architectures, which are:
Quote:
at43usb320 at43usb355 at76c711 at86rf401 at90c8534 at90can128 at90can32 at90can64 at90pwm1 at90pwm2 at90pwm216 at90pwm2b at90pwm3 at90pwm316 at90pwm3b at90pwm81 at90s1200 at90s2313 at90s2323 at90s2333 at90s2343 at90s4414 at90s4433 at90s4434 at90s8515 at90s8535 at90scr100 at90usb1286 at90usb1287 at90usb162 at90usb646 at90usb647 at90usb82 at94k ata6289 atmega103 atmega128 atmega1280 atmega1281 atmega1284p atmega128rfa1 atmega16 atmega161 atmega162 atmega163 atmega164a atmega164p atmega165 atmega165a atmega165p atmega168 atmega168a atmega168p atmega169 atmega169a atmega169p atmega169pa atmega16a atmega16hva atmega16hva2 atmega16hvb atmega16m1 atmega16u2 atmega16u4 atmega2560 atmega2561 atmega32 atmega323 atmega324a atmega324p atmega324pa atmega325 atmega3250 atmega3250a atmega3250p atmega325a atmega325p atmega328 atmega328p atmega329 atmega3290 atmega3290a atmega3290p atmega329a atmega329p atmega329pa atmega32c1 atmega32hvb atmega32m1 atmega32u2 atmega32u4 atmega32u6 atmega406 atmega48 atmega48a atmega48p atmega64 atmega640 atmega644 atmega644a atmega644p atmega644pa atmega645 atmega6450 atmega6450a atmega6450p atmega645a atmega645p atmega649 atmega6490 atmega649a atmega649p atmega64c1 atmega64hve atmega64m1 atmega8 atmega8515 atmega8535 atmega88 atmega88a atmega88p atmega88pa atmega8hva atmega8u2 attiny13 attiny13a attiny167 attiny22 attiny2313 attiny2313a attiny24 attiny24a attiny25 attiny26 attiny261 attiny261a attiny4313 attiny43u attiny44 attiny44a attiny45 attiny461 attiny461a attiny48 attiny84 attiny84a attiny85 attiny861 attiny861a attiny87 attiny88 atxmega128a1 atxmega128a1u atxmega128a3 atxmega128d3 atxmega16a4 atxmega16d4 atxmega16x1 atxmega192a3 atxmega192d3 atxmega256a3 atxmega256a3b atxmega256a3bu atxmega256d3 atxmega32a4 atxmega32d4 atxmega32x1 atxmega64a1 atxmega64a1u atxmega64a3 atxmega64d3 m3000 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7

It's bit ridiculous to add "support" for every possible suffix like a or p or pa or a1u or a3u or bu or hvb or hva or hve or d3 or a4w or x1 or c1 or d4 or u2 or u4 or u6 or whatever imaginable finite digit-letter combination...

• The compiler won't care for the exact device.
• The assembler won't care for the exact device.
• The linker won't care for the exact device.

The only thing that matters is the architecture, which is one of — again for the latest, officially supported release series:

avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6
avrxmega2 avrxmega4 avrxmega5 avrxmega6 avrxmega7

Consequently, what you have to do to compile code for an "unsupported" device is:

• Compile it for the respective architecture.
• Assembler it for the respective architecture.
• Link it for the respective architecture.

As most users do compile+assemble in one step, this simplifies to:

• Compile-and-Assemble it for the respective architecture.
• Link it for the respective architecture.

What you will need are three things:

1) Device support from header as of avr/io.h
2) Library support
3) Startup code

All this is in the realm of AVR-LibC. Presumably you prefer that Lib-C implementation over newlib or others.

ad 1) This is mainly copy-pasting text from a similar device already supported by AVR-LibC and do some fix-ups to IRQ-vectors, SFRs, signature, etc.

AVR-LibC's headers use built-in defines like __AVR_ATmega8__ to pick device-specific files. If compiled for an architecture, the compiler won't set such device-specific built-in define, of course. Consequently, add the respective -D__AVR_MyDevice__ as used in the new headers to the compiler's command options.

ad 2) Nothing special here — under the assumption that you use AVR-LibC as a Standard C-Library implementation.

However, AVR-LibC ships some device-specific functions that are not part of the C standard. If you like to use them, implement respective functions by hand or rebuild lib[cm].a for your device and use these.

ad 3) Link with home-brew startup-code for your device. Look at the AVR-LibC source for ./crt1/gcrt1.S for an example. Notice that the vector's names are anonymous like __vector_1 and what matters is just _VECTORS_SIZE.

If you find a device in the same architecture that uses the same vector table, i.e. same _VECTORS_SIZE, reusing that device's startup code should work fine.

Using startup code from a device in the same architecture should still be fine if
– The other device's vector table is bigger (some flash will be wasted)
– The other device's vector table is smaller. Will only work if no vectors corresponding to the missing entries are used, of course. So this is kind of hack if you are to lazy to do proper startup code and prefer to run into problems later.

If the linker is called through the compiler driver (avr-gcc) and the link is performed for a device, the compiler driver adds a -Tdata=... to the command options passed to the linker proper (avr-ld) invocation.

Add a -Tdata= that fits the memory layout of your device to the linker command options.

Besides waiting that someone else does the work for you or fixing your local copy, you can also go ahead and add the support to the official GNU GCC, GNU Binutils and AVR-LibC repositories.

These projects are open for contributions. This might be different for private redistributions of respective projects.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, thanks Sprinter! So I'm gathering then, that simply using atxmega128a1u should work fine? At least if I understand what you're saying, and if I understand the concept behind Atmel's Xmega series convention. They both have 128kb, they're both "u" (built-in USB, "fixed" ADC) so the only difference should be that the 1 has extra "stuff", and if I don't use that stuff... I'm golden?

That's easy enough if true. A cursory (very cursory) look at the two pin charts shows that the 100 pin has (obviously) 36 more pins and that is accounted for by way of 3 8-pin ports (which are used for gpio, extra serial interfaces, and an "external bus"), 1 4-pin port (gpio and alternative external crystal connection), and 4 power pairs. So as long as I don't use that stuff... I'm good, is that right? But then I notice some existing pins are used for different alternative functions (well, at least in the diagram. Further down in the charts they are identical - odd).

Or, as you say, I can add my specific chip through some copy pasting and rebuilding... but then that presumes (as does the above paragraph) that I'm making the proper assumptions, which frankly isn't what I should be doing (making assumptions). I'd prefer explicit support, of course. Odd thing is... Studio 5.1 offers it while Studio 6 doesn't.

I don't think its necessarily ridiculous to support every suffix so long as that suffix actually has some meaning beyond package and/or temperature characteristics. The "u" suffix is rather substantial for this series of chips, and I would take a certain comfort knowing that the differences are appropriately accounted for. You obviously have a deep understanding of how this stuff works, which is great... I don't. And I don't think I should have to. A painter shouldn't have to know the chemistry behind his paint in order to apply it to the canvas.

- Steven

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was going to say why bother with all this when I already told you that you can use AS5/6's toolchain (or the separate build if you like) and I was then going to show you the grep'd --target-help output. Only thing is Atmel have screwed that too and the --target-help option does not work properly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It does if you use their further option -mlist-devices

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It does if you use their further option -mlist-devices

Not with the 5.1 version I'm using:

C:\Program Files\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin>avr-gcc --target-help -mlist-devices
avr-gcc: CreateProcess: No such file or directory

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try:

avr-gcc -Wa,-mlist-devices --target-help
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope still nada:

C:\Program Files\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin>avr-gcc -Wa,-mlist-devices --target
-help
avr-gcc: CreateProcess: No such file or directory

But let's assume it runs for you (AS6 perhaps?). Surely the X-U you want to program is listed there?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, its not. That's the problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I say my 5.1 is out of date. I think there's been a later 5.1 and then a 6.0 yet even my early 5.1 has this (see picture). When I build having selected that:

		"C:\Program Files\Atmel\AVR Studio 5.1\extensions\Atmel\AVRGCC\3.3.1\AVRToolchain\bin\avr-gcc.exe"  -funsigned-char -funsigned-bitfields -O1 -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99 -MD -MP -MF "AVRGCC2.d" -MT"AVRGCC2.d"  -mmcu=atxmega128a3u  -o"AVRGCC2.o" ".././AVRGCC2.c" 
		Finished building: .././AVRGCC2.c
		Building target: AVRGCC2.elf
		Invoking: AVR/GNU C Linker

So clearly this toolchain's C compiler knows all about the atxmega128a3u

So just take a graft of the 3.3.1\AVRToolchain part of the tree and you have a compiler capable of compiling, assembling and linking for the atxmega128a3u

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

Or just download and install the standalone toolchain:

http://www.atmel.com/tools/ATMEL...

- Dean :twisted:

That one worked. Thanks Dean. And thanks others.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ho hum:

(you just downloaded what you already had which is what I've been saying all along).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hardly. But thanks anyway.

[Edit for clarification] above, I said

Quote:
I'd prefer explicit support, of course. Odd thing is... Studio 5.1 offers it while Studio 6 doesn't
So I'd have to d/l 5.1 anyway, which is a lot larger and more cumbersome than the package Dean linked to.

[Edit x2] Ok, I guess that's where you presumed I had 5.1... I suppose it reads that way. Anyway, I had 6, not 5.1... and 6 for whatever reason doensn't appear to recognize that chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

and 6 for whatever reason doensn't appear to recognize that chip.

Oh you are kidding. Can Atmel get this thing any more wrong?!? I've avoided the 700MB download for AS6 so far. Looks like that may have been serendipitous!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Oh you are kidding. Can Atmel get this thing any more wrong?!? I've avoided the 700MB download for AS6 so far. Looks like that may have been serendipitous!

Calm down Cliff. AS6 does indeed fully support the ATXMEGA128A3U. I'd hold off downloading the beta however if you have a slow connection as the release is due any day now.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So s_mack is lying?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its not listed in the --help output

I'm certainly not lying. I may very well be mistaken, however. I got VERY frustrated trying to use AVRS6, so perhaps I didn't spend enough time looking.

I uninstalled it, but I seem to recall trying to choose it from drop down lists as well, and it wasn't there. For example, in 5.1 (which I now have installed) if I go Tools-->Programming and look under "Device" it is there... I'm pretty sure that's the procedure I took in 6 and it wasn't there.

But mostly I was going by the "supported devices" listing from the help output.

- Steven

ps. I'm not literate enough in all this to know who is publishing what. "avr-gcc" version 4.3.3 did NOT list it. 4.5.1 did. 4.7.0 did NOT.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So s_mack is lying?

I'm not saying that, I'm just saying I am absolutely certain that applications can be compiled for the ATXMEGA128A3U in AS6. The AU parts were added as a support pack in 5.0 (or perhaps 5.1).

The output of AS6's "avr-gcc -Wa,-mlist-devices --target-help" on my machine (note: internal build, but toolchain should be basically identical:

Known MCU names:
  avr1 avr2 avr25 avr3 avr31 avr35 avr4 avr5 avr51 avr6 avrxmega1
  avrxmega2 avrxmega3 avrxmega4 avrxmega5 avrxmega6 avrxmega7 avrtiny10
  at90s1200 attiny11 attiny12 attiny15 attiny28 at90s2313 at90s2323
  at90s2333 at90s2343 attiny22 attiny26 at90s4414 at90s4433 at90s4434
  at90s8515 at90c8534 at90s8535 ata5272 attiny13 attiny13a attiny2313
  attiny2313a attiny24 attiny24a attiny4313 attiny44 attiny44a attiny84
  attiny84a attiny25 attiny45 attiny85 attiny261 attiny261a attiny461
  attiny461a attiny861 attiny861a attiny87 attiny43u attiny48 attiny88
  attiny80 attiny828 at86rf401 ata6289 at43usb355 at76c711 atmega103
  at43usb320 attiny167 at90usb82 at90usb162 ata5505 atmega8u2 atmega16u2
  atmega32u2 attiny1634 atmega8 atmega8a ata6285 ata6286 atmega48
  atmega48a atmega48pa atmega48p atmega88 atmega88a atmega88p atmega88pa
  atmega8515 atmega8535 atmega8hva at90pwm1 at90pwm2 at90pwm2b at90pwm3
  at90pwm3b at90pwm81 at90pwm161 ata5790 ata5790n ata5795 atmega16
  atmega16a atmega161 atmega162 atmega163 atmega164a atmega164p
  atmega164pa atmega165 atmega165a atmega165p atmega165pa atmega168
  atmega168a atmega168p atmega168pa atmega169 atmega169a atmega169p
  atmega169pa atmega32 atmega32a atmega323 atmega324a atmega324p
  atmega324pa atmega325 atmega325a atmega325p atmega325pa atmega3250
  atmega3250a atmega3250p atmega3250pa atmega328 atmega328p atmega329
  atmega329a atmega329p atmega329pa atmega3290 atmega3290a atmega3290p
  atmega3290pa atmega406 atmega64rfa2 atmega64rfr2 atmega64 atmega64a
  atmega640 atmega644 atmega644a atmega644p atmega644pa atmega645
  atmega645a atmega645p atmega649 atmega649a atmega649p atmega6450
  atmega6450a atmega6450p atmega6490 atmega6490a atmega6490p atmega16hva
  atmega16hva2 atmega16hvb atmega16hvbrevb atmega26hvg atmega32hvb
  atmega32hvbrevb atmega48hvf atmega64hve at90can32 at90can64 at90pwm161
  at90pwm216 at90pwm316 atmega32c1 atmega64c1 atmega16m1 atmega32m1
  atmega64m1 atmega16u4 atmega32u4 atmega32u6 at90usb646 at90usb647
  at90scr100 at94k m3000 atmega128 atmega128a atmega1280 atmega1281
  atmega1284 atmega1284p atmega128rfa1 atmega128rfa2 atmega128rfr2
  at90can128 at90usb1286 at90usb1287 atmega2560 atmega2561 atmega256rfa2
  atmega256rfr2 atmxt112sl atmxt224 atmxt224e atmxt336s atxmega16a4
  atxmega16a4u atxmega16c4 atxmega16d4 atxmega16x1 atxmega32a4
  atxmega32a4u atxmega32c4 atxmega32d4 atxmega32x1 atxmega64a3
  atxmega64a3u atxmega64a4u atxmega64b1 atxmega64b3 atxmega64c3
  atxmega64d3 atxmega64d4 atxmega64a1 atxmega64a1u atxmega128a3
  atxmega128a3u atxmega128b1 atxmega128b3 atxmega128c3 atxmega128d3
  atxmega128d4 atxmega192a3 atxmega192a3u atxmega192c3 atxmega192d3
  atxmega256a3 atxmega256a3u atxmega256a3b atxmega256a3bu atxmega256c3
  atxmega256d3 atxmega384c3 atxmega384d3 atxmega128a1 atxmega128a1u
  atxmega128a4u attiny4 attiny5 attiny9 attiny10 attiny20 attiny40

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

4.7.0 did NOT.

There are no official Atmel builds of the toolchain that use GCC 4.7 - did you install the builds linked here? If so, then yes, those won't have the newer XMEGA support.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh probably... I went about this whole thing in probably most illogical way possible I have no doubt I got myself turned around.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

s_mack wrote:
A painter shouldn't have to know the chemistry behind his paint in order to apply it to the canvas.
If the color bleeches soon after because you picked the wrong pigment you won't have fun.

If the painting peels off the canvas because you chose the wrong binding you won't have fun.

If you kid comes along and is fond of the fancy colors and uses the highly toxical colors like finger paint or as body paint you won't have fun.

It's allways true that you get more out of things if you know about the things you are using. This does not restrict to some compiler option...

If you drive a car and don't know anything about it, we all know it's not good idea.

Learning about what you are using will cost you time, but you will be rewarded later; it's simply an investment.

If you do not invest, you will pay and pay again later, maybe only small amounts, but again and again. And you wonder why others use the same stuff with ease while you have trouble again and again with that "scrap".

clawson wrote:
I was going to say why bother with all this.
It's a general recipe how to add "missing" support. You think this is the last question on "How do I get support for XYZ?"

And what would be the answer if the host was Linux? You just linked such a thread to here.

Atmel does not publish specification of new devices ahead of time.

And even if they did, it's trivial to add support to the toolchain (compiler, assembler, linker). It's a very good starting point for anyone who likes to get involved with the tools and is inclined to contribute some more value to a ∞ performance/cost ratio software.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sprinter... your points are excellent. Mine was simply that we don't all have the time to invest in knowing all things to such a depth. I agree that the best painter is going to be the one that knows how to paint and ALSO know the chemistry behind his craft. And the best AVR programmers are going to be those that know every tool in as much depth as possible. But I would also suggest there's a point at which we build off of others' knowledge and not re-learn what they had to in order to get us here. Afterall, if I were required to know everything about gcc (or anything else really) just to use gcc, then there'd be no point in having gcc (I'd just do what it does myself).

I'm sure some of the best drivers out there have absolutely no idea how their cars work. Just as I'm sure some of the best mechanics out there have no clue how to drive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It's a general recipe how to add "missing" support. You think this is the last question on "How do I get support for XYZ?"

Oh no your answer was excellent - it's just it appeared the OP already had what he needed on his hard drive before he even started. (he did).

There seems little point learning how to build a car when there's one parked on the driveway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
There seems little point learning how to build a car when there's one parked on the driveway.
Oh no, it was not about building a car.

It was just a note on how to adjust the seat and the rear mirrors to comfort you if the settings are nor as you like them, for example after you bought the car or you use your friend's car.

You would really buy new car if the seat position does not fit?

Great market gap! I am going to sell specially customized cars!

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now you're trivializing it. Making an adjustment to your car seat is in no way a good analogy for what is required to make the "adjustments" discussed here.

95% of the population > 16 years old is capable of driving a car with really minimal education and training. You think your programming skills are of that little value? If you had to take 4 years of courses and/or read volumes of books on multiple subjects simply to reach down and adjust your seat... there really would be a market for customized cars.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

s_mack wrote:
Now you're trivializing it. Making an adjustment to your car seat is in no way a good analogy for what is required to make the "adjustments" discussed here.

95% of the population > 16 years old is capable of driving a car with really minimal education and training. You think your programming skills are of that little value? If you had to take 4 years of courses and/or read volumes of books on multiple subjects simply to reach down and adjust your seat... there really would be a market for customized cars.

What do you think is the level of difficulty of the adjustments?

We don't need to change the compiler.
We don't need to change the binutils.
We can reuse libc if only libc-features are needed.
We need to compile/assemble the startup code (you should know how to compile /assemble code) if it cannot be reused.

How difficult is it? Will it take 4 years, really? If it's not like adjust in the seat, then is it like

Adjusting tire pressure?

Mounting a roof rack?

You only drove in the hood in circles for fun and now you have to drive hundreds of miles in the night and it is raining cats n dogs? Like Janet and Brad?

And me, I am Frank? Or Riff?

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, now you've just lost me. I have no idea who those people are.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't know Dr. Frank N. Furter?

Never saw the film with the longest-running theatrical release in film history?

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is that the one with Leonardo Di Craprio where he hangs over a ship's hull shouting, "I'm the Queen of all girls!" or something like that?

I know that was in the theatre a long time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For more than 36 years, really?

I meant the "Rocky Horror Picture Show".

Newly engaged Janet and Brad get lost on a rainy november night. Seeking for help with a flat tire they make some new experiences...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes really. (wtf are we talking about??)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This thread is about "unsupported AVR devices in the avr-gcc compiler". An outline to a general solution to this problem was given; without changing the compiler and thus in a land called "using the compiler" — provided respective architecture support is already present in the compiler.

Then the questions arose how difficult such an apprach is, both with respect to follow the approach and with respect to work out such an approach by reading the documentation or using his own "average compiler user familiar with the tool" knowledge.

To get an impression about the difficulty, you came up with the analogon between "using the compiler" and "using a car".

You said that my analogy of difficulty by some real-world car-examples was to easy, and I proposed some more examples of "using a car".

Here we are.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What's a compiler?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Quote:

4.7.0 did NOT.

There are no official Atmel builds of the toolchain that use GCC 4.7 - did you install the builds linked here? If so, then yes, those won't have the newer XMEGA support.

- Dean :twisted:


What builds linked here?

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's at least one preview build:

https://www.avrfreaks.net/index.p...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is also this link into the same thread pointing to a more recent snapshot, namely avr-gcc 4.7.1 (prerelease) from 2012-03-22:

https://www.avrfreaks.net/index.p...

avrfreaks does not support Opera. Profile inactive.