View topic - unsupported devices and Atmel

Search

unsupported devices and Atmel

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum

Author

Message

int1

Posted: Oct 07, 2012 - 01:02 PM

Joined: Sep 04, 2004
Posts: 28

It seems Atmel are developing their own branch of the AVR GCC toolchain (current v3.4.1 with gcc 4.6.1) separate from the official GCC http://gcc.gnu.org
Unfortunately Atmel's version of the toolchain have supported all available AVR devices, while the official GCC is lagging behind, missing support for many newer xmega devices. Atmel have released patches so it would seem these could be applied to the latest official gcc, but all my attempts at this have failed.

Can someone explain why the contrast in device support between the two toolchains ?
Looking at the source of both toolchains I found the modifications necessary to add new xmega devices. It does not appear too difficult which makes me wonder why the lack of support.

Note: Although it is possible to use toolchain with the -mmcu set to one of the AVR variant names 'avrxmega2', 'avrxmega3',... et. I found this may not provide correct start-up code for the device. For example, selecting devices with USB will generate interrupt vector table that is one entry too short.

Adam

SprinterSB

Posted: Oct 07, 2012 - 01:33 PM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

int1 wrote:

Unfortunately Atmel's version of the toolchain have supported all available AVR devices, while the official GCC is lagging behind, missing support for many newer xmega devices. Atmel have released patches so it would seem these could be applied to the latest official gcc, but all my attempts at this have failed.

Are you saying that you posted patches to gcc-patches@ / binutils@ / avr-libc-dev@ for review and they where refused? Probably license or copyright or formal issues then.

Quote:

Can someone explain why the contrast in device support between the two toolchains ?

Because nobody integrated them in GCC. Nobody ever sent patches to gcc-patches@ or binutils@ with these extensions. At least none that I know of.

Quote:

Looking at the source of both toolchains I found the modifications necessary to add new xmega devices. It does not appear too difficult which makes me wonder why the lack of support.

Becaue people don't contribute to avr-gcc / avr-binutils. Not eaven for "not too difficult" stuff.

Quote:

Although it is possible to use toolchain with the -mmcu set to one of the AVR variant names 'avrxmega2', 'avrxmega3',... et. I found this may not provide correct start-up code for the device.

This is a reasonable approach. All you need from compiler / binutils is core support, what you don't need is explicit device "support".

For the bits of AVR-Libc (headers, crt*.o, bits of AVR-Libc that are beyond C e.g. EEPROM support, ...) this is different; you have to get it from somewhere.

Sources of startup code is in ./crt1/gcrt.S in AVR-Libc. Headers is likely just copy and paste from a sister device.

_________________
avr-gcc News • ABI • Options • 4.7-Windows • Inline Asm

clawson

Posted: Oct 07, 2012 - 06:53 PM

Joined: Jul 18, 2005
Posts: 62207
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

Can someone explain why the contrast in device support between the two toolchains ?

For that one you need to track down someone at Atmel for comment. It seems ludicrous that they've chosen to "go it alone".

_________________

JohanEkdahl

Posted: Oct 07, 2012 - 07:40 PM

Joined: Mar 27, 2002
Posts: 18506
Location: Lund, Sweden

Quote:

For that one you need to track down someone at Atmel for comment.

I believe you should have added half a dozen of emoticons to that, Cliff.

Going from history, there will be no comments from anyone at Atmel re this more than possibly "We are planning to push out patches up-stream".

I seem to recall that this has been said quite a long time ago [Certified Understatement of the 1st Degree, With Honors and Mention in Despatches].

SprinterSB

Posted: Oct 08, 2012 - 08:18 AM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

clawson wrote:

Quote:

Can someone explain why the contrast in device support between the two toolchains ?

[...] It seems ludicrous that they've chosen to "go it alone".

Not necessarily.

Besides the legal issues, that mainly depends on how much resources are available to (sup)port newer versions and bring patches upstream.

It is considerably faster to change your local copy than to pass a review and get the changes upstream.

However, this situation might change if you want to keep up with current development. I'd guess forward-porting patches can become a real annoyance, in particular if there are changes in the official repositories.

This is the case for GCC: The 4.6 avr backend has 16 files total. The current development has 35 files total.

Besides the functional changes (more than 50 bugs fixed compared to 4.6.2), there have also been code clean-ups which means many small changes in many places sprinkled all over the sources.

All this makes porting patches not easier; very likely you run into a conflict with each and every patch against 4.6 if you try to use it against 4.7 or newer.

_________________
avr-gcc News • ABI • Options • 4.7-Windows • Inline Asm

int1

Posted: Oct 10, 2012 - 04:56 AM

Joined: Sep 04, 2004
Posts: 28

SprinterSB wrote:

clawson wrote:

Quote:

Can someone explain why the contrast in device support between the two toolchains ?

[...] It seems ludicrous that they've chosen to "go it alone".

Not necessarily.

Besides the legal issues, that mainly depends on how much resources are available to (sup)port newer versions and bring patches upstream.
...

All this makes porting patches not easier; very likely you run into a conflict with each and every patch against 4.6 if you try to use it against 4.7 or newer.

That this is true. Every gcc patch from Atmel toolchain will fail in gcc 4.7.1. The code structure has just changed too much. Atmel toolchain appears to be using avr-libc 1.80 and binutils 2.22, which are current official releases. Patches for these projects worked without a hitch.

I am new to using patch/diff and to making contributions. I am interested bringing over device support given the Atmel's patches (gcc-4.6.1, binutils-2.22, avr-libc-1.8.0) and device header files. Can someone give me a few pointers to the correct procedure to submit these changes ?

SprinterSB

Posted: Oct 10, 2012 - 05:54 AM

Joined: Dec 21, 2006
Posts: 1483
Location: Saar-Lor-Lux

int1 wrote:

SprinterSB wrote:

All this makes porting patches not easier; very likely you run into a conflict with each and every patch against 4.6 if you try to use it against 4.7 or newer.

Easiest part is avr-libc because it is muss less restrictive WRT patches and integrating them into the project.

For avr-libc subscribe to the avr-libc-dev@ and maybe also to the avr-gcc-list@ mailing lists. These lists are low traffic.

For Binutils and GCC the reading is "Contributing to GCC".

If you are willing to contribute and resolved the legal issues, development takes place in the Binutils mailing list and the GCC mailing lists.

The formal procedure is to post the patch to the binutils@ resp. gcc-patches@ mailing lists.

If you are still interested and have questions, you can ask in the avr-gcc-list@ and I'll answer there, so that you can also get familiar with mailing lists and how they work.

Besides all that, adding new devices is a new feature and are appropriate for the current development version of GCC, which is future 4.8.0.

Older releases are "bug fixes and documentation changes only" releases.

However, supporting new devices in GCC is a trivial thing provided respective core support is present. So you may be lucky with proposing to backport the changes to the 4.7 release series and get it approved by one of the avr port maintainers. For maintainers, see MAINTAINERS file.

_________________
avr-gcc News • ABI • Options • 4.7-Windows • Inline Asm

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR GCC forum

AVRFreaks.net

Search