WinAVR and GCC for Atmel devices

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

I don't use GCC/WinAVR at this time. I am using ICCAVR 7.x
and did not like the ICCAVR version 8. So, I have some interest in using one of the above mentioned.

What is the difference between WinAVR and GCC?

I think I have been spoiled using a commercial based product. I am used to starting an install and everything is then handled by the installer. I like the IDE setup using ICCAVR, makes life easier (at least for me).

Also, I am interesting in being able to use GCC in a Linux environment (Ubuntu 12.04), but it looks complicated to install and setup. I have the GCC installed on the LInux machine in order to experiment. I have been able to write, compile and run several very basic programs. In that environment, LINUX, I have so far been unable to determine where the include files are and what they offer. So, I am thinking that the GCC version for the Atmel AVR are perhaps more like the GNN compiler
I have been playing around with (for the Linux PC) might be the same.

So any advice or suggestions?

Thanks.

I'll believe corporations
are people when Texas executes one.

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

Quote:

What is the difference between WinAVR and GCC?

None whatsoever. WinAVR is a package that contains a January 2010 version of the 8bit avr-gcc compiler.
Quote:

Also, I am interesting in being able to use GCC in a Linux environment (Ubuntu 12.04), but it looks complicated to install and setup.

Umm no. Especially not in Ubuntu:

http://www.wrightflyer.co.uk/avr...

Just follow exactly what I wrote there. But also note that very last point I added just a couple of weeks ago. If you want a "more up to date" avr-gcc for Ubuntu then Atmel's 4.6.2 version is actually better as it has support for some AVR devices that the main trunk development of avr-gcc has.

If you do get the Atmel one it's not a .deb but simply a .tar.gz so you will have to "tar xvzf filenam.tar.gz" it to unpack the contents. As I said in a thread the other day I'd then put a soft-link to it as /usr/local/avr as that's more likely where people might expect to find it. Then like the other text on the page above I'd do an "export PATH" to add /usr/local/avr/bin.

In a Windows environment I think I'd forget WinAVR now and simply install Atmel AS6 which gives you a modern IDE and a copy of that avr-gcc 4.6.2 built for Windows.

In Ubnutu I think I'd get one of those command line tool packages then wrap an IDE around it. Popular choices are Eclipse or Netbeans or, dare I suggest it, Code::Blocks (the same as ICC V8 in fact). Personally I think C::B hits a happy balance between usability and complexity.

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

Thanks clawson. I did not have a lot of luck in using ICCAVR 8, I never did figure out how to get it going with code:blocks.
As you mentioned, installing GCC for Ubuntu, at least for me, is somewhat intimidating. Especially with doing all of the separate component installs. I have been using Ubuntu primarily using the GUI mode.

I did install EMACs, but have not yet figured out how to set it up just in the Linux environment.
I also installed COde:Blocks from the Ubuntu software center but when I opened the software, it locked up the system. I was able to open the System monitor and it showed
that all if the CPU time was used. This is a meerkat based machine and is using the Intel Atom mother board.

I will visit the link you posted and follow through that.
Thanks for the link, now off I go....

I'll believe corporations
are people when Texas executes one.

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

Quote:

. Especially with doing all of the separate component installs. I have been using Ubuntu primarily using the GUI mode.

But that's my point. You do not have to. Bingo600 here wrote a script to build avr-gcc on Linux (see sticky thread at top of this forum). At various major release points he's run that script and done all the hard work for you and the result is a single.deb file (a Debian installation package). As Ubuntu is based on Debian it uses dpkg/apt-get/synaptic to get and install .deb files. So to use one off my website where Bing600 puts the packages he builds you download your chosen .deb (presumably the highest numbered one for either amd64 or i386) and you run a single "dpkg -i filename.deb" command to then install that package. At the end of the day it will have put everything pre-built and ready to use in /usr/local/avr so the ONLY additional step you need to do is add that (or rather than ./bin/ directory beneath it) to your PATH (probably by editing .bashrc). That is all that's required. However his builds only go up to 4.5.x and don't necessarily have all the lastest AVRs supported.

