Include avr tools with Linux download.

[GoogleCodeExporter]

What change would like to see?

There should be a package, too, for people that want to install it the "Linux 
way", but the .zip download should include the avr tools (so we know the 
avr-gcc version works, etc.).

Original issue reported on code.google.com by dmel...@gmail.com on 22 Jul 2010 at 6:10

[GoogleCodeExporter]

This patch let's the Linux verson use bundled tools if they are present, but 
preserves the current behavior if no toolchain is present.

Original comment by paul.sto...@gmail.com on 21 Feb 2012 at 3:15

Attachments:

• linux_path.diff

[GoogleCodeExporter]

I've finished testing the 32 bit toolchain.  I tested Ethernet, Firmata and USB 
Host Shield libraries on 5 different boards.  All work.  I did discover a minor 
bug in Firmata on Mega, but the same bug happens when Firmata is build with the 
Mac version.

Here is the 32 bit Linux toolchain.

Original comment by paul.sto...@gmail.com on 23 Feb 2012 at 1:51

Attachments:

• avr_tools_linux32.tar.bz2

[GoogleCodeExporter]

Here is the 64 bit toolchain, also tested with 5 boards, Ethernet Webserver, 
StandardFirmata, and USB Host Shield 2.0 "board_qc".

Original comment by paul.sto...@gmail.com on 23 Feb 2012 at 7:38

Attachments:

• avr_tools_linux64.tar.bz2

[GoogleCodeExporter]

Thanks for doing this!

Original comment by dmel...@gmail.com on 24 Feb 2012 at 2:41

• Changed state: Accepted
• Added labels: Milestone-1.0.1

[GoogleCodeExporter]

Just now I got yet another user email with an incompatible linux toolchain (eg 
"error: 'prog_char' does not name a type").

It will be a real relief when 1.0.1 is published with a known-compatible linux 
toolchain!  I don't want to seem impatient, but I am eagerly anticipating the 
day when Linux users get the same quality Arduino experience Mac and Windows 
users have enjoy.

Original comment by paul.sto...@gmail.com on 25 Feb 2012 at 10:44

[GoogleCodeExporter]

I added these:

https://github.com/arduino/Arduino/commit/784232c6a509245aafd8f821cd3f15903d5da2
bd
https://github.com/arduino/Arduino/commit/ee537dd53eedaa898bf24b686b23d0b609cdee
2c

The build.xml is a bit sketchy (e.g. the 64-bit archive is unzipped on top of 
the 32-bit one), but it seems to work.  If anyone wants to clean it up, that 
would be great.

Original comment by dmel...@gmail.com on 28 Feb 2012 at 8:29

• Changed state: Fixed

[GoogleCodeExporter]

I cleaned up the build.xml process:

https://github.com/arduino/Arduino/commit/c128aac7614192dcde1ad552e1919009c5cd47
7c
https://github.com/arduino/Arduino/commit/de8c051f38f8874504953faa857f017717dd55
91
https://github.com/arduino/Arduino/commit/c5c41bc5318e4a426dbb5cfe64d1501680fbff
06

Original comment by dmel...@gmail.com on 29 Feb 2012 at 9:43

[GoogleCodeExporter]

Nice!  I'm really looking forward to Linux users getting the same tools as Mac 
& Windows (and an easy answer for the regular emails I get on this - especially 
those Gentoo users who refuse to use a better distro)

It probably makes little difference, but tar on linux supports a -xjf option, 
where "j" means to uncompress bzip2 on-the-fly, like "z" does for gzip.  That 
could avoid the separate uncompress bunzip step and write only one uncompressed 
copy to disk instead of 2.

Original comment by paul.sto...@gmail.com on 29 Feb 2012 at 9:55

[GoogleCodeExporter]

What about support for 'newer' chips? E.g. there is currently no support for 
say ATtiny4313 at all. Also I suppose we non-windows users can rely on the fact 
that the tool-chain will be updated for all platforms with equal priority.

Of course ultimately this should be handled by Atmel (how about actively 
submitting patches back to gcc guys!?!), but they have chosen to stick to a 
windows-only mentality. May they rot in hell for that.

Original comment by madworm_...@spitzenpfeil.org on 12 Mar 2012 at 11:07

[GoogleCodeExporter]

