Sorry if this is in the wrong forum - mods please move if necessary.
Anyway, the compiler we use (GCC) is currently at version 6.1. There were a few 5.x releases, and most of us (for AVR and in general) use version 4.x.y (i.e. 4.8.2, 4.9.2, etc...)
Does anyone have experience and/or an opinion as to whether or not it would be a good idea to "upgrade" to the version 6.x family? Of course, I know that this would involve downloading source and compiling it... no problem here on my end.
I just would like to know if v6.x is "better" (or not), "stable" (or not) and if I should update both my AVR toolchain and Linux toolchain to version 6.1
I installed 6.1.0 today only because that's the version the author of a bootloader I'm working on is using but I don't have any immediate plans to use it with the IDE.
Aren't we somewhat dependent on Atmel source changes that are not integrated into the latest gnu version of the compiler? The latest Atmel compiler is 4.9.2
(Also, alas, the things that the core gcc people do frequently seem to be "not good" for the AVR.)
westfw:
Aren't we somewhat dependent on Atmel source changes that are not integrated into the latest gnu version of the compiler? The latest Atmel compiler is 4.9.2
(Also, alas, the things that the core gcc people do frequently seem to be "not good" for the AVR.)
I assume it doesn't matter. If I compile GCC for the AVR target and use the "../configure --prefix=$PREFIX --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2" configure options, it builds for the AVR... right?
I can't imagine that a source package is released where some parts "aren't ready yet".
Concerning your last line (and what Robin2 said, probably the best idea IS just to leave well enough alone. I mean, what's the difference going to be? A few microseconds faster code? A few bytes less code? Who cares? (I don't).
I installed 6.1.0 today only because that's the version the author of a bootloader I'm working on is using but I don't have any immediate plans to use it with the IDE.
Actually, to use a new GCC with the IDE, all you need to do is either relocate the supplied compiler to some other directory that isn't in your path, or delete it altogether.
As long as GCC and friends are in your path (as well as AVRDUDE), the IDE will find and use it.
Quite a few years ago when I first started with Arduino, I "upgraded" my AVR toolchain with the newest source at the time (I compiled it). Then I went through a lot of grief to map out the directory structure of the included toolchain so that I could place the new files where the old ones were.
I don't recall how I discovered it, but the location of the files is irrelevant... ad long as they are in the executable path (that sure made things easier.
Now I have the IDE by itself (no toolchain) and the AVR-GCC toolchain installed as a separate entity (which I also use stand-alone with C/CPP files and a Makefile).
It's actually easier (for me anyway) to use a text editor on the source, then "make" the code, then AVRDUDE it into the AVR and see if it works. Even if I do use the IDE, I still use the external editor and only use the IDE as a "compile and upload it" button. I even use an external serial terminal instead of the one in the IDE (although it IS a pain to have to close the serial terminal each time before I upload new code... two different things connected at the same time to the same serial port doesn't work very well!
Krupski:
Actually, to use a new GCC with the IDE, all you need to do is either relocate the supplied compiler to some other directory that isn't in your path, or delete it altogether.
I realize that, but I like to use the stock IDE so I am on the same page as the typical users of the projects I am involved in and can more easily find and report bugs to the Arduino developers. This is also why I like to do everything in the Arduino IDE, with all its limitations and annoyances. I've encountered quite a few publicly released "Arduino" projects that don't even work right with the Arduino IDE because the author is using Eclipse or something.
If I compile GCC for the AVR target and use the "../configure --prefix=$PREFIX --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2" configure options, it builds for the AVR... right?
What's usually missing is support for the newer chips in the "-mmcu=atmega328pb" compile switch. Since "AVR" is actually a good dozen or more minor variants, each with it's own startup files, libraries, and link maps, this is relatively significant... (ok, perhaps not for the official AVR boards. But a bunch of the add-on avr packages need it - attiny1632 isn't supported by the older compiler from 1.0.x, for example.)
I can't imagine that a source package is released where some parts "aren't ready yet".
I laugh! Did you not notice that essentially every gcc release between 4.3.2 (shipped with the original arduino versions) and 4.8.x (included in IDE 1.6.x) had some major bug that caused problems for would-be arduino users? It was a big problem for linux people who were getting their avr-gcc package separately from the arduino IDE package, eventually resulting in the IDE needing to include its own set of compiler binaries.
It was a big problem for linux people who were getting their avr-gcc package separately from the arduino IDE package, eventually resulting in the IDE needing to include its own set of compiler binaries.
Sorry, with Debian Linux I never have problem with the packaged version by Debian.
Arduino was still with 4.3.2 since Debian (1.0.5) was with 4.8, and it worked.
I am not a specialist, I am a poor electronician, but for example Servo lib IDE 1.6.5 use always "SIGNAL" macro which was still deprecated before 2002 ( two year before first release of Wiring and three years before the fork of Wiring by M Banzi).
In 1.0.5 Debian version, "SIGNAL" was replaced by official macro "ISR".
Perhaps (I am not a specialist) some other cases like this one are at the origin of "big problems" you are talking about with some other Linux distributions.
Unfortunately, since the Arduino fight, Debian stop to support arduino IDE.
westfw:
Aren't we somewhat dependent on Atmel source changes that are not integrated into the latest gnu version of the compiler? The latest Atmel compiler is 4.9.2
(Also, alas, the things that the core gcc people do frequently seem to be "not good" for the AVR.)
Opening up this can-of-worms topic I noticed today that Arduino 1.8.5 is using a version 4.8.3-2014-q1 of the gnu toochain, Atmel Studio 6.2 has 4.8.4.371 , and McAtmel Studio 7.0 comes with a version 6.3.1.508, which seems to be a 6-2017-q2 update. Right now I am using the SAMD21G-based Arduinos but I am looking ahead to the roomier and faster SAMx5y family. Does anyone know if being this far behind in the toolchain will cause any problems?
