On May 8, 2008, at 16:09:10, Dennis Clark wrote:
I do wonder about the tool chain though - Is that not in the package?
That is as much a hassle as the compiler to build. I've not looked,
does
this include the libs as well as the compiler? They tend to be
related.
I don't think it
On Apr 28, 2008, at 23:57:56, Dave N6NZ wrote:
So, the Bingo scripts worked as-is? I was under the impression that
the standard 10.5 installation was at least missing tools.
Um, well...I honestly don't recall!
I would try them as-is. I think I slightly modified mine...they're
enclosed.
On Apr 24, 2008, at 3:55 AM, Bernard Fouché wrote:
Currently if one does not read all the traffic on this mailing list,
it's difficult to know what patches are required to have a fully
fonctionnal avr-gcc toolchain.
+1
I'd like to upgrade my toolchain on Linux, and if I read the list
On Apr 18, 2008, at 1:29 PM, Weddington, Eric wrote:
FSF stock 4.3.0 is broken for the AVR port. You have to have a slew of
patches to get code generation right. See the patches (gcc, binutils,
others) that come with the WinAVR 20080411 package.
Thanks. Maybe the right question to ask is,
On Apr 20, 2008, at 2:29 PM, Dmitry K. wrote:
More exactly: this is because binutils 2.18 does not support
the MOVW instruction with architecture 3.
The simplest workaround (if you are not happy to install new
binutils) is to add '-mall-opcodes':
Replace into 'config/avr/avr.h' the string:
Hi. Is binutils 2.18 and gcc-4.3.0 okay to build for AVR? In
particular, the ATmega324p?
TIA!
--
Rick
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
On Apr 18, 2008, at 1:29 PM, Weddington, Eric wrote:
FSF stock 4.3.0 is broken for the AVR port. You have to have a slew of
patches to get code generation right. See the patches (gcc, binutils,
others) that come with the WinAVR 20080411 package.
is there a way to get a .zip or gzip version
I'm getting these errors building gcc-4.2.3:
/Users/rmann/LZRepo/avrbuild/trunk/work-4.2.3/gcc-4.2.3/Darwin/./gcc/
xgcc -B/Users/rmann/LZRepo/avrbuild/trunk/work-4.2.3/gcc-4.2.3/
Darwin/./gcc/ -B/usr/local/avr-4.2.3/avr/bin/ -B/usr/local/avr-4.2.3/
avr/lib/ -isystem
On Oct 17, 2007, at 9:46 AM, Dave N6NZ wrote:
OK, a FAQ, I know.
I need to install the avr-gcc tool chain on a MacBook, OS X. Can
someone please give me a pointer to the current best-known-method
for getting the most up-to-date tool chain on a Mac?
I wrote a simple, semi-automatic
On Oct 17, 2007, at 1:01 PM, David Kelly wrote:
You include the same patches and tweaks as WinAVR? Much the way
Joerg's
FreeBSD port and WinAVR stay in close sync? Several months ago I tried
several MacOS X ports of avr-gcc but none supported ATmega 48 and/or
168 (forgot which, or both). I
I have a script that downloads an easily-changed set of versions of
the tools, and then builds universal versions of everything. I had
planned to use that as a first step to making downloadable installers
with packagemaker, but haven't gotten that far yet.
On Jul 8, 2007, at 12:07 PM,
On May 20, 2007, at 3:49 PM, Colin O'Flynn wrote:
See http://www.newae.com/loonboard/lub for more details on the
system. There's
an article there that was in CC that will give you some ideas perhaps?
Oh that sounds cool. I'll check it out.
Thanks!
--
Rick
On May 17, 2007, at 20:45 , kitts wrote:
You need to make sCommandReceived a volatile variable.
Yeah, I realized that, thanks. I'm fully aware of the dangers of the
optimizer, and was operating from the assumption that it was turned
off. I should've known.
Thanks!
--
Rick
As I build binutils, I get the following from configure:
*** This configuration is not supported in the following subdirectories:
target-libiberty
(Any other directories should still work fine.)
Is this an important error? Can I safely ignore it?
I'm building binutils:
cd
This question is by no means urgent...
I'm writing a script to download and build a complete AVR toolchain,
and I'd like to defer installation to the very end (after all the
subcomponents are built). Right now, I'm running into the problem
that building gcc relies on having binutils built
On Apr 23, 2007, at 17:43 , Graham Davies wrote:
Someone will probably offer better advice than what follows, but,
for what it's worth, the Linux-from-scratch (LFS) project offers a
general solution for this type of problem, i.e. bootstrapping a
compiler.
Thanks, I'll take a look.
--
On Dec 15, 2006, at 14:17 , Anatoly Sokolov wrote:
Build script (need registration):
http://www.avrfreaks.net/index.php?
name=PNphpBB2file=viewtopict=42631
Wow, that script worked really well, thanks!
So, I tried running the Makefile supplied with the Atmel USB HID
example, and I get an
Hi. I have 3 main questions:
a) I think I found the patches I need to support the at90usbxxx
parts. Is this right?
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01001.html
b) The email referenced above has a subject prefixed with [AVR][4.2].
As far as I know, the latest release of gcc is
Hi. I came across some posts that suggest there is AT90USBxxx part
support, but my avr-gcc 4.1.0 build doesn't have it. I'm in the
process of downloading 4.1.1, but the posts talked about patches (I
assume they were for some gcc 3.x version).
Can someone elaborate? Where do I find these
Hi. I've successfully built the toolchain several times before. I
don't believe I've ever seen this error. I had gcc 4.1.0, binutils
2.16.1, and other bits from around that time. I just downloaded gcc
4.1.1, and tried to build it without updating anything else. I don't
know if that's part
On Dec 14, 2006, at 18:29 , Eric Weddington wrote:
AFAIK, in AVR GCC 4.x, you must add this to the configure:
--disable-libssp
Thanks, that was it!
--
Rick
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
I have a deadline tomorrow with my school project. I've been building
circuits all week, and just now discovered that, all of a sudden, avr-
gcc seems to be invoking the native as. My Makefile, which hasn't
changed since it worked last week, now produces this:
On Feb 12, 2006, at 10:43 PM, Volkmar Dierkes wrote:
Did you check that the Mega103-Compatibility-Fuse has the correct
setting? The default value is Yes, but the compatibility mode should
be off if your program is compiled for the ATMega128.
Yep, that was it. Thanks!
--
Rick
smime.p7s
I have a simple app that only defines the UART0 receive interrupt
handler for an ATmega128. I can set that it's getting called in gdb
(and because its code is executing), but then something happens and
my code jumps to the top of main. I'm assuming some other interrupt/
reset is occurring,
Generating code for an ATmega128.
I've boiled this down to a pretty simple case, I think. In the
following code, if compiled with -Os, if d is made volatile, then
it never seems to get past execution in the first delay loop. If it's
not volatile, it works correctly. If I compile with -O0,
25 matches
Mail list logo