Wow, those are some awefully strong words directed at a company that is indeed 
maintaining cross-platform open source software.  Sure, Atmel only publishes 
Windows binaries and their proprietary IDE is Windows only, but the Linux 
distros and CrossPack for Mac are indeed syncing to gcc 4.5.1+patches as 
maintained by Atmel.  The latest Ubuntu packages, for example, are based on 
Atmel's published code.  I personally am very grateful Atmel started investing 
the effort to keep the code maintained, when pretty much everyone else dropped 
it.  They have indeed gone to great lengths to contribute the AVR patches back 
to the community.  I believe the current arrangement was made in a spirit of 
cooperation with the gcc developers.

As for using a newer toolchain on Linux, my patch makes that easy.  Just delete 
the hardware/tools/avr directory.  Then Arduino will attempt to run whatever 
AVR toolchain is installed on your system.  You can install any version you 
like.

But really, you don't even need to do that much.  In time, after 1.0.1 
releases, the distros will package it.  They'll build from source and their 
packages will almost certainly use the AVR toolchain they package.  If you're 
using a good distro, it'll probably work.  But if your distro is one of those 
which does a terrible job maintaining its packages *cough*Gentoo*cough*, 1.0.1 
will be a self-contained program that should "just work" and save you hours of 
frustration debugging broken software builds.

If you would like to contribute, a simple way would be to test the 1.0.1 
release candidate as throughly as possible, before the release is made in a 
couple weeks.  Here's the Linux files:

Linux (32-bit): http://files.arduino.cc/downloads/arduino-1.0.1-rc1-linux.tgz
Linux (64-bit): http://files.arduino.cc/downloads/arduino-1.0.1-rc1-linux64.tgz

Original comment by paul.sto...@gmail.com on 12 Mar 2012 at 1:45

[GoogleCodeExporter]

Well, strong words are sometimes necessary. And depending on ones point of view 
thing look quite different.

I don't know how bad Gentoo is with keeping their AVR packages up-to-date, but 
at least with respect to avr-gcc / avr-libc openSUSE isn't a great deal better. 
If I hadn't found the build scripts for the toolchain on avrfreaks.net, I would 
still be waiting to use my ATtiny4313 chips - or maybe I would have had to use 
a different distro in a VM (which sucks).

In my personal 'happy happy joy joy' world, Atmel would provide all patches + 
source code + a nice understandable manual and or a build script for the VERY 
SAME toolchain that is shipped with their latest "Studio" behemoth. Not 
scattered in many folders hidden away on some obscure webserver in norway, but 
in one single zip-file that is available for download on their main site - 
without forced registration.

Before I had found the build-script on avrfreaks.net I actually tried to 
compile the compiler / bin-utils / avr-libc with the manuals I had found on 
these relevant sites. So I ended up with "vanilla" avr-gcc 4.5.1 - no 
ATtiny4313 support. What else...

Trying to find all the patches that were necessary to get this thing going was 
hell. 

This should definitely NOT be that hard.

Original comment by madworm_...@spitzenpfeil.org on 16 Mar 2012 at 3:47

[GoogleCodeExporter]

And if Microchop / Xilinx / Altera and the likes manage to give native max-os / 
linux IDEs + toolchain to their happy users, why should I not bitch about Atmel.

I like their chips so far, but regarding the IDE they are simply acting stupid. 
And using a world Mr. Torvalds seems to like, I thing they are brain-damaged to 
stick to windows only.

Original comment by madworm_...@spitzenpfeil.org on 16 Mar 2012 at 3:54

[GoogleCodeExporter]

I meant to say Microchip of course.

Original comment by madworm_...@spitzenpfeil.org on 16 Mar 2012 at 3:55

[GoogleCodeExporter]

And as nice and important it is to have the Arduino IDE self-contained and 
identical on all platforms, having a tool-chain that is available system-wide 
is not to be neglected. That gives the user the freedom to use whatever IDE 
seems best, as the default paths are set properly.

If the linux distros should indeed start to package the new IDE it is only to 
be hoped that they don't drop their current tool chain in favour of that. 
Having both would be best, current versions, fully patched. Ideally pulled from 
a central source (Arduino and Atmel).

Original comment by madworm_...@spitzenpfeil.org on 16 Mar 2012 at 5:46