AVR-Chat

----- Original Message -----
From: "markevans_1" <markevans@iinet.net.au>
To: <AVR-Chat@yahoogroups.com>
Sent: Tuesday, March 16, 2004 07:31
Subject: [AVR-Chat] Re: AVR Compiler: which is the best


> Thanks for all the replys.
>
> I have written a handful of programs for AVR and PIC in
assembly. I
> find once you start to include LCDs (especially graphical
ones) to
> the project the code gets quite large quite quickly. So my
main
> reason in looking for a higher level compiler is for
managability.
> As for language preference,
>
> I have significant experience in C/C++, java and a bit of
BASIC but
> am not adverse to learning a new latest-and-greatest
language. The
> main requirement is that there is a large body of freely
available
> existing code for the particular compiler-language so I
can drop in
> an I2C class, LCD routines etc and not waste my time
writing and
> debugging such code. Also I would like to have the option
to port my
> code to other micros if the need arises.

Go with GNU.  Yeah, its all written for the x86 and similar
desktop architectures, but it is a start.

There is also a project out of Switzerland called "Oberon"
and/or "BlueBottle".
http://bluebottle.ethz.ch/
It is an alternative operating system, similar in spirit to
Linux, that is freely available.  Although written for the
x86 platform, it is a graphical OS complete with its own
compiler which is open sourced (I think).  "Oberon" is the
language, it was created by Niklaus Wirth of Pascal fame.
Perhaps someone might want to create an AVR port of Oberon
and use that as a starting point for making BlueBottle into
a nifty  AVR development environment.  Oberon is a simpler
language than even C and shows a great deal of promise.
It is still very much a research project right now.

Just a thought as to where to go looking.

> Looking back on a few hundred lines of assembly you coded
a couple
> of years ago and untangling it is not much fun: even if it
is well
> documented. Furthermore, I find the vast bulk of code I
have written
> is related to GUI stuff. Output a string or draw a line to
an LCD,
> listen for keypresses etc: which requires a lot of code
that can be
> reused from project to project and has little need for
highly speed
> optermised code. Whenever speed becomes an issue though, I
would
> greatly prefer to code in inline assembly, if for nothing
more you
> can easily count clock cycles.
>
> I am still a student doing a Computer Science and
Engineering
> Degree. After a 3 year degree of CS you know compilers
generate
> assembly but are never taught or shown what it is or what
it looks
> like: for that matter you are told not to code in it. As
for
> engineering, they do introduce you to it, but there is
still a heavy
> focus on using C for low level stuff where ever possible.

They don't have compiler theory courses at your University?
I thought that was part of CSE.

> I understand the reasoning behind it but I still think
programmers
> should have an understanding of what a compiler does and
how it does
> it to better understand the implementations of the code
they write
> in high level languages.

One way to learn about this is to obtain a compiler that
excretes assembly language instead of object modules.  That
way, you can write test programmes and look at the output
that is generated.  When I was doing a 68HC11 project, my C
compiler was one that generated assembly files.  So I could
look at the generated assembly output and tune my source
code for the best (shortest, fastest) output.  Of course, I
am one of those people who has absolutely no problem with
taking the generated assembly code and hand tuning it even
further.

I would recommend the GCC compiler.  It's uglier than
homemade sin but it gets the job done (well) and you can
poke around under the hood.

> I will download a couple of demos of the mentioned AVR
Compilers and
> see which I prefer.
>
> Mark.
>


Erikc  - firewevr@airmail.net
///
"An Fhirinne in aghaidh an tSaoil."
"The Truth against the World."
        -- Bardic Motto