Meanwhile Atmel has got into the Linux game too and they (as linked on the end of my webpage) have a Linux version of their 4.6.2 based "Toolchain". It's a later version with more AVRs but is just fractionally more complex to install because you have to manually extract the .tar file and you have to manually position the files in a suitable place. I guess you could just keep them in a sub-dir of your home directory but I think I'd make them appear in the more general /usr/local/avr place which is the same place that Bingo's packages install to. That could be as simple as a "ln -s" command to make the directory where the files actually are appear as /usr/local/avr

I've run Code::Block in Ubuntu on an Intel Atom board so would not expect problems. Admittedly that was 10.04 not 12.04 so the repo version may be quite different now.

PS to be honest I would go with Atmel's 3.4.1 toolchain (pick AVR8 for Linux 32 for your Intel Atom board). Register (I know!) then download the file.tar.gz to your ~ directory. CD there and just:

tar xvzf file.tar.gz

Whatever "file" is (and it's a stupidly long name) you will now end up with a directory also called ~\file\. Now give the command:

ln -s ~/file /usr/local/avr

which will make the same directory and contents also appear as if it's at /usr/local/avr (you probably need to prefix that command with "sudo" then give your password when asked as you may not otherwise have write access to /usr/local).

Finally use you favourite Linux editor (kate or gedit if you like GUIs, I go for "nano" myself) and in your home directory do:

nano .bashrc

(or whatever editor) then at the end add a line:

export PATH=$PATH:/usr/local/avr/bin

From now on when you start terminals they'll have that directory added to the PATH. To check just type:

avr-gcc -v

and see if you get some output showing that you succeeded in running avr-gcc.

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

wow! That is a lot of info there clawson. I will start working on that. I did download the GCC include file(s) from the Atmel site. Not sure if I don't try the Bingo600 script you mentioned. BTW, Ubuntu is for a 64bit distribution.

If I use the Bingo600 script, will the H files I already downloaded cause any issues? I have not looked at the script yet.

Also. I noticed that when I did a PC C program, compiled it with no errors, I still had to use the path ./program_name. I did figure out I had to make a dir
~/bin. Then the script I had experimented with executed.
So, as you can see, I am still getting up to speed, especially using the command (terminal) mode.

Once again, thank you for your help.
Best regards.

I'll believe corporations
are people when Texas executes one.

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

Quote:

Not sure if I don't try the Bingo600 script you mentioned.

No, do not contemplate building it. You are using Ubuntu. Bingo (or Atmel) did all the hard work. Just get a package and install it. The binaries are built - there's no scripts to run, no binaries to build.
Quote:

If I use the Bingo600 script, will the H files I already downloaded cause any issues?

It was a totally pointless exercise downloading .h files. All these packages have everything you need to build - all the prebuilt library code, all the headers, everything.

It really is as simple as 1 command (.deb) or about 4 or 5 commands I listed above (.tar.gz) to get up and running and building avr-gcc code in Linux.

As for the "./" prefix thing. Yup I've always thought it odd that Unix command shells don't default PATH to "." but this doesn't apply to anything to do with avr-gcc. As I say you will once and for all add /usr/local/avr/bin to you command shell path so from then on all of avr-gcc, avr-ld, avr-objcopy etc. will be instantly runnable. And when you build "executables" for the AVR then just like on Windows you will actually be building AVR format ELF files and then you will use avr-objcopy to extract an Intel .hex file image from that (all this detail hopefully hidden from you either by the IDE you choose or the Makefile you use if you choose to build on the command line with "make").

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

OK, clawson, I will try the Atmel install and your instructions. I will get back when I try it, perhaps by
next week if not sooner.

I'll believe corporations
are people when Texas executes one.

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

clawson wrote:
As for the "./" prefix thing. Yup I've always thought it odd that Unix command shells don't default PATH to "."
It's because it's a multi user environment. If you type
cd /tmp
ls

you don't want to wipe your whole home directory. Anyone with access to the system can put anything called ls in, for example, /tmp.
And it could break the whole system in a fraction of a second if you run these commands as root. And even worse, it can do some nasty stuff for a short time, followed by a /bin/ls (and a rm -f /tmp/ls), so you don't even notice that a user just gained root access to the system.

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

snigelen :
Yes, it is difficult to manipulate the system unless you have a good handle on UNIX/LINUX.
I think I became complacent using Windows to install applications. But, I have been able to use the Ubuntu software to install 'applications' in a similar manner.

I will try to install the GCC package for Atmel and that brings up another area of confusion. If I already have GCC installed and it is operating, at least to compile C programs that run on the Linux PC, is that a conflict with installing another GCC package.:?:

I'll believe corporations
are people when Texas executes one.

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

tubecut wrote:
I will try to install the GCC package for Atmel and that brings up another area of confusion. If I already have GCC installed and it is operating, at least to compile C programs that run on the Linux PC, is that a conflict with installing another GCC package.:?:
No.
The AVR tools get names like avr-gcc .

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

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

Well, I just discovered something else; I had previously
installed the Arduino software and it ran ok on Ubuntu.
I never programmed a Atmel board as I do not have one.
In checking the GCC software using the Ubuntu software
center I noticed that the GCC software was installed.
So I removed it and then later noticed that also removed the Arduino software.
So, did I already have the GCC AVR software installed?
Was that a special GCC configured just for the Arduino?

I'll believe corporations
are people when Texas executes one.

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

Quote:
So, did I already have the GCC AVR software installed?

Yes. Ubuntu Arudino packages dependencies will (used to) install avr-gcc packages as well. (I think this is no longer true, starting with 1.0.1; there were a lot of issues introduced by unix users have essentially random and broken versions of avr-gcc installed, depending on distribution and version and package manager. I think now it includes its own copy of avr-gcc 4.3.2.)

Quote:
Was that a special GCC configured just for the Arduino?

Nope; it was a full avr-gcc. On windows, the Arduino install includes a full copy of WinAVR, and on Mac it includes a full copy of AVR CrossPack. Arduino is somewhat held back WRT compiler version be there not being a newer WinAVR... (OTOH, 4.4 was broken, 4.5 was broken, early 4.6s were broken... I don't know if there IS a post 4.3.2 gcc that is known working in the Arduino environment. (mostly rather odd C++ issues that don't affect most users.))

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

