[avr-gcc-list] RE: avr-gcc-list Digest, Vol 7, Issue 23

[Dafni & Robert Berger]

Hi Sam,

I sent the fax yesterday.

Did you get it?

Regards,

Robert

----------------------------------------------------------------------------
Dafni & Robert Berger
Pharmacist & Embedded Systems SW Engineer
Stratigou Rogakou 24
GR-15125 - Polydrosso - Maroussi
Athens - Greece
Tel.: (+30 210) 6847881
Fax.:(+30 210) 6847881
email: address@hidden
URL: users.hol.gr/~dafniz
"Software development is like making a baby... You can't make a baby in one
month by impregnating nine women."

"Giving up on assembly language was the apple in our Garden of Eden:
Languages whose use squanders machine cycles are sinful."
(Epigrams in Programming,  ACM SIGPLAN Sept. 1982)


-----Original Message-----
From: address@hidden [mailto:address@hidden
Behalf Of address@hidden
Sent: Sunday, August 24, 2003 3:00 AM
To: address@hidden
Subject: avr-gcc-list Digest, Vol 7, Issue 23

Send avr-gcc-list mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.avr1.org/mailman/listinfo/avr-gcc-list
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of avr-gcc-list digest..."


Today's Topics:

   1. RE: Next version of winavr!!! (Marlin Unruh)
   2. RE: Next version of winavr!!! (Ron Kreymborg)
   3. RE: Next version of winavr!!! (Derick Schoonbee)
   4. Converting from IAR to avr-gcc (Gregory Berardi)
   5. RE: Next version of winavr!!! (E. Weddington)
   6. Re: Converting from IAR to avr-gcc
   7. Re: Converting from IAR to avr-gcc (Gregory Berardi)
   8. Re: Re[2]: [avr-gcc-list] Re: GCC-AVR Update (20082003)
       (Larry Barello)


----------------------------------------------------------------------

Date: Fri, 22 Aug 2003 21:55:43 -0600
From: "Marlin Unruh" <address@hidden>
To: <address@hidden>
Subject: RE: [avr-gcc-list] Next version of winavr!!!
Message-ID: <address@hidden>
In-Reply-To: <address@hidden>
Content-Type: text/plain;
        charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 1


On the subject of IDEs. I use Vim from http://www.vim.org/ as my 'IDE'.
Awesome text editor, VERY powerful. You can map key strokes to compile your
code, then download the hex file to the stk500. Vim can do so much,
basically the limit is your knowledge of how to use it. You have to be very
dedicated to learn it but the rewards are great. Only learn it once and use
it on any micros.
Vim was written by a c programmer, for c and may other programming
languages. It may not be easy to learn, but it's worth it. Use it under
Linux or Windows.

Marlin





------------------------------

Date: Sat, 23 Aug 2003 13:58:30 +1000
From: "Ron Kreymborg" <address@hidden>
To: <address@hidden>
Subject: RE: [avr-gcc-list] Next version of winavr!!!
Message-ID: <address@hidden>
In-Reply-To: <address@hidden>
Content-Type: text/plain;
        charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 2

I appreciate you can't bundle this solution with WinAVR, but for those who
can afford a few dollars, IMO a better editor is Ultraedit
(www.ultraedit.com). If you include uemakeXp (www.uemake.com) (which already
has a WinAVR interface), you have an exceptional development IDE.

Ron

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of E. Weddington
> Sent: Saturday, 23 August 2003 1:40 AM
> To: Dave Hansen; address@hidden; address@hidden
> Subject: Re: [avr-gcc-list] Next version of winavr!!!
>
>
> > >From: Andreas Schwarz <address@hidden>
> > [...]
> > >
> > >"Steven Chang-Lin Yu" <address@hidden> wrote:
> > [...]
> > > > Just some suggestion, for the next version:
> > >
> > > > 3.      A GUI or text based makefile generator (I am
> writing one for
> > > > myself, if it is finish I will send to the mailing
> list)
> > >
> > >3a. Throw away Volker Oth's makefile, replace it by a
> SIMPLE example
> > >and/or a makefile generator.
> >
> > Ummm.
> >
> > I'm fairly new to the avr-gcc world, though I've been
> programming embedded
> > systems for over 15 years.  I first downloaded WinAVR a
> few months ago, and
> > was able to get everything running (i.e., an application
> I was porting to
> > WinAVR) within a day or so.
> >
> > If "Volker Oth's makefile" is the Makefile supplied with
> WinAVR, it would be
> > a great disservice to the user community to replace it
> with a "SIMPLE"
> > example.  I, for one, found it very clear and easy to
> understand and use.
> >
>
> Wait, wait, wait.
>
> First off, for some reason I can't read Steven's email; it
> comes across as garbage so I don't know the whole thread.
>
> The sample makefile that is in WinAVR has NOTHING to do
> with Volker Oth's makefile.
>
> The latest makefile comes with the AVR COFF package, and it
> has a lot more comments in it, which should help.
>
> And, I always say in the readme and elsewhere that this
> makefile is a SAMPLE ONLY! There is nothing "official"
> about it. If the makefile does not meet your needs, then
> feel free to write your own. This is why I also say to
> please read the make user manual, so a user can edit the
> sample makefile to their heart's content.
>
> As to a makefile generator, my hopes are to include a
> Project Management feature into Programmers Notepad. Now, I
> realize that not everybody wants Programmers Notepad.
> That's fine; that's why there's choice in the world.
>
> In talking with Simon Steele, the author of Programmers
> Notepad (PN), he will implement a GUI way of adding files
> to a "project", and provide a table that will have various
> compiler options and linker options that can be selected (a
> la a "property table" that you would see in Delphi or VB).
> Menu commands would be provided to allow you to Make or
> Build your project. This would launch a helper program that
> would take the set of files in the project, and the
> compiler and linker options, generate a makefile, and
> automatically launch make. These compiler options and
> linker options will be stored in an XML file.
>
> Anybody interested in helping?
>
> Eric
>
>
>
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list


------------------------------

Date: Sat, 23 Aug 2003 11:20:23 +0200
From: "Derick Schoonbee" <address@hidden>
To: address@hidden, address@hidden, address@hidden,
        address@hidden
Subject: RE: [avr-gcc-list] Next version of winavr!!!
Message-ID: <address@hidden>
Content-Type: text/plain; format=flowed
MIME-Version: 1.0
Precedence: list
Message: 3

vim (& make & midnight commander) is good ... even on W2K&XP  ... mind you I
do not do any 'production' stuff .. surely nice to have a common ground
accross OSes & target processors ...
D.

From: "Brian Cuthie" <address@hidden>
To: "'Dave Hansen'" <address@hidden>, <address@hidden>,
<address@hidden>
Subject: RE: [avr-gcc-list] Next version of winavr!!!
Date: Fri, 22 Aug 2003 17:31:25 -0400


Well, clearly you haven't used a good IDE, or you didn't know how to use
it. Lots of production code is developed using IDEs. Nearly every
application for every desktop platform (we're talking the 99% of the
market held by MS/Apple, not the Linux/Unix world) is developed in an
IDE. Most commercial desktop applications are orders of magnitude more
complex than any of the embedded stuff that gets done.

An IDE does offer an additional level of abstraction, and many people
are understandably reluctant to begin using a new one (me included,
sometimes). But more often than not, learning the new tool pays off in
spades.

-brian

-----Original Message-----
From: Dave Hansen [mailto:address@hidden
Sent: Friday, August 22, 2003 4:54 PM
To: address@hidden; address@hidden; address@hidden
Subject: RE: [avr-gcc-list] Next version of winavr!!!

...

I could say that "good IDE" is an oxymoron, but that'd be too harsh.
IME,
most IDEs make it easy to do simple things.  They're especially useful
to
get example code up and running quickly.  But they fall apart when
stretched
a little.  I find them (for the most part) unsuitable for a production
environment.  Furthermore, everyone's IDE is different from everyone
else's.
   If you have several tool sets from several vendors targeting several
micros, you have to master each of them.

...

Regards,
    -=Dave

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


------------------------------

Date: 23 Aug 2003 08:56:26 -0500
From: Gregory Berardi <address@hidden>
To: address@hidden
Subject: [avr-gcc-list] Converting from IAR to avr-gcc
Message-ID: <address@hidden>
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 4

I am converting a very large program for the atmega128 from IAR to
avr-gcc and I'm having some problems.  Once I get this to compile and
work I want to convert it to atmega103 since the 128 is obsolete.  We
are currently building boards with the 128 until we run out, sometime in
Februrary or March.  My current problem is a function that takes a float
and returns a float.  The header prototype is;

float AdjFZSP(float SP);

I get and error of;

parse error before '(' token

Can't I have a return type float?

Could someone show me a way to get around this?

Is there some information on converting from IAR to avr-gcc?

-greg




------------------------------

Date: Sat, 23 Aug 2003 14:06:31 GMT
From: "E. Weddington" <address@hidden>
To: "Steven Chang-Lin Yu" <address@hidden>,
        address@hidden
Subject: RE: [avr-gcc-list] Next version of winavr!!!
Message-ID: <address@hidden>
Precedence: list
Message: 5

> > I not sure whether this is possible or not, but having
> all the avrlibc
> > file together in a folder, and alow user to just
download
> the package of
> > the linux, and uncompress in the folder???
>
> I'm not sure what you mean here.
> -------------------------------------------
>
> Well, what I mean is it possible to actually use the same
package of
> avrlibc files under linux with avr, hence the user can
upgrade the
> avrlibc files, by just download the linux build, and
unzip in to the
> folder of winavr???
>

avr-libc comes as source code and is compiled for whatever
platform you're using: Linux, FreeBSD, Windows, etc.

If you're talking about doing a dynamic upgrade (download
source, build library on fly on Windows platform), then
that idea has been recently brought to my attention (from
Joerg Wunsch). It won't be in the next release, but I'm
definitely considering something like in the future.

Eric



------------------------------

Date: Sat, 23 Aug 2003 14:14:22 GMT
From: address@hidden
To: Gregory Berardi <address@hidden>, address@hidden
Subject: Re: [avr-gcc-list] Converting from IAR to avr-gcc
Message-ID: <address@hidden>
Precedence: list
Message: 6

> I am converting a very large program for the atmega128
from IAR to
> avr-gcc and I'm having some problems.  Once I get this to
compile and
> work I want to convert it to atmega103 since the 128 is
obsolete.  We
> are currently building boards with the 128 until we run
out, sometime in
> Februrary or March.

You mean "convert to mega128 from the mega103". :)

