Search |
 |
|
 |
| Author |
Message |
|
|
 Posted: Dec 14, 2004 - 10:30 AM |
|
Joined: Oct 21, 2004
Posts: 1
|
|
I have installed win-avr 20040720 under windows, and trying to compile sosse (2003-04-13 release, or any older) and I've got strange errors for all versions of sosse;
Code:
C:\...osse-20030413\sosse-20030413\src>make
avr-gcc -mmcu=atmega161 -Wall -I. -Os -mcall-prologues -c -o hal.o hal.c
In file included from ./types.h:33,
from ./sw.h:31,
from ./crypt.h:31,
from hal.c:27:
C:/WinAVR/bin/../lib/gcc/avr/3.4.1/../../../../avr/include/pgmspace.h:3:2: warni
ng: #warning "<pgmspace.h> is deprecated, use <avr/pgmspace.h> instead"
In file included from hal.c:29:
C:/WinAVR/bin/../lib/gcc/avr/3.4.1/../../../../avr/include/eeprom.h:3:2: warning
: #warning "<eeprom.h> is deprecated, use <avr/eeprom.h> instead"
In file included from hal.c:30:
C:/WinAVR/bin/../lib/gcc/avr/3.4.1/../../../../avr/include/io.h:3:2: warning: #w
arning "<io.h> is deprecated, use <avr/io.h> instead"
hal.c: In function `hal_init':
hal.c:47: error: invalid lvalue in unary `&'
hal.c:48: error: invalid lvalue in unary `&'
hal.c:49: error: invalid lvalue in unary `&'
hal.c:50: error: invalid lvalue in unary `&'
hal.c:51: error: invalid lvalue in unary `&'
hal.c:52: error: invalid lvalue in unary `&'
hal.c:53: error: invalid lvalue in unary `&'
hal.c:54: error: invalid lvalue in unary `&'
hal.c:55: error: invalid lvalue in unary `&'
make: *** [hal.o] Error 1
C:\...osse-20030413\sosse-20030413\src>
I suffered over different versions of sosse, trying different configuration,- nothing helps - I've got these errors. Can anyone help me? |
|
|
| |
|
|
|
|
|
|
Posted: Dec 14, 2004 - 02:44 PM |
|
Joined: Mar 27, 2002
Posts: 2065
Location: Selkirk, NY, USA
|
|
Baed on the messages, I'd say this was written for avr-gcc. WinAVR is
mostly the same, but the handling of I/O registers changed such that
some things (e.g. "outp(PORTB-1,0)"), acceptable to avr-gcc, are illegal
in WinAVR.
Your best bet is to go through each of the errors individually and fix them
up. My experience is that, once you've done this, you'll probably be OK
(no "hidden" incompatibilities). |
|
|
| |
|
|
|
|
|
|
Posted: Dec 14, 2004 - 04:00 PM |
|
Joined: Dec 20, 2002
Posts: 7276
Location: Dresden, Germany
|
|
Hmm, WinAVR *is* avr-gcc (plus a bunch of related tools), only in an
updated version, compared to what has once been floating around here
at avrfreaks.net as `avr-gcc'.
But I agree, most likely the code has been written for an ancient
version of the compiler/library. |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
|
Posted: Dec 14, 2004 - 05:29 PM |
|
Joined: Mar 01, 2001
Posts: 4953
Location: Rocky Mountains
|
|
|
mckenney wrote:
Baed on the messages, I'd say this was written for avr-gcc. WinAVR is
mostly the same, but the handling of I/O registers changed such that
some things (e.g. "outp(PORTB-1,0)"), acceptable to avr-gcc, are illegal
in WinAVR.
Ok, a basics refresher  :
1. GNU Binutils contains: The GNU assembler, as. Also called gas. The GNU linker, ld. And a bunch of other utilities that works on binary files.
2. The GNU Compiler Collection (GCC). Compilers for different languages such as C, C++, Fortran, Java, Objective-C, Ada. GCC can be built for different targets (processors and OS platforms). When it is built for the AVR target, the compiler is commonly called: AVR GCC, or avr-gcc.
3. avr-libc. The Standard C library for the AVR that works with the GNU toolset above.
4. WinAVR is a suite of prebuilt software development tools for the AVR. WinAVR includes: GNU Binutils, GCC, avr-libc, and a bunch of other tools. WinAVR includes only the C compiler and the C++ compiler of GCC.
So WinAVR contains avr-gcc, the same avr-gcc compiler found on Linux, FreeBSD, and Mac OS X. WinAVR contains the avr-gcc cross compiler built to run on a Windows host.
All of this info should be found in the WinAVR README.
The outp() macro comes from avr-libc. avr-libc is also used on all the various hosts above. The outp() macro has been deprecated for a while and will go away soon. When somebody uses outp they are probably using an older version of avr-libc and probably an older version of AVR GCC. |
|
|
| |
|
|
|
|
|
|
Posted: Dec 14, 2004 - 06:44 PM |
|
Joined: Mar 27, 2002
Posts: 2065
Location: Selkirk, NY, USA
|
|
|
Quote:
Ok, a basics refresher
"Yes, dear".
WinAVR is a package containing a program named "avr-gcc", along with
a bunch of things (headers, libraries) closely associated with it. avr-gcc
was the name of a package available a few years ago which (curiously)
contained a program named "avr-gcc" along with a bunch of things [blah
blah blah]. Give me a name for the Package Formerly Known As avr-gcc,
and I'll use it.
The introduction of WinAVR included some changes (beyond packaging)
over the PFKAa-g.
The PFKAa-g allowed certain constructs (not just outp) which WinAVR
does not. Some programs (I suspect this is one of them) used these
constructs. If someone wants to build these programs with WinAVR (which
I strongly recommend), these constructs will have to be repaired/updated/
(pick-a-word).
My other answer was shorter. |
|
|
| |
|
|
|
|
|
|
Posted: Dec 14, 2004 - 07:32 PM |
|
Joined: Mar 01, 2001
Posts: 4953
Location: Rocky Mountains
|
|
|
mckenney wrote:
Quote:
Ok, a basics refresher
"Yes, dear".
WinAVR is a package containing a program named "avr-gcc", along with
a bunch of things (headers, libraries) closely associated with it. avr-gcc
was the name of a package available a few years ago which (curiously)
contained a program named "avr-gcc" along with a bunch of things [blah
blah blah]. Give me a name for the Package Formerly Known As avr-gcc,
and I'll use it.
Oh, now I understand your usage. I've generally called it the "AVR Freaks distribution" of AVR GCC, as it was put together by AVR Freaks back then. There's no generally good name for it (that's why I started the WinAVR moniker). Sorry for being pedantic. 
mckenney wrote:
The introduction of WinAVR included some changes (beyond packaging)
over the PFKAa-g.
The PFKAa-g allowed certain constructs (not just outp) which WinAVR
does not. Some programs (I suspect this is one of them) used these
constructs. If someone wants to build these programs with WinAVR (which
I strongly recommend), these constructs will have to be repaired/updated/
(pick-a-word).
Well technically it depends on which version of WinAVR. WinAVR did allow those contructs in earlier releases, because the earlier releases included earlier versions of avr-libc which, of course, allowed it. It's avr-libc that has changed over time. |
|
|
| |
|
|
|
|
|
|
Posted: Dec 14, 2004 - 07:43 PM |
|
Joined: Dec 20, 2002
Posts: 7276
Location: Dresden, Germany
|
|
My guess is the program is one of those nice examples that tried to
shine with intimate knowledge of the AVR hardware, by inferring a
regular port's DDR register straight from the main port register
number (or vice versa). This used to work back when avr-libc didn't
support direct assignment forms for the IO registers, where the IO
port macros were actually simple numbers. Nowadays, the port macros
are a little more complicated, so simple arithmetics on them is no
longer directly possible.
Sure, it could be made work again (using some obscure typecasting),
but it's arguable whether this kind of implied knowledge (as opposed
to handle all the PORTx/PINx/DDRx based on their explicit macros from
the header file) is really good style. It might sound like clever
programming at first, as it could save a few bytes of code or RAM, but
could easily become a boomerang some day. Not only that it's tricky
and hard to maintain (as we are currently being demonstrated here),
but who's going to guarantee that the old adjacent arrangement for
each respective PORTx/PINx/DDRx register is never going to change?
We've already seen enough surprises from Atmel, like the CAN128 which
is basically an ATmega128 but has a lot of the original registers
moved into the upper register area (where they cannot be accessed
using IN/OUT anymore).
The only thing that will be ensured with this kind of trickery as that
with each new release (of either the hardware or the software), you
can always fear a new surprise. ;-) |
_________________
Jörg Wunsch
Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
|
| |
|
|
|
|
|
|
Posted: Dec 14, 2004 - 10:52 PM |
|
Joined: Mar 27, 2002
Posts: 2065
Location: Selkirk, NY, USA
|
|
I vaguely recall having trouble with a macro I had written for the (ahem)
AFD to manipulate 16-bit I/O registers, which used address arithmetic to
reference the two halves. I don't recall why I thought inw/outw were
unsuitable when I wrote it, but I would say there existed quasi-plausible
reasons to do this sort of thing in the AFD.
But no matter -- the value of moving to WinAVR was so large that I just
patched things up (OK, maybe there were a few muttered expletives) and
never looked back. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 26, 2012 - 06:19 PM |
|
Joined: May 08, 2011
Posts: 1
|
|
I'm not sure if this helps anyone but I've updated the last known version of SOSSE (2003 04 13) - Simple Operating System for Smartcard Education and created a Github repo for it here:
https://github.com/theqlabs/SOSSE
At this time it compiles great under Ubuntu 10.10 using avr-gcc-4.3 (latest) - there's also a Wiki and plans to continue to developing. My first priority will be to get an example Application checked in to show people how to use this OS.
Hope this helps,
--theqlabs |
|
|
| |
|
|
|
|
|
|
Posted: Feb 26, 2012 - 07:07 PM |
|
Joined: Apr 25, 2004
Posts: 3809
Location: Denmark
|
|
Thanx for the info , and efford
/Bingo |
|
|
| |
|
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