As you just found if you use avr-gcc there's a chance you'll see:

clawson@ws-czc1138h0b:/$ avr-gcc -v
The program 'avr-gcc' is currently not installed.  You can install it by typing:
sudo apt-get install gcc-avr

Don't, whatever you do, do that. It will get you a version of avr-gcc that has been built by Canonical for the Ubuntu repository. It is not a good version (unless things have changed dramatically recently). It misses some part support and some of the important bug fixing patches. This is exactly why Bingo and others have their own builds to make a better job of it.

If Arduino for Ubuntu just had a dependency on avr-gcc from the repo rather than delivering it's own copy (as in Windows) and then later had problems I'm not entirely surprised.

So continue on your current course and see if you can get that Atmel packaged version working.

As also noted gcc for building programs on your PC (the "host" version) will not clash with the version to build AVR code because the cross-compiling versions have names such as avr-gcc (AVR8), avr32-gcc (AVR32), arm-gcc (ARM) or even arm-none-linux-gnueabi-gcc (another ARM version).

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

I've used the Ubuntu supplied gcc-avr since 10.04 without problems (before that I used SuSE with the same experience). I haven't found more bugs there than in any other tool-chain, it's often the same bugs in fact, since they tend to use the same patches that introduce the bugs ;-). Here's the Debian changelog for the last couple of versions.

