Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: [AVR-Chat] C programming on AVR

2008-03-22 by Sander Pool

WinAVR with AVR Studio is pretty easy to use. Can't beat the price 
either. You simply tell Studio what kind of chip you use and it sets the 
compiler flags so that the correct IO definitions get grabbed when you 
include the default io file (sorry, forget the name). I suppose it 
depends on your definition of 'straightforward' but it's hard to imagine 
anyone who's working on a serious piece of software who would claim that 
assembly is easier than C. Just like C# is in many ways easier than C or 
C++. Different strokes different folks I suppose but with cheap 
horsepower I see no reason to advocate assembly over C except for maybe 
a few critical blocks where every instruction counts. For most people 
time saved during development and testing is more than worth the extra 
$1 to get an AVR with a little more memory. But it's a personal decision 
of course. There is a certain elegance in squeezing the last MIP out of 
an AT-Tiny. I do this for fun and I've decided that for me C is low 
level enough.

I don't think that an embedded platform is the right choice for learning 
C. Learn C on a PC (Linux, windows, Mac, whatever) and then apply those 
skills to develop embedded apps. As far as books go it seems that the 
Smileymicro book is a good way to start. You can download the first 
chapter from the site to get a taste. It shows how to program a 
butterfly with WinAVR+studio and minimal extra hardware.

    Sander

Mike Harrison wrote:
>
> On Sat, 22 Mar 2008 11:03:14 -0700, you wrote:
>
> > I recently moved from assembly programming to C for the AVR for
> > a project, teaching myself mostly. It has been torturous, for me
> > especially because I'm originally a hardware guy. Programming
> > in assembly over the last 5 years has been straightforward, and
> > an easy understanding of the pins and resources of each micro.
> > However, the incredibly klugey nature and structure of the C
> > compilers and makefile systems to me was and still is horrendous.
>
> I'd have to agree, but this is entirely down to the compiler producers 
> - it doesn't need to be that
> hard.
> In most cases, any particular chip will have a set of default settings 
> that will be useable for the
> majority of people, at least until they get the hang of things, and a 
> good toolchain will make it
> easy to start off a simple project with minimal fiddling.
>
> An example of how easy this can be is Hi-Tech's PIC C compiler - just 
> do #include <pic.h> and you
> can compile & run a project in MPLAB pretty much straight away with no 
> fiddling about.
>
> IAR's Embedded workbench C for the AVR isn't too bad, as the default 
> linker options are sensible and
> easily changed, although th ewhole porject/workspace thing, and 
> default directory structure can be a
> bit tedious where all you want is asimple single source and object file
> Their ARM toolset is another story - I still need to refer to my 
> 'to-do' list every time I start a
> new project... I doubt anyone with no example projects to look at 
> could ever get this working with
> the JTAG debugger from the docs alone..
>
> __

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.