And one learns to "accept" the warnings , even EW has to live with them.
I assume you're not able to use the Debian install packages from Cliff's page http://www.wrightflyer.co.uk/avr...
Actually I had forgotten about Cliff's packages....
Thanks for the link. I see he DOES have BOTH the x86 and AMD64 versions. What I DON'T know is if he built them under pure Debian or a 'buntu flavor.
The only possible problem might be compatibility between Debian and Ubuntu. *SOME* Debian packages are NOT compatible with Ubuntu (and visa versa) even though they are BOTH .deb in structure. I'm running Linux Mint which uses the Ubuntu repository for most packages. Naturally the mix of libraries is part of the issue, so when unsure it's better to just build it from source on the system where it will be used. (No, I'm NOT a 'BSD fan).
Cliff didn't build them at all - I just let Carsten (Bingo) upload the files he builds to my webspace.
Until now i have only used Ubuntu LTS to build the .deb packages on Cliff's page.
Either 8.04 or 10.04
At some time i begun to indicate the build distro in the packagename.
avr-gcc-4.5.1-avrfreaks-2011-dec-29-u10.04.x64.deb
^^^^^
|
Means Ubuntu 10.04
I use Virtualbox , for the buildhost systems. And at the moment i still have an Ubuntu 10.04 installed in a 32 bit engine , and another in a 64-bit engine.
Btw: The "Special Static" was build with the "real" winavr-2010 patches , and even though it's build under U-8.04. It might work under a 10.04.
Ohh: I have seen the recent posts about a .deb error in the latest Ubuntu 12.xx
Atm. i don't have a Ubuntu 12 installed , so there isn't much i can do.
Ohh: I have seen the recent posts about a .deb error in the latest Ubuntu 12.xx
Atm. i don't have a Ubuntu 12 installed , so there isn't much i can do. /Bingo
Hmmm, well I'm running Linux Mint 13 64 bit, which is based on the Ubuntu 12.04 repositories.
Currently there seems to be an error on the FreeBSD server , so getpatches.sh fails
If this is still a problem see here https://www.avrfreaks.net/index.p...
As it's unpatched binutils, the avr-size don't know about avr's
Use : avr-size for displaying the "old size info"
As it's unpatched binutils, the avr-size don't know about avr's
Use : avr-size for displaying the "old size info"
$ avr-size twi_demo.elf
text data bss dec hex filename
3616 54 101 3771 ebb twi_demo.elf
configure: error: gmp.h cannot be found or is unusable.
checking for asprintf... (cached) yes
and
gcc-4.9.1/libcilkrts/include/internal/metacall.h
gcc-4.9.1/libcilkrts/configure.ac
../make-avr-gcc/buildavr-gcc.sh: line 251: cd: gcc-4.9.1/mpfr: No such file or directory
(../make-avr-gcc/buildavr-gcc.sh) patching MPFR source
configure: error: gmp.h cannot be found or is unusable.
checking for asprintf... (cached) yes
and
gcc-4.9.1/libcilkrts/include/internal/metacall.h
gcc-4.9.1/libcilkrts/configure.ac
../make-avr-gcc/buildavr-gcc.sh: line 251: cd: gcc-4.9.1/mpfr: No such file or directory
(../make-avr-gcc/buildavr-gcc.sh) patching MPFR source
I remember getting a similar error with libiberty when I was building simulavr from source. Simulavr didn't include libiberty source, but gcc-4.9.2 does, so I'm not sure yet what the problem is...
I have no special talents. I am only passionately curious. - Albert Einstein
I think I found a bug in the build script. In the buildavr.log I found the following:
cp: cannot stat `gmp-6.0.0a/*': No such file or directory
This is from the following line in the build script:
cp -rfp ${gmpbase}/* ${gccbase}/gmp
The problem is the script assumes the basename of the gmp archive (gmp-6.0.0a) is the name of the directory created when the archive is extracted. However the directory name in gmp-6.0.0a.tar.bz2 is gmp-6.0.0 (no 'a' suffix).
I manually copied the gmp source files and re-ran the build script.
I have no special talents. I am only passionately curious. - Albert Einstein
That seems like a sensible explanation to the error , and yes the immediate cure would be to manyally copy the gmp source files , or to extract the gmp sources , rename the directory to the "a" name , and repack it.
I'm probably not going to update the buildscript , as it's only a few capable people using it today , and i expect that they can do the same reasoning as you.
Ok, I'm game, where does one start to get AVR 8 support with ATA6614Q device?
I downloaded the Linux stuff from Atmel and found the headers have the device but it looks like they are at version 4.81, if I'm going to battle this I should at least use the latest source.
The WINAVR stuff is not they answer, it appears the supported devices stopped a few years ago.
I tried AS 6.2 but it doesn't respond well to my Windows 7 x64, Windows 10 x64 appears to be functional but that is a beta setup, not production and AS 6.2 does not have git.
I still have to read the stuff from Atmel, that might answer a few questions.
Oh, Bingo, I found your deb for Raspberry PI, 20 hours? I probably don't want to know what your hobbies are....
For latest Atmel device support you are (currently) better off sticking to Atmel builds. So while 4.9 may look enticing I'd just take Atmel's 4.8.1 and use that for the time being. Atmel haven't released a toolchain for a while so I rather suspect they are waiting for the 4.9 dust to settle and we may see one shortly anyway.
They are working (see the check in history at the AVR-LibC repo and all the activity from Atmel employees) to push their private changes for added device support back upstream so the generic build will mirror their own local build at which point it won't be necessary to have an Atmel one at all - but that's still work in progress and until then the Atmel builds remain the best option - especially for "none mainstream" devices like the one you want to use.
I sort of assumed the posting on the website might be part of the auto-build process. Perhaps that last step simply does not work for some reason or maybe it was that the build of the AMD64 version did fail for some reason?
Last but not least, where do I put the header files? The file structure seems to be vastly different for each build of the AV tool chain, the Eclipse AVR add in can't find them.
The avr-gcc etc are in ./bin and the base of the includes are at ../avr/include/ from there - that would be the directory with stdio.h and so on. Then all the AVr specific stuff is in an ./avr/ from there (that is ../avr/include/avr/ from the ./bin/) which is why io.h is referred to as <avr/io.h> in AVR programs.
To be honest I don't know why you don't just get the .tar.gz from atmel.com and unpack it (though I understand the current issue with no linux64 build).
Had to give up on AVR Linux, the tools are 4.81 and the Eclipse AVR add in does not pick up the arv/io.h file so it will not allow selection of a MCU. I did a git and found where he was parsing the directories but couldn't figure out why it was failing.
Atmel Studio 6.2 (AS) on Windows 10 was working until they installed the latest build, it killed all the USB drivers, didn't like them, they were not branded by Microsoft so they killed them. Several application from the 'Store' died too so Atmel is not alone.
I restored a snap-shot of my Windows 7 workstation system before I installed AS and installed AS again, after it installed the first time I ran it AF told me it had an update, 100mb or so later it was install and now AS on Windows 7 x64 is working.
Here is the deal: gcc 4.80 ~ 4.82 are known to be faulty, the current compiler for AVR8/32 is gcc 4.81 for ARM 4.84 so is it safe to use 4.81 on an AVR8 device?
Yes but note that ALL compilers have bugs. GCC is pretty good with its release schedule so some get fixed quite often but 4.8.1 (and 4.9.2) will have bugs. You just have to hope (as with all compilers) you don't hit one that affects what you happen to be trying to do at the time. Having said that I consider 4.8.1 from Atmel's build to be pretty stable.
(ah "masm"! - those were the days! having used the CP/M assembler before it the thing seemed so "grown up" when I first used it!)
Posted by dbrion0606: Mon. Nov 17, 2014 - 10:18 AM
1
2
3
4
5
Total votes: 0
Well, this building script seems to work good on a RPi : it takes hours, but generates avr libraries. However, there is a small flaw: usually, prefix is used to denote the directory where the results (compiler, gas, libraries, doc) will go : it may be in a small disk; the place where one builds (huge amount of *.o, ...) can be in a separate disk (it is cleaned after building, but it eats disk space), at least in a distinct directory. This does not matter with usual disks, even USB keys -one can install x86 - GNUlinux on a USB stick now-. But RPi "disk" is a SD card : it is expensive (twice as USB sticks), and maybe wear out : seems a bad idea not to separate the building directory trees from the installed one.
But RPi "disk" is a SD card : it is expensive (twice as USB sticks), and maybe wear out : ...
fyi, there's a creation using the Raspberry Pi Compute Module that contains a 1TB SATA laptop hard disk. In the following, go thru the Kickstarter link.
Iknew one can mount external usb disks (rotating ones, with a low price per GB): this was the way I got avr-gcc built,, with salvaged laptop 250GB disk and an adapter. One can even, atleast theoretically, boot from it -only the fat part of the RPi SD is mandatory -; but , if new , this makes price double ... Main issue is that one cannot, with this script, build on the hard disk and move the result into the SD, "prefix" being used to denote the downloaded sources, the temporary directories to untar and compile (I know one can make mount points, but it is not what comes into mind) and the result which should go into the SD in a classical configuration....
Well, thanks Chapman for the information. I knew that one can use an external -USB- rotating disk (price per GB is very low) -one can even boot from it, only the FAT part of the SD is mandatory- but it is not a standard configuration, doubles the price and makes connectivity complicated . I got avr-gcc compiled on an external -250GB, in 3 parts- USB HD but I cannot -maybe a copy works, if generated compilers /libraries are directory-tree independant...- put it into the SD as directories to download sources , directories to untar and compile and result directories are in the same tree denoted by "prefix" (I did not try to fix it with mount points during buils, as it is not standard).
Nice to hear
And one learns to "accept" the warnings , even EW has to live with them.
I assume you're not able to use the Debian install packages from Cliff's page http://www.wrightflyer.co.uk/avr...
/Bingo
- Log in or register to post comments
TopActually I had forgotten about Cliff's packages....
Thanks for the link. I see he DOES have BOTH the x86 and AMD64 versions. What I DON'T know is if he built them under pure Debian or a 'buntu flavor.
The only possible problem might be compatibility between Debian and Ubuntu. *SOME* Debian packages are NOT compatible with Ubuntu (and visa versa) even though they are BOTH .deb in structure. I'm running Linux Mint which uses the Ubuntu repository for most packages. Naturally the mix of libraries is part of the issue, so when unsure it's better to just build it from source on the system where it will be used. (No, I'm NOT a 'BSD fan).
- Log in or register to post comments
TopCliff didn't build them at all - I just let Carsten (Bingo) upload the files he builds to my webspace.
- Log in or register to post comments
TopUntil now i have only used Ubuntu LTS to build the .deb packages on Cliff's page.
Either 8.04 or 10.04
At some time i begun to indicate the build distro in the packagename.
I use Virtualbox , for the buildhost systems. And at the moment i still have an Ubuntu 10.04 installed in a 32 bit engine , and another in a 64-bit engine.
Btw: The "Special Static" was build with the "real" winavr-2010 patches , and even though it's build under U-8.04. It might work under a 10.04.
Ohh: I have seen the recent posts about a .deb error in the latest Ubuntu 12.xx
Atm. i don't have a Ubuntu 12 installed , so there isn't much i can do.
/Bingo
- Log in or register to post comments
TopHmmm, well I'm running Linux Mint 13 64 bit, which is based on the Ubuntu 12.04 repositories.
- Log in or register to post comments
TopCurrently there seems to be an error on the FreeBSD server , so getpatches.sh fails
If this is still a problem see here https://www.avrfreaks.net/index.p...
/Bingo
- Log in or register to post comments
Top@26-feb-2013
Updated the buildscript with working file mirrors (getfiles.sh)
/Bingo
- Log in or register to post comments
TopI can't download the script.
- Log in or register to post comments
TopGiven that Atmel have a 4.7.2 pre-built for Linux is there really any point?
- Log in or register to post comments
TopIt's great to have such a script.
- Log in or register to post comments
TopI have a feeling that the patches for the 4.5.1 script , on the freebsd server has been taken down.
I have included the patches in the 4.5.2 zip file.
So skip the get-patches.sh step.
I also updated to build the new avrdude 6.1
/Bingo
- Log in or register to post comments
TopJörg just released avrlibc-1.8.1
I have updated the buildscript in the first post to use that one.
The previous script is attached here (if anyone still wants 1.8.0) , note i haven't tested it on Mint17 (Ubuntu 14.04).
/Bingo
Attachment(s):
- Log in or register to post comments
TopI had to test the new avrlibc-1.8.1 , and Cliff wanted to use _flash etc. So avr-gcc 4.5.1 won't do.
Now building avr-gcc-4.9.1 and binutils 2.24 (stock unpatched)
versions w. avrlibc-1.8.1
avr-gcc-4.9.1 w. avrlibc-1.8.1 , dude-6.1 & gdb-7.8
As it's unpatched binutils, the avr-size don't know about avr's for displaying the "old size info"
Use : avr-size
/Bingo
Attachment(s):
- Log in or register to post comments
TopI'm trying to use your script to build only avr-gcc + avr-libc.
When I first got the error, I thought I needed libiberty.a installed, so I installed binutils-devel, and now have:
/usr/lib64/libiberty.a
I still get the above build error though.
Any ideas what I need to do to get it to work?
Here's the contents of the directory I call the build script from:
In case you need more details, I copied buildavr.log to http://162.248.164.251/files/
I have no special talents. I am only passionately curious. - Albert Einstein
- Log in or register to post comments
TopI also just tried adding binutils to the build (binutils-2.24.tar.bz2), and I still get the same error.
I have no special talents. I am only passionately curious. - Albert Einstein
- Log in or register to post comments
Top./config usually produces a log file that reveals any issues.
- Log in or register to post comments
TopI see
configure: error: gmp.h cannot be found or is unusable.
checking for asprintf... (cached) yes
and
gcc-4.9.1/libcilkrts/include/internal/metacall.h
gcc-4.9.1/libcilkrts/configure.ac
../make-avr-gcc/buildavr-gcc.sh: line 251: cd: gcc-4.9.1/mpfr: No such file or directory
(../make-avr-gcc/buildavr-gcc.sh) patching MPFR source
and
make[1]: *** [configure-mpc] Error 1
make[1]: *** Waiting for unfinished jobs....
1: Have you looked in the "pre-reqs.txt" ???
for potentially needed packages before building
2: why does the gcc-4.9.1/mpfr dir not exist
3: try to run with just 1 core enabled (in package-versions top)
/bingo
- Log in or register to post comments
TopThanks for the help. With 4.9.2 out, I took another look. My screw-up came from reading the comments in getfiles.sh:
There was no such comment for GMP & mpfr, so I thought they weren't required. Reading the gnu docs makes it clear that they are required.
https://gcc.gnu.org/install/prer...
I added back GMP & mpfr to the get-files and build scripts, re-ran the get-files, and am running the build script as I type this.
I have no special talents. I am only passionately curious. - Albert Einstein
- Log in or register to post comments
TopNow I'm getting the following error:
I remember getting a similar error with libiberty when I was building simulavr from source. Simulavr didn't include libiberty source, but gcc-4.9.2 does, so I'm not sure yet what the problem is...
I have no special talents. I am only passionately curious. - Albert Einstein
- Log in or register to post comments
TopI think I found a bug in the build script. In the buildavr.log I found the following:
This is from the following line in the build script:
The problem is the script assumes the basename of the gmp archive (gmp-6.0.0a) is the name of the directory created when the archive is extracted. However the directory name in gmp-6.0.0a.tar.bz2 is gmp-6.0.0 (no 'a' suffix).
I manually copied the gmp source files and re-ran the build script.
I have no special talents. I am only passionately curious. - Albert Einstein
- Log in or register to post comments
TopHi Ralph
That seems like a sensible explanation to the error , and yes the immediate cure would be to manyally copy the gmp source files , or to extract the gmp sources , rename the directory to the "a" name , and repack it.
I'm probably not going to update the buildscript , as it's only a few capable people using it today , and i expect that they can do the same reasoning as you.
/Bingo
- Log in or register to post comments
TopI just built avr-gcc 4.9.2
To circumvent the above problem , i extracted gmp-6.0.0a.tar.bz2 to gmp-6.0.0 , renamed gmp-6.0.0 to gmp-6.0.0a , and repacked it to a tar.bz2 again
/Bingo
- Log in or register to post comments
TopOk, I'm game, where does one start to get AVR 8 support with ATA6614Q device?
I downloaded the Linux stuff from Atmel and found the headers have the device but it looks like they are at version 4.81, if I'm going to battle this I should at least use the latest source.
The WINAVR stuff is not they answer, it appears the supported devices stopped a few years ago.
I tried AS 6.2 but it doesn't respond well to my Windows 7 x64, Windows 10 x64 appears to be functional but that is a beta setup, not production and AS 6.2 does not have git.
I still have to read the stuff from Atmel, that might answer a few questions.
Oh, Bingo, I found your deb for Raspberry PI, 20 hours? I probably don't want to know what your hobbies are....
- Log in or register to post comments
TopFor latest Atmel device support you are (currently) better off sticking to Atmel builds. So while 4.9 may look enticing I'd just take Atmel's 4.8.1 and use that for the time being. Atmel haven't released a toolchain for a while so I rather suspect they are waiting for the 4.9 dust to settle and we may see one shortly anyway.
They are working (see the check in history at the AVR-LibC repo and all the activity from Atmel employees) to push their private changes for added device support back upstream so the generic build will mirror their own local build at which point it won't be necessary to have an Atmel one at all - but that's still work in progress and until then the Atmel builds remain the best option - especially for "none mainstream" devices like the one you want to use.
- Log in or register to post comments
TopI can't find the AVR8 linux x64 tool chain.
Any ideas?
- Log in or register to post comments
TopMessage
The system has encountered an error. Details of which should follow...
ERROR
Target binary, dcp extraction not possible. Cannot find the target.
While attempting to download the Windows AVR 8 3.4.5 tool chain and headers
- Log in or register to post comments
Topinstalled atmel-3.4.4-avr-gcc-4.8.1-2014-06-14-raspbian.armhf.deb on http://radxa.com/Rock the Radxa Rock Pro
it works.
- Log in or register to post comments
Top3.4.4 had the same problem, Linux x64 wasn't available at first. Give it a few days...
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopThis lack of Linux 64 is very annoying. Surely they have a build script that just pumps out all versions at the same time?
- Log in or register to post comments
TopI'm certain it has already been built. Rather it's the website which isn't properly updated.
"Experience is what enables you to recognise a mistake the second time you make it."
"Good judgement comes from experience. Experience comes from bad judgement."
"Wisdom is always wont to arrive late, and to be a little approximate on first possession."
"When you hear hoofbeats, think horses, not unicorns."
"Fast. Cheap. Good. Pick two."
"We see a lot of arses on handlebars around here." - [J Ekdahl]
- Log in or register to post comments
TopI sort of assumed the posting on the website might be part of the auto-build process. Perhaps that last step simply does not work for some reason or maybe it was that the build of the AMD64 version did fail for some reason?
- Log in or register to post comments
TopLast but not least, where do I put the header files? The file structure seems to be vastly different for each build of the AV tool chain, the Eclipse AVR add in can't find them.
Oh, Eclipse on Raspberry, that was a trip.
- Log in or register to post comments
TopI just got hit with a bad compiler message: https://www.mail-archive.com/lin...
I had to upgrade ubuntu to 14.10 to get away from 4.8x gcc
- Log in or register to post comments
TopI think the relative location of the the .h to the .bin is something controlled by the .config usually an avr8 build has this structure:
The avr-gcc etc are in ./bin and the base of the includes are at ../avr/include/ from there - that would be the directory with stdio.h and so on. Then all the AVr specific stuff is in an ./avr/ from there (that is ../avr/include/avr/ from the ./bin/) which is why io.h is referred to as <avr/io.h> in AVR programs.
To be honest I don't know why you don't just get the .tar.gz from atmel.com and unpack it (though I understand the current issue with no linux64 build).
- Log in or register to post comments
TopWhoaaa
Now i really don't want to think about what you do for fun ....
/Bingo
- Log in or register to post comments
TopHad to give up on AVR Linux, the tools are 4.81 and the Eclipse AVR add in does not pick up the arv/io.h file so it will not allow selection of a MCU. I did a git and found where he was parsing the directories but couldn't figure out why it was failing.
Atmel Studio 6.2 (AS) on Windows 10 was working until they installed the latest build, it killed all the USB drivers, didn't like them, they were not branded by Microsoft so they killed them. Several application from the 'Store' died too so Atmel is not alone.
I restored a snap-shot of my Windows 7 workstation system before I installed AS and installed AS again, after it installed the first time I ran it AF told me it had an update, 100mb or so later it was install and now AS on Windows 7 x64 is working.
Here is the deal: gcc 4.80 ~ 4.82 are known to be faulty, the current compiler for AVR8/32 is gcc 4.81 for ARM 4.84 so is it safe to use 4.81 on an AVR8 device?
C:\Program Files (x86)\Atmel\Atmel Toolchain\ARM GCC\Native\4.8.1437\arm-gnu-toolchain\arm-none-eabi\bin>
gcc version 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147] (Atmel build: 371)
I would go back 1970 and command line everything like the good old days of masm using ed but I'm getting lazy in my old age.
Parts are here, circuit boards are 14 days out, building a prototype out of P-dip transceivers parts and UNO's
- Log in or register to post comments
TopYes but note that ALL compilers have bugs. GCC is pretty good with its release schedule so some get fixed quite often but 4.8.1 (and 4.9.2) will have bugs. You just have to hope (as with all compilers) you don't hit one that affects what you happen to be trying to do at the time. Having said that I consider 4.8.1 from Atmel's build to be pretty stable.
(ah "masm"! - those were the days! having used the CP/M assembler before it the thing seemed so "grown up" when I first used it!)
- Log in or register to post comments
TopWell, this building script seems to work good on a RPi : it takes hours, but generates avr libraries. However, there is a small flaw: usually, prefix is used to denote the directory where the results (compiler, gas, libraries, doc) will go : it may be in a small disk; the place where one builds (huge amount of *.o, ...) can be in a separate disk (it is cleaned after building, but it eats disk space), at least in a distinct directory. This does not matter with usual disks, even USB keys -one can install x86 - GNUlinux on a USB stick now-. But RPi "disk" is a SD card : it is expensive (twice as USB sticks), and maybe wear out : seems a bad idea not to separate the building directory trees from the installed one.
- Log in or register to post comments
Top"Dare to be naïve." - Buckminster Fuller
- Log in or register to post comments
TopIknew one can mount external usb disks (rotating ones, with a low price per GB): this was the way I got avr-gcc built,, with salvaged laptop 250GB disk and an adapter. One can even, atleast theoretically, boot from it -only the fat part of the RPi SD is mandatory -; but , if new , this makes price double ... Main issue is that one cannot, with this script, build on the hard disk and move the result into the SD, "prefix" being used to denote the downloaded sources, the temporary directories to untar and compile (I know one can make mount points, but it is not what comes into mind) and the result which should go into the SD in a classical configuration....
- Log in or register to post comments
TopWell, thanks Chapman for the information. I knew that one can use an external -USB- rotating disk (price per GB is very low) -one can even boot from it, only the FAT part of the SD is mandatory- but it is not a standard configuration, doubles the price and makes connectivity complicated . I got avr-gcc compiled on an external -250GB, in 3 parts- USB HD but I cannot -maybe a copy works, if generated compilers /libraries are directory-tree independant...- put it into the SD as directories to download sources , directories to untar and compile and result directories are in the same tree denoted by "prefix" (I did not try to fix it with mount points during buils, as it is not standard).
- Log in or register to post comments
Top@dbrion0606
I'd say something as easy as a symlink would solve your problem
cd /usr/local
$ln -s <usb-disk avr dir> avr
build the stuff
Then rm the symlink, and copy the <usb-disk avr dir> to /usr/local/avr.
No magic there
I'm just building on a 16GB Sandisk Ultra Class10 card , and that's it.
The wear is neglible as most files are written once , and read many times.
/Bingo
- Log in or register to post comments
TopPages