/usr/share/doc/gcc-avr/changelog.Debian.gz wrote:
* Applied patch from peter green
that removes
the --disable-checking configure option (closes: #645822)

-- Hakan Ardo Sun, 20 Nov 2011 10:34:42 +0100

gcc-avr (1:4.5.3-2) unstable; urgency=low

* Added 57-ctors-dtors-patch.diff patch that fixes GCC bug 45263. It
was ported from gcc cvs by Francois Lorrain
and confirmed by Changwoo Ryu
(closes: #634341)

-- Hakan Ardo Thu, 11 Aug 2011 18:50:38 +0200

gcc-avr (1:4.5.3-1) unstable; urgency=low

* New upstream release (closes: #550985, #594279, #629734)
* Replaced the patch-set with the patch-set provided by Atmel at
http://distribute.atmel.no/tools...
30-gcc-4.5.1-fixedpoint-3-4-2010.patch
31-gcc-4.5.1-xmega-v14.patch
32-gcc-4.5.1-avrtiny10.patch
33-gcc-4.5.1-osmain.patch
34-gcc-4.5.1-builtins-v6.patch
35-gcc-4.5.1-avrtiny10-non-fixedpoint.patch
37-gcc-4.5.1-option-list-devices.patch
38-gcc-4.5.1-bug13473.patch
39-gcc-4.5.1-bug13579.patch
40-gcc-4.5.1-bug-18145-v4.patch
41-gcc-4.5.1-avrtiny10-bug-12510.patch
42-gcc-4.5.1-bug12915.patch
43-gcc-4.5.1-bug13932.patch
44-gcc-4.5.1-bug13789.patch
50-gcc-4.5.1-new-devices.patch
51-gcc-4.5.1-atmega32_5_50_90_pa.patch
54-gcc-4.5.1-attiny1634.patch
56-gcc-4.5.1-atmega48pa.patch

-- Hakan Ardo Sat, 09 Jul 2011 19:26:28 +0200

gcc-avr (1:4.3.5-1) unstable; urgency=low

* New upstream release
* Removed build-depedns on dbs (closes: #576067)
* Updated the patch-set from
http://www.freebsd.org/cgi/cvswe...
patch-avr-libgcc.S
patch-newdevices
patch-xmega
patch-xx-os_main
patch-bug19636-24894-31644-31786
patch-bug33009
patch-bug34210-35508
patch-bug35013
patch-bug11259
patch-bug18145
patch-builtins
patch-disable-ssp
patch-param-inline-call-cost

I don't know if anything essential i missing. (Is there?).

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

Quote:

Replaced the patch-set with the patch-set provided by Atmel

Atmels' 4.5.1 release was dog's breakfast and is part of what gave AS5.0/5.1 such a bad reputation. Their 4.6.2 now in AS6 SP1 build 1938 is MUCH better. I would worry if the repo really has an effectively Atmel based 4.5.1.

Of course the problems may not have affected everyone - some of the faults I can remember are that the new tiny4/5/9/10 support used the wrong LD opecode and on "big" devices the do_copy_data loop used LPM instead or ELPM (or some fault in that area that meant that data beyond the 64KB addressable range was not initialised.

If you are just using stable/traditional AVRs it's quite possible (as I guess was the case for a lot of AS5 users) that the faults won't actually impact you.

I would encourage you to get Atmel's 4.6.2 build for Linux as, so far, that seems to have been proven quite stable.

BTW I wonder how often Canonical rebuild? Atmel's 4.6.2 and the patchset for it have been available for a while. You'd kind of hope the version in the repo might have been rebuilt to reflect this. The latest activity in your log above is now almost 12 months ago.

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

clawson wrote:
Atmels' 4.5.1 release was dog's breakfast and is part of what gave AS5.0/5.1 such a bad reputation. Their 4.6.2 now in AS6 SP1 build 1938 is MUCH better. I would worry if the repo really has an effectively Atmel based 4.5.1

Ok, so there's a good reason not to use the avr-gcc that comes with Ubuntu 12.04, but I guess 10.04 is ok, since it uses the same patches as the latest/last Winavr(?).

I tend to use Atmel's toolchain more and more, as I use some new devices that's not supported in the older versions, and it seems to work well.

clawson wrote:
Of course the problems may not have affected everyone - some of the faults I can remember are that the new tiny4/5/9/10 support used the wrong LD opecode and on "big" devices the do_copy_data loop used LPM instead or ELPM (or some fault in that area that meant that data beyond the 64KB addressable range was not initialised.
That bug, and others, were present in all toolchains with "support" for that family. They have all been fixed in version 3.6.2 (the latest) of Atmel Toolchain.
clawson wrote:
BTW I wonder how often Canonical rebuild? Atmel's 4.6.2 and the patchset for it have been available for a while. You'd kind of hope the version in the repo might have been rebuilt to reflect this. The latest activity in your log above is now almost 12 months ago.

I don't know. That changelog was from a 12.04 installation.

Looking at Debian it seems they use 4.3.5 in stable and have jumped to 4.7.0 in unstable and testing.

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

Quote:

have jumped to 4.7.0 in unstable and testing.

I could have sworn that SprinterSB has said that no 4.7.x before 4.7.2 was trustworthy. Hopefully Debian will move to that before they release.

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

Unable to get the link (ln -s) to work correctly.

After following instructions (clawson) the archive appears to be installed(?).

After downloading the Atmel archive I moved it to the ~/AVR and extracted it there.

This shows the directory structure that extracting the Atmel archive generated:

Quote:
jerryl@jerryl-Meerkat-NetTop:~/AVR/avr8-gnu-toolchain-linux_x86$ pwd

and this is the directory:
/home/jerryl/AVR/avr8-gnu-toolchain-linux_x86

jerryl@jerryl-Meerkat-NetTop:~/AVR/avr8-gnu-toolchain-linux_x86$ ls -la
total 48

and here are the contents :
drwxrwxr-x 12 jerryl jerryl 4096 Aug 17 08:02 .
drwxrwxr-x 3 jerryl jerryl 4096 Nov 13 15:55 ..
drwxrwxr-x 5 jerryl jerryl 4096 Aug 17 07:35 avr
drwxrwxr-x 2 jerryl jerryl 4096 Aug 17 08:04 bin
drwxrwxr-x 4 jerryl jerryl 4096 Aug 17 07:35 doc
drwxrwxr-x 3 jerryl jerryl 4096 Aug 17 07:33 i686-pc-linux-gnu
drwxrwxr-x 2 jerryl jerryl 4096 Aug 17 07:37 include
drwxrwxr-x 2 jerryl jerryl 4096 Aug 17 07:33 info
drwxrwxr-x 3 jerryl jerryl 4096 Aug 17 08:02 lib
drwxrwxr-x 3 jerryl jerryl 4096 Aug 17 08:02 libexec
drwxrwxr-x 4 jerryl jerryl 4096 Aug 17 07:35 man
drwxrwxr-x 5 jerryl jerryl 4096 Aug 17 08:02 share

jerryl@jerryl-Meerkat-NetTop:~/AVR/avr8-gnu-toolchain-linux_x86$


Can someone point to the proper syntax to perform the link (ln -s)?

Also, I guess this will all be in the command line mode (terminal mode).
Also, hoping that I get this working, what would I best use as a programmer?
If I understand the Arduino correctly, one of those boards can be used as a programmer?

I usually use XP PRO , AS4, ICCAVR, STK500 and Dragon to develop and program the
target. I am hoping to use the Linux PC in the future.

I am using a Meerkat based PC , Ubuntu 12.04. This particular PC does not have a 'real' serial port
only USB port(s).

Thanks.

I'll believe corporations
are people when Texas executes one.

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

You don't have to make any links. Just add $HOME/AVR/avr8-gnu-toolchain-linux_x86/bin to PATH. If you use bash you can, for example, put this in ~/.bash_profile

export PATH=$HOME/AVR/avr8-gnu-toolchain-linux_x86/bin:$PATH

or add it to your Makefile(s), something like this

PATH := $(HOME)/AVR/avr8-gnu-toolchain-linux_x86/bin:$(PATH)
============================================================
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Also, I guess this will all be in the command line mode (terminal mode).

Doesn't have to be:

sudo apt-get install codeblocks

As for "programmer" you are going to need avrdude for that.

Attachment(s): 

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

snigelen wrote:
30-gcc-4.5.1-fixedpoint-3-4-2010.patch
This patch introduces wrong integer multiplication, see a thread we had some days ago.

avrfreaks does not support Opera. Profile inactive.

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

Well, I thought I was moving right along with using gcc-avr and CodeBlocks.
I started a new project and entered a very simple program. When I attempted to use
that compile file I get the following:

Quote:
Compiling: main.c
/bin/sh: 1: avr-gcc: not found
Process terminated with status 127 (0 minutes, 0 seconds)
0 errors, 0 warnings

So, I am not sure how to set up CodeBlocks to use gcc-avr or so it seems.

I did add gcc-avr path to the PATH.

I don't have any hardware to actually program an AVR but was hoping to at
least be able to compile a simple program and then be able to display the various
files generated by the compile. I was hoping to at least be able to inspect the hex output
file. I was thinking then I could sneaker net the hex file to my XP PRO pc, use AS4 and either
a STK500 or Dragon to do a test burn to see how things were working.

I am thinking that it is a must to know how to use makefile and make or things won't
get setup right. But, I was also convinced that a simple AVR program (if no errors) would
also be able to use the hex file to test out.

I also think that if I can get better educated in using CodeBlocks I would be able to use
the ICCAVR version 8. After I upgraded to version 8 I was never able to use it and just stayed
with ICCAVR version 7.

But, when I am able to use the Linux tools, then I would not need to use the XP PRO pc. :)

So, any help, advice will be greatly appreciated.

EDIT: Went back and looked at $PATH:
This is the $PATH edited with each on separate line, easier to see.

Quote:
/home/jerryl/bin:
/usr/lib/lightdm/lightdm:
/usr/local/sbin:
/usr/local/bin:
/usr/sbin:
/usr/bin:/sbin:
/bin:/usr/games

I thought I changed this, not sure how to make permanent.

I'll believe corporations
are people when Texas executes one.

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

You don't need to have your compiler in PATH in order to use it with Code::Blocks.

I did a test with Ubuntu 10.04. Installed codeblocks, it detected "GNU AVR GCC Compiler" I had installed with "sudo apt-get install gcc-avr".

A small test did not compile, it insisted in looking for include files in /usr/include wich doesn't work. I had to remove it like I did here (and /usr/lib from lib search path), then it worked.

But if I don't want to use that toolchain? I have, for example, Atmel toolchain installed in /usr/local/avr8-gnu-toolchain-linux_x86_64 (nothing of it in PATH).

I went to Settings/Compiler and debugger... again and copied the AVR toolchain to a "Atmel AVR Toolchain". In that configuration I changed "Compiler's installation directory" under "Toolchain executables" to the directory mentioned above. That's all I had to do to use that toolchain.

And I have SprinterSB's 4.7.2 toolchain for windows installed under wine (for testing). To use that I had to make the programs executable (chmod +x), and make symlinks in it's bin-folder to names without .exe, like

for k in *.exe; do ln -s $k `basename $k .exe`; done

(or simply add .exe to the entries under "Program Files").

I have Bingo's toolchain installed under /usr/local/avr, very easy to add that one too.

So now I have four toolchains I can easily choose from.

Last Edited: Fri. Nov 16, 2012 - 04:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

So, I am not sure how to set up CodeBlocks to use gcc-avr or so it seems.

There are many tutorials / forum posts on other sites about using Code::Blocks but basically you need to go to the Settings menu and then the Compiler and Debugger... entry. In the panel that appears click the top droplist and make sure "GNU AVR GCC Compiler" is selected. In passing note that on the tab you first see you probably will later need to tick some options (like -Os for optimization) but for now, in the multi-tab dialog click "Toolchain Executables" and make sure the path in the top box is set right. I have m,ine pointed at /usr/local/avr/bin (because that's where I have the avr-gcc executable and other tools) but I think you may have it in another place. Now just OK from the dialog and you should be able to build.
Quote:

I am thinking that it is a must to know how to use makefile and make or things won't
get setup right

No - Code::Blocks (or whatever IDE you choose) isolates you from Makefiles but you maybe do need to know some of the important compiler options like -Os.

As ICCAVR V8 uses Code::Blocks then using one will help you with the other.

Quote:

I thought I changed this, not sure how to make permanent.

Well at a command shell you can use "export". So:

export PATH=/foo

means this remains in place for everything else then done in that command shell.

If you want it done for every command shell you open then edit you can edit ~/.bashrc - in mine the last line is:

export PATH=$PATH:/usr/local/avr/bin

which adds /usr/local/avr/bin to the end of the PATH.

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

If I use this path below and execute avr-gcc as shown below, then it executes.

Quote:
jerryl@jerryl-Meerkat-NetTop:~/AVR/avr8-gnu-toolchain-linux_x86/bin$ ./avr-gcc -v

I am not sure the exact command to add this properly to the $PATH in hopes this will now allow CodeBlocks to to compile a simple test file.

Not sure use if I use the export to $PATH or export to bashrc or if that is what is required.
Reading a Linux manual on Command and Shell programming, it seems unclear to me. :(

Quote:
clawson wrote: to place in ./bashrc:
export PATH=$PATH:/usr/local/avr/bin

I interpret that to mean I can add to the .bashrc:

~/AVR/avr8-gnu-toolchain-linux_x86/bin$ 

Can the directory '\avr8-gnu-toolchain-linux_x86' be renamed to something smaller or is that particular part of the path name tied to the original install?

I did notice that if I use the GCC compiler (for the PC) from CodeBlocks it works as I would expect. It compiled and then runs the code on the PC.

Also, it is confusing to me, the difference between
using $HOME and '~' in a command line. It must be that
$HOME is just a variable name to be used if using the $PATH command.

I wish to thank everyone for assisting me in getting this Linux avr-gcc and codeblocks to work.

And one final question: AVRDUDE is just software? All along I thought it was a programmer. If I understand the details correctly, then AVRDUDE will work with the STK_500 on a Linux PC. Ofcourse no AS

I'll believe corporations
are people when Texas executes one.

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

~ is just short-hand for your home directory. It will be something like:

/home/your-user-name/

In fact I'd take a guess that on your machine it is:

/home/jerryl/

So if you want to quote an absolute path to the toolchain and not rely on ~ then it would be:

/home/jerryl/AVR/avr8-gnu-toolchain-linux_x86/bin

So in Code::Blocks just paste exactly that into the box I described earlier where you set the location of the "Toolchain Executables" for the avr-gcc compiler.

As I said before if you do want to give this a more sensible name then you could give the command:

ln -s /home/jerryl/AVR/avr8-gnu-toolchain-linux_x86 /usr/local/avr

in which case /usr/local/avr/bin would be a synonym for /home/jerryl/AVR/avr8-gnu-toolchain-linux_x86/bin.

Quote:

And one final question: AVRDUDE is just software?

Yes:

http://www.nongnu.org/avrdude/

===========================================================================

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

OK, I have been batting zero here. Nothing really works and after attempting to make some of the changes I noticed that it will now not even build a regular GCC program as before. Also noticed that starting a new project seemed different, it did not place the start code as before for the avr-gcc option.
I did go and change the toolchain executables but that didn't work either.
So, I used synaptic and deleted code blocks. The avr-gcc seems to be ok.

So, if I reinstall the codeblocks package (from the recently downloaded tar.bz file), is there a preferable location/path to install in. I was thinking it would still have to install in the same directory/path as avr-gcc ?

After the next try I will stop bothering freaks and just put this aside until my blood pressure returns to normal.

I'll believe corporations
are people when Texas executes one.

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

Code::blocks stores your configuration in the .codeblocks folder in your home directory. Maybe you want to remove (or rename) that to start over from the defaults?

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

Ok Ok, I tried everything , now my patient has expired and I am making no progress, so thanks to all, this is not the path for me.
I will delete codeblocks and forget about it until something commercial for linux comes along that perhaps I can afford.
Back to XP Pro for AVR work.

Thanks to everyone who gave advice and comments.

I'll believe corporations
are people when Texas executes one.

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

Quote:

something commercial for linux

I fear you may have missed the point of Linux!

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

Yea clawson I know. I understand that open source means that
there are many contributors that make up the various applications
and how they may work together. But, I notice there are some commercial packages on the market for linux. I am thinking of QT and Real Software and others. It would seem that there must be a market for linux apps that are available and require about the same level of expertise as windows to install and use.

But, this did not work for me and that is my lack of linux knowledge.
So, if something doesn't work then it is time to move on and
go back to what I know I can use.

I think that the support on getting this to install and work has been excellent from freaks.net. Just could not get it right here.
And after making changes to attempt to get things working, I noticed that other things no longer worked. And this is even after uninstalling, removing .codeblocks directory and all contents ,and reinstalling the app ,it still would not work the same as the very first install. I tried to install from synaptic as well as the sudo install as suggested in a previous post.

I can continue to use my windows AVR applications to use the AVR devices and it is sad to have to admit defeat on using linux in this area.
Perhaps in a few weeks I will dip my toe in the water again....

I'll believe corporations
are people when Texas executes one.