compiling sosse

10 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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;

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 " is deprecated, use  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 " is deprecated, use  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 " is deprecated, use  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?

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

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).

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

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.

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

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.

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

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.

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

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. :oops:

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.

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

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.

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

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.

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

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

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

Thanx for the info , and efford

/Bingo