>My current problem is a function that takes a float
> and returns a float.  The header prototype is;
>
> float AdjFZSP(float SP);
>
> I get and error of;
>
> parse error before '(' token
>
> Can't I have a return type float?
>
> Could someone show me a way to get around this?


I don't know for sure without seeing the code in context
and the actual compiler output, but some points:
1. Do you have a prototype written for the function?
2. Do you have #include <math.h>?
3. For later, when you link, be sure to have the -lm switch
in the linker flags to link in the math library. If you are
using the WinAVR sample makefile, it automatically includes
this switch.



> Is there some information on converting from IAR to avr-
gcc?
>

Not that I'm aware of. Best to read the avr-libc
documentation thoroughly. However, converting from IAR to
GCC is not that difficult (I used to use IAR). The biggest
differences are:
1. Interrupt Service Routines. (But everybody is different
as there is no standard.)
2. Putting strings in Flash and reading from Flash.
3. Minor header file differences.


So, what are your reasons from moving from IAR to GCC?

Eric



------------------------------

Date: 23 Aug 2003 15:02:29 -0500
From: Gregory Berardi <address@hidden>
To: address@hidden
Subject: Re: [avr-gcc-list] Converting from IAR to avr-gcc
Message-ID: <address@hidden>
In-Reply-To: <address@hidden>
References: <address@hidden>
Content-Type: text/plain
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 7

Duh!

I meant the atmega103 is what we are using and we will be going to the
128.

Brain fart!

-greg


On Sat, 2003-08-23 at 08:56, Gregory Berardi wrote:
> I am converting a very large program for the atmega128 from IAR to
> avr-gcc and I'm having some problems.  Once I get this to compile and
> work I want to convert it to atmega103 since the 128 is obsolete.  We
> are currently building boards with the 128 until we run out, sometime in
> Februrary or March.  My current problem is a function that takes a float
> and returns a float.  The header prototype is;
>
> float AdjFZSP(float SP);
>
> I get and error of;
>
> parse error before '(' token
>
> Can't I have a return type float?
>
> Could someone show me a way to get around this?
>
> Is there some information on converting from IAR to avr-gcc?
>
> -greg
>
>
>
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list


------------------------------

Date: Sat, 23 Aug 2003 14:44:27 -0700
From: "Larry Barello" <address@hidden>
To: "James Dabbs" <address@hidden>
Cc: AVR GCC List <address@hidden>
Subject: Re: Re[2]: [avr-gcc-list] Re: GCC-AVR Update (20082003)
Message-ID: <address@hidden>
References: <address@hidden>
Content-Type: text/plain;
        charset="Windows-1252"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: list
Message: 8

The last time I compared IAR & GCC was about 2 years ago and IAR had
marginally smaller
code size, but much fatter and slower libraries (for my projects).  The end
result was a
slight edge to GCC.  This is only for small model code, which is all that
GCC supports.

>>From what I heard, IAR now implements some sort of "code compressor" where
they look for
strings of op-codes and replace with function calls, globally.  This can
really crunch
the code size, if you like that sort of thing.

Anyway, at the time I did my comparison (GCC, IAR, ICC and CV) the note I
wrote
apparently found its way into an Atmel AVR seminar where the local FAE were
using it to
show low cost quality tools were available.

Perhaps and updated comparison with an objective analysis of the pro/con
would go a long
way towards either focusing the GCC efforts, or convincing Atmel to give us
better
support.

Cheers!

----- Original Message -----
From: "James Dabbs" <address@hidden>


> > An  Atmel  engineer  here in Germany I spoke to on the phone yesterday
> confirmed  that  gcc  indeed
> > is "a really nice compiler" for AVR. But frankly  I  think  it  would
take
> one order of magnitude less
> > bugs and maybe  a 1/3 or 1/2 cut in code size on gcc's part (impossible
I
> know) to  really start sucking
> > away customers from IAR and stir things up at Atmel.  With  regard  to
> bugs I'm not so sure, but with
> > code size I'd have to quote grand ma: "Not gonna happen". ;)
>
> This was not my experience.  I evaluated IAR (for a project that now seems
> to be defunct) and it was a really nice environment and it had a good
> debugger.  But the compiler output in my case from IAR was *bigger* than
> GCC, and in fact wouldn't fit into the part.  This was with the IAR
> optimizer on full blast, favoring small code, compiling C++ source.  Also
a
> section of code (the XTEA encryption algorithm) caused IAR to emit bad
code
> at maximum optimization, while GCC dealt with it.
>
> I also think that GCC's inline assembler, in extended mode, can't be beat.
> Especially with a little part like the AVR and an understanding of the
ABI,
> you can really pick out and optimize problem spots.
>


------------------------------

_______________________________________________
avr-gcc-list mailing list
address@hidden
http://www.avr1.org/mailman/listinfo/avr-gcc-list


End of avr-gcc-list Digest, Vol 7, Issue 23
*******************************************