AVR-Chat

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 have been learning mostly with WinAVR and the Butterfly, a system
 touted as having many good examples to expand from.  However,
 some versions of the Butterfly were not written in WinAVR, and the
 code is NOT portable, and is generally full of bugs or poor
documentation.
 (Since it is free, I'm not supposed to mind.)   Therefore, one
cannot simply
 pick up modules from anywhere and hack them into one's code, as I
 had hoped.
 The books and online tutorials have not helped much.  I was able to
 rope a friend, who is a C application programmer, into a fun AVR
 project, and we tackled this nasty mess from our two different
 directions, working together.
 Ken
 On Sat 03/22/08 10:29 AM , "Leon" leon355@btinternet.com sent:

	----- Original Message ----- 
 From: "bronzefury" 
 To: 
 Sent: Friday, March 21, 2008 3:45 PM
 Subject: [AVR-Chat] C programming on AVR
 > Hi,
 >
 > I haven't seen a good website that teaches how to write C for the
AVR
 > and would like to get some opinion from the group about which book
 > you'd recommend.  Sometimes, ratings on Amazon are a bit skewed. 
I'd
 > prefer to stick with AVR Studio and WinAVR. I already have the
 > Kernighan & Ritchie book on C.
 You don't need anything else, just look at a few embedded C examples
and it 
 should be obvious what you need to do.
 Leon
 --
 Leon Heller
 Amateur radio call-sign G1HSM
 Yaesu FT-817ND and FT-857D transceivers
 Suzuki SV1000S motorcycle
 leon355@btinternet.com [3]
 http://www.geocities.com/leon_heller [4]
                       


Links:
------
[1] mailto:bronzefury@yahoo.com
[2] mailto:AVR-Chat@yahoogroups.com
[3] mailto:leon355@btinternet.com
[4] http://www.geocities.com/leon_heller
[5]
http://groups.yahoo.com/group/AVR-Chat/message/14577;_ylc=X3oDMTM2bTg5NnU4BF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BG1zZ0lkAzE0NTc4BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTIwNjIwNjk4NwR0cGNJZAMxNDU3Nw--
[6]
http://groups.yahoo.com/group/AVR-Chat/post;_ylc=X3oDMTJxNGJhOHRsBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BG1zZ0lkAzE0NTc4BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTIwNjIwNjk4Nw--?act=reply&messageNum=14578
[7]
http://groups.yahoo.com/group/AVR-Chat/post;_ylc=X3oDMTJldnE1MmE5BF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTIwNjIwNjk4Nw--
[8]
http://groups.yahoo.com/group/AVR-Chat/messages;_ylc=X3oDMTJldDJrbjRlBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA21zZ3MEc3RpbWUDMTIwNjIwNjk4Nw--
[9]
http://groups.yahoo.com/group/AVR-Chat/files;_ylc=X3oDMTJmbzBxcGVrBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA2ZpbGVzBHN0aW1lAzEyMDYyMDY5ODc-
[10]
http://groups.yahoo.com/group/AVR-Chat/photos;_ylc=X3oDMTJlYTBoNDk4BF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA3Bob3QEc3RpbWUDMTIwNjIwNjk4Nw--
[11]
http://groups.yahoo.com/group/AVR-Chat/links;_ylc=X3oDMTJmaWVvaWgxBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA2xpbmtzBHN0aW1lAzEyMDYyMDY5ODc-
[12]
http://groups.yahoo.com/group/AVR-Chat/database;_ylc=X3oDMTJjNzMzdm5iBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA2RiBHN0aW1lAzEyMDYyMDY5ODc-
[13]
http://groups.yahoo.com/group/AVR-Chat/polls;_ylc=X3oDMTJmMjUyaHNiBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA3BvbGxzBHN0aW1lAzEyMDYyMDY5ODc-
[14]
http://groups.yahoo.com/group/AVR-Chat/members;_ylc=X3oDMTJla3NocWwwBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA21icnMEc3RpbWUDMTIwNjIwNjk4Nw--
[15]
http://groups.yahoo.com/group/AVR-Chat/calendar;_ylc=X3oDMTJkaXJvcGhzBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA2NhbARzdGltZQMxMjA2MjA2OTg3
[16]
http://groups.yahoo.com/;_ylc=X3oDMTJkOWw4NzI0BF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxMjA2MjA2OTg3
[17]
http://groups.yahoo.com/group/AVR-Chat/join;_ylc=X3oDMTJmM2s2dnIzBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA3N0bmdzBHN0aW1lAzEyMDYyMDY5ODc-
[18] mailto:AVR-Chat-digest@yahoogroups.com?subject=Email Delivery:
Digest
[19]
mailto:AVR-Chat-traditional@yahoogroups.com?subject=Change%20Delivery%20Format:%20Traditional
[20]
http://groups.yahoo.com/group/AVR-Chat;_ylc=X3oDMTJkZXQ5NnB2BF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwNmdHIEc2xrA2hwZgRzdGltZQMxMjA2MjA2OTg3
[21] http://docs.yahoo.com/info/terms/
[22] mailto:AVR-Chat-unsubscribe@yahoogroups.com?subject=
[23]
http://groups.yahoo.com/group/AVR-Chat/members;_ylc=X3oDMTJmazFpamYxBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzEyMDYyMDY5ODc-
[24]
http://groups.yahoo.com/group/AVR-Chat;_ylc=X3oDMTJlczZpZzJlBF9TAzk3MzU5NzE0BGdycElkAzQzMTM5NzQEZ3Jwc3BJZAMxNzA2NTU0MjA1BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTIwNjIwNjk4Nw--
[25]
http://us.ard.yahoo.com/SIG=13omsgbte/M=493064.12016309.12445701.8674578/D=groups/S=1706554205:NC/Y=YAHOO/EXP=1206214188/L=/B=4RJEDELaX.o-/J=1206206988258144/A=3848614/R=0/SIG=12t4qk00m/*<a
href=
[26]
http://us.ard.yahoo.com/SIG=13oo7fg6e/M=493064.12016257.12445664.8674578/D=groups/S=1706554205:NC/Y=YAHOO/EXP=1206214188/L=/B=4hJEDELaX.o-/J=1206206988258144/A=4507179/R=0/SIG=12de4rskk/*<a
href=
[27]
http://us.ard.yahoo.com/SIG=13oao21hg/M=493064.12016262.12445669.8674578/D=groups/S=1706554205:NC/Y=YAHOO/EXP=1206214188/L=/B=4xJEDELaX.o-/J=1206206988258144/A=5028924/R=0/SIG=11e3tma2a/*<a
href=


[Non-text portions of this message have been removed]

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

----- Original Message ----- 

From: "Mike Harrison" <mike@whitewing.co.uk>
To: <AVR-Chat@yahoogroups.com>
Sent: Saturday, March 22, 2008 7:19 PM
Subject: Re: [AVR-Chat] C programming on AVR


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

I use Rowley CrossWorks for ARM and MSP430 development, it's very good. They 
have an AVR version, but I haven't tried it (I prefer assembler).

Leon
--
Leon Heller
Amateur radio call-sign G1HSM
Yaesu FT-817ND and FT-857D transceivers
Suzuki SV1000S motorcycle
leon355@btinternet.com
http://www.geocities.com/leon_heller

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

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

The comment was about the devtools, not the language. A C compile/link process is inevitably more
complex than an assemble one. Poor defaults/configs can make it a lot more complex than necessary. 

>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

NO NO NO!!!

If you want to write for embedded, learn on that, preferably via assembler first so you understand
the hardware. PC programming allows far too many bad habits to develop.

While it is true that compiling C is more complex than compiling 
assembly it is all hidden from the user so there's no real perceivable 
difference. That's what it's about. I'm not sure what C development 
experience you have first hand but getting the 'hello world' equivalent 
to compile and load using WinAVR/Stdio is close to trivial. I really 
don't see how it could be simpler. The order of magnitude gain in 
productivity comes at almost no cost.

An embedded platform is a TERRIBLE platform to learn a new language. 
You'll never know why things aren't working, too many variables. You 
need at least proficiency and preferably expertise in your programming 
language before applying it to a restrictive platform like an AVR.

    Sander

Mike Harrison wrote:

>
>
> The comment was about the devtools, not the language. A C compile/link 
> process is inevitably more
> complex than an assemble one. Poor defaults/configs can make it a lot 
> more complex than necessary.
>
> >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
>
> NO NO NO!!!
>
> If you want to write for embedded, learn on that, preferably via 
> assembler first so you understand
> the hardware. PC programming allows far too many bad habits to develop.
>
>

----- Original Message ----- 

From: "Mike Harrison" <mike@whitewing.co.uk>
To: <AVR-Chat@yahoogroups.com>
Sent: Saturday, March 22, 2008 8:39 PM
Subject: Re: [AVR-Chat] C programming on AVR


> >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.
>
> The comment was about the devtools, not the language. A C compile/link 
> process is inevitably more
> complex than an assemble one. Poor defaults/configs can make it a lot more 
> complex than necessary.
>
>>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
>
> NO NO NO!!!
>
> If you want to write for embedded, learn on that, preferably via assembler 
> first so you understand
> the hardware. PC programming allows far too many bad habits to develop.

There weren't any real embedded C compilers when I first used the language, 
most people used assembler on MCUs and desktop machines (before the PC). I 
used a C compiler for my TRS-80 when one became available to develop code 
for an embedded Z80 once, with some some difficulty, just to see if it was 
feasible.

Leon
--
Leon Heller
Amateur radio call-sign G1HSM
Yaesu FT-817ND and FT-857D transceivers
Suzuki SV1000S motorcycle
leon355@btinternet.com
http://www.geocities.com/leon_heller

On Sat, 22 Mar 2008 15:44:47 -0400, you wrote:

>
>
>While it is true that compiling C is more complex than compiling 
>assembly it is all hidden from the user so there's no real perceivable 
>difference. That's what it's about. I'm not sure what C development 
>experience you have first hand but getting the 'hello world' equivalent 
>to compile and load using WinAVR/Stdio is close to trivial. I really 
>don't see how it could be simpler. The order of magnitude gain in 
>productivity comes at almost no cost.

This is all about how well the environment has been designed, and can vary from trivial to
borderline impossible - I've seen dev environments at both ends of the spectrum.  

>An embedded platform is a TERRIBLE platform to learn a new language. 
>You'll never know why things aren't working, too many variables. 

That's what debuggers are for. Learning how to debug apps in this environment is an essential skill
you can only learn by doing. 

>You  need at least proficiency and preferably expertise in your programming 
>language before applying it to a restrictive platform like an AVR.

At a basic level, perhaps, although if you know any language of a similar type ( assember, Basic,
Pascal etc.),  transitioning to another isn't as big a step as moving from a PC type envoironment to
one where you need to have an intimate understanding of the underlying hardware. 

Certainly if you have no knowledge of programming in any comparable language, I'd totally agree that
a PC environment is a better place to learn, but once you have the hang of programming in general,
the constraints of embedded apps are more significant than differences between languages. 

>    Sander
>
>Mike Harrison wrote:
>>
>>
>> The comment was about the devtools, not the language. A C compile/link 
>> process is inevitably more
>> complex than an assemble one. Poor defaults/configs can make it a lot 
>> more complex than necessary.
>>
>> >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
>>
>> NO NO NO!!!
>>
>> If you want to write for embedded, learn on that, preferably via 
>> assembler first so you understand
>> the hardware. PC programming allows far too many bad habits to develop.
>>
>>  
>
>------------------------------------
>
>Yahoo! Groups Links
>
>
>

On Mar 22, 2008, at 1:03 PM, kholt@sonic.net wrote:

> However, the incredibly klugey nature and structure of the C
> compilers and makefile systems to me was and still is horrendous.


IMO "integrated development environments" are incredibly kludgey and  
horrendous. Makefiles are simple and elegant.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Mar 22, 2008, at 2:39 PM, Mike Harrison wrote:

>> 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
>
> NO NO NO!!!
>
> If you want to write for embedded, learn on that, preferably via  
> assembler first so you understand the hardware. PC programming  
> allows far too many bad habits to develop.


Not only "allows" but "encourages." Printf() and malloc() come to mind  
as bad habits that have to be broke to write good 8-bit embedded code.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

--- In AVR-Chat@yahoogroups.com, Sander Pool <sander@...> wrote:
> Why are printf and malloc bad habits?
Of course, using malloc() is no more a bad habit than is using a 
chainsaw.  Both can be effective when used properly, and can be 
dangerous when used carelessly.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

----- Original Message ----- 

From: "David Kelly" <dkelly@hiwaay.net>
To: <AVR-Chat@yahoogroups.com>
Sent: Saturday, March 22, 2008 11:21 PM
Subject: Re: [AVR-Chat] C programming on AVR


>
> On Mar 22, 2008, at 1:03 PM, kholt@sonic.net wrote:
>
>> However, the incredibly klugey nature and structure of the C
>> compilers and makefile systems to me was and still is horrendous.
>
>
> IMO "integrated development environments" are incredibly kludgey and
> horrendous. Makefiles are simple and elegant.

I used to think the same, but with complex devices like FPGAs, ARM and MIPS 
controllers a good IDE saves a great deal of time. The CrossWorks IDE 
includes an excellent debugger and simulator, and links to revision control 
systems; I'd hate having to go back to the techniques we used to use.

Leon
--
Leon Heller
Amateur radio call-sign G1HSM
Yaesu FT-817ND and FT-857D transceivers
Suzuki SV1000S motorcycle
leon355@btinternet.com
http://www.geocities.com/leon_heller

Why are printf and malloc bad habits? In your opinion, of course.

    Sander

David Kelly wrote:

>
>
>
> Not only "allows" but "encourages." Printf() and malloc() come to mind
> as bad habits that have to be broke to write good 8-bit embedded code.
>
> --
> David Kelly N4HHE, dkelly@HiWAAY.net <mailto:dkelly%40HiWAAY.net>
> ========================================================================
> Whom computers would destroy, they must first drive mad.
>
> __

> ... the techniques we used to use.

EPROMs, 12 of them for a 20-minute erase and one burn!  Ah, the good old 
days.


Tom

----- Original Message ----- 

From: "Tom Becker" <gtbecker@rightime.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Sunday, March 23, 2008 12:27 AM
Subject: Re: [AVR-Chat] C programming on AVR


> > ... the techniques we used to use.
>
> EPROMs, 12 of them for a 20-minute erase and one burn!  Ah, the good old
> days.

I always wrote a serial loader and simple debugger. It saved a lot of 
messing about with EPROMs.

Leon

On Mar 22, 2008, at 6:24 PM, Sander Pool top-posted:

> Why are printf and malloc bad habits? In your opinion, of course.
>
>    Sander
>
> David Kelly wrote:
>>
>> Not only "allows" but "encourages." Printf() and malloc() come to  
>> mind
>> as bad habits that have to be broke to write good 8-bit embedded  
>> code.

They both incur a lot of overhead. Printf() has to include an  
interpreter to parse your format string at run time. It has to import  
a library of all the routines necessary for all the supported format  
conversion. It encourages heavy use of the call stack, which is  
usually a limited resource. It requires a buffer to perform the  
conversion in to before sending it on to even more overhead of a stdio  
library.

Malloc generally implements a very simplistic, non-deterministic,  
allocation and freeing of memory. If you need dynamic memory  
allocation then its more dependable to build your own into your code  
because you should be better able to control your resource use and  
know in advance whether or not in the worst case one has enough  
memory. If one has enough room to statically allocate buffers at  
compile time then one's code will never fault for lack of memory  
during runtime.

Top-posting is bad because chronological order english is written left  
to right, top to bottom. That which is said last does not belong  
before that which prompted its saying.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Mar 22, 2008, at 6:19 PM, Leon wrote:

> ----- Original Message -----
> From: "David Kelly" <dkelly@hiwaay.net>
>
>> IMO "integrated development environments" are incredibly kludgey and
>> horrendous. Makefiles are simple and elegant.
>
> I used to think the same, but with complex devices like FPGAs, ARM  
> and MIPS
> controllers a good IDE saves a great deal of time. The CrossWorks IDE
> includes an excellent debugger and simulator, and links to revision  
> control
> systems; I'd hate having to go back to the techniques we used to use.

You missed the whole point.

Is well and good to have tools for generating fuse maps to configure  
complex chips. And to generate initialization code to start the chip.  
IMO Freescale MCUs have great need for these tools.

But when configuration and build options are buried under menus under  
menus and hidden in undocumented IDE binary "project" files, one is in  
the "incredibly kludgey and horrendous" zone.

Freescale's Code Warrior is especially bad at hiding one's options and  
selections.

To AVR Studio's credit it has an option to generate a Makefile. I  
haven't exercised that option. It also has option to use an external  
Makefile. Haven't used that either. But I do build my own Makefile and  
compare my output files to those generated by AVR Studio's internal  
build facility. Having my own Makefile ensures that I have captured  
and documented all the options selected. My Makefile goes in SVN along  
with everything else. Including the AVR Studio project file. The big  
difference is that one can diff versions of the Makefile and see what  
changed. The binary project files can only be compared if the  
committer thought to mention all the changes between one and the next.  
But the file changes for nothing more than the selection of open files  
in the editor, so it changes often.

One thing I have noticed is that my Makefile has an optional depend:  
target which cross references all the include files used by source  
file so that if one changes a .h file the appropriate .c files are  
recompiled. In AVR Studio one has to know to "Build All".

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

If you could stick to the subject I'd continue the conversation but 
since you feel you need to 'strengthen' your argument by berating my 
posting style I'll bow out.

    Sander

David Kelly wrote:

>
>
> On Mar 22, 2008, at 6:24 PM, Sander Pool top-posted:
>
>
>
> Top-posting is bad because chronological order english is written left
> to right, top to bottom. That which is said last does not belong
> before that which prompted its saying.
>
> --
> David Kelly N4HHE, dkelly@HiWAAY.net <mailto:dkelly%40HiWAAY.net>
>

At 05:19 AM 23/03/2008, you wrote:
>IAR's Embedded workbench C for the AVR isn't too bad,

...except for the 10 times price tag of other compilers
like CVAVR and Image Craft...that is if one wants to actually
buy a full version rather than just use the 4k limited kick start
version.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

At 05:03 AM 23/03/2008, kholt@sonic.net wrote:
>However, some versions of the Butterfly were not written in WinAVR, and the
>  code is NOT portable,

The original code from smileymicros was written on an earlier
version of winavr. Some of the stuff has changed or has been
deprecated.

The code will work with the version of winavr supplied on his
website. As you become more competent in C, you should be able
to take the code to newer versions or even different compilers.

All part of the learning method...may be...

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

David Kelly wrote:
> On Mar 22, 2008, at 1:03 PM, kholt@sonic.net wrote:
> 
>> However, the incredibly klugey nature and structure of the C
>> compilers and makefile systems to me was and still is horrendous.
> 
> 
> IMO "integrated development environments" are incredibly kludgey and  
> horrendous. Makefiles are simple and elegant.

Maybe.  I've found that some IDE's do a pretty predictable job of 
generating the makefiles.  I've used Eclipse with the AVR plugin to do 
mine and been pretty happy with the results.

DLC

> --
> David Kelly N4HHE, dkelly@HiWAAY.net
> ========================================================================
> Whom computers would destroy, they must first drive mad.
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

Don't worry about it.  To live on the 'net you need to grown thicker 
skin.  There is _always_ someone who wants to instruct us all not to 
top-post.  Like the teachers who taught us english speakers that we must 
NEVER split an infinitive (which we can very easily do [and I just 
did]), they are simply attached to a habit that does not always make 
sense.  Top post all you want - I myself get tired of wading through 
increasingly difficult to deal with >>> to get to the answer somewhere 
near the bottom of a 20 page thread...  This isn't USENET me' lads.

IMO,
DLC

Sander Pool wrote:
> If you could stick to the subject I'd continue the conversation but 
> since you feel you need to 'strengthen' your argument by berating my 
> posting style I'll bow out.
> 
>     Sander
> 
> David Kelly wrote:
>>
>> On Mar 22, 2008, at 6:24 PM, Sander Pool top-posted:
>>
>>
>>
>> Top-posting is bad because chronological order english is written left
>> to right, top to bottom. That which is said last does not belong
>> before that which prompted its saying.
>>
>> --
>> David Kelly N4HHE, dkelly@HiWAAY.net <mailto:dkelly%40HiWAAY.net>
>>
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

Sander Pool wrote:
> Why are printf and malloc bad habits? In your opinion, of course.

Oy!  You've opened a can o' worms right and proper!  Printf is a nasty 
bit of work that is a small OS in and of itself.  It has to dynamically 
restructure itself to handle different print options since there is no 
fixed order or function within its use.  As such it sucks up a bunch of 
memory for very little utility.  Malloc is simply bad because you give 
up control of how memory is being used.  You typically have little 
enough RAM lying about to get what you want done, you don't need 
something else assigning RAM to structures that you can't reuse or 
carefully control!  With embedded programming you must know where all 
your time is being spent and what RAM is being used and where it is 
being used.

DLC

>     Sander
> 
> David Kelly wrote:
>>
>>
>> Not only "allows" but "encourages." Printf() and malloc() come to mind
>> as bad habits that have to be broke to write good 8-bit embedded code.
>>
>> --
>> David Kelly N4HHE, dkelly@HiWAAY.net <mailto:dkelly%40HiWAAY.net>
>> ========================================================================
>> Whom computers would destroy, they must first drive mad.
>>
>> __
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

----- Original Message ----- 

From: "dlc" <dlc@frii.com>
To: <AVR-Chat@yahoogroups.com>
Sent: Sunday, March 23, 2008 7:28 AM
Subject: Re: [AVR-Chat] C programming on AVR


>
>
> Sander Pool wrote:
>> Why are printf and malloc bad habits? In your opinion, of course.
>
> Oy!  You've opened a can o' worms right and proper!  Printf is a nasty
> bit of work that is a small OS in and of itself.  It has to dynamically
> restructure itself to handle different print options since there is no
> fixed order or function within its use.  As such it sucks up a bunch of
> memory for very little utility.  Malloc is simply bad because you give
> up control of how memory is being used.  You typically have little
> enough RAM lying about to get what you want done, you don't need
> something else assigning RAM to structures that you can't reuse or
> carefully control!  With embedded programming you must know where all
> your time is being spent and what RAM is being used and where it is
> being used.

I was using fprintf extensively in part of an ARM application to make things 
easy, when writing formatted data to a buffer for transmission. It worked OK 
but it just took too much time and I was over-running a 20ms interrupt, so I 
had to replace it with my own function.

Leon
--
Leon Heller
Amateur radio call-sign G1HSM
Yaesu FT-817ND and FT-857D transceivers
Suzuki SV1000S motorcycle
leon355@btinternet.com
http://www.geocities.com/leon_heller

On Mar 23, 2008, at 1:03 AM, dlc wrote:

> David Kelly wrote:
>>
>> IMO "integrated development environments" are incredibly kludgey and
>> horrendous. Makefiles are simple and elegant.
>
> Maybe.  I've found that some IDE's do a pretty predictable job of
> generating the makefiles.  I've used Eclipse with the AVR plugin to do
> mine and been pretty happy with the results.

Yes. Its not the use or presence of GUI IDEs that I'm complaining  
about. Its the inability to document configuration settings because  
they are buried in the GUI and undocumented "project" file(s).

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Mar 23, 2008, at 1:27 AM, dlc wrote:

>   Don't worry about it.  To live on the 'net you need to grown thicker
> skin.  There is _always_ someone who wants to instruct us all not to
> top-post.  Like the teachers who taught us english speakers that we  
> must
> NEVER split an infinitive (which we can very easily do [and I just
> did]), they are simply attached to a habit that does not always make
> sense.  Top post all you want - I myself get tired of wading through
> increasingly difficult to deal with >>> to get to the answer somewhere
> near the bottom of a 20 page thread...  This isn't USENET me' lads.


Don't forget that when asking questions one is asking for the favor of  
a reply. If you can't speak the language, ask intelligent questions,  
and obey the forms, then don't expect a reply.

Top posting is bad. Failure to trim is equally bad. There is no excuse  
for 20 pages of quoted crap. In general top-posters are responsible  
for most cases of 20 pages of quoted crap.

Fun thing to do to yank top-poster's chains: reply in top-post format  
but change the contents of the quoted section. Then cite that quoted  
sections a couple of generations later. Top-posters who fail to trim  
never read the entire message they send.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

>  Don't forget that when asking questions one is asking for the favor of
>  a reply. If you can't speak the language, ask intelligent questions,
>  and obey the forms, then don't expect a reply.
>
>  Top posting is bad. Failure to trim is equally bad. There is no excuse
>  for 20 pages of quoted crap. In general top-posters are responsible
>  for most cases of 20 pages of quoted crap.

I'd agree with all that.

In general I find that those that tirade against top posters can't 
spell and smell of elderberry wine.

DLC

David Kelly wrote:
> On Mar 23, 2008, at 1:27 AM, dlc wrote:
> 
>>   Don't worry about it.  To live on the 'net you need to grown thicker
>> skin.  There is _always_ someone who wants to instruct us all not to
>> top-post.  Like the teachers who taught us english speakers that we  
>> must
>> NEVER split an infinitive (which we can very easily do [and I just
>> did]), they are simply attached to a habit that does not always make
>> sense.  Top post all you want - I myself get tired of wading through
>> increasingly difficult to deal with >>> to get to the answer somewhere
>> near the bottom of a 20 page thread...  This isn't USENET me' lads.
> 
> 
> Don't forget that when asking questions one is asking for the favor of  
> a reply. If you can't speak the language, ask intelligent questions,  
> and obey the forms, then don't expect a reply.
> 
> Top posting is bad. Failure to trim is equally bad. There is no excuse  
> for 20 pages of quoted crap. In general top-posters are responsible  
> for most cases of 20 pages of quoted crap.
> 
> Fun thing to do to yank top-poster's chains: reply in top-post format  
> but change the contents of the quoted section. Then cite that quoted  
> sections a couple of generations later. Top-posters who fail to trim  
> never read the entire message they send.
> 
> --
> David Kelly N4HHE, dkelly@HiWAAY.net
> ========================================================================
> Whom computers would destroy, they must first drive mad.
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 

   You can post way down here and see if the in-line posters will see it.

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

Or perhaps Ripple, Thunderchicken, or Annie Greensprings...


REB


dlc wrote:

>    In general I find that those that tirade against top posters can't 
> spell and smell of elderberry wine.
>
> DLC
>
> David Kelly wrote:
>   
>> On Mar 23, 2008, at 1:27 AM, dlc wrote:
>>
>>     
>>>   Don't worry about it.  To live on the 'net you need to grown thicker
>>> skin.  There is _always_ someone who wants to instruct us all not to
>>> top-post.  Like the teachers who taught us english speakers that we  
>>> must
>>> NEVER split an infinitive (which we can very easily do [and I just
>>> did]), they are simply attached to a habit that does not always make
>>> sense.  Top post all you want - I myself get tired of wading through
>>> increasingly difficult to deal with >>> to get to the answer somewhere
>>> near the bottom of a 20 page thread...  This isn't USENET me' lads.
>>>       
>> Don't forget that when asking questions one is asking for the favor of  
>> a reply. If you can't speak the language, ask intelligent questions,  
>> and obey the forms, then don't expect a reply.
>>
>> Top posting is bad. Failure to trim is equally bad. There is no excuse  
>> for 20 pages of quoted crap. In general top-posters are responsible  
>> for most cases of 20 pages of quoted crap.
>>
>> Fun thing to do to yank top-poster's chains: reply in top-post format  
>> but change the contents of the quoted section. Then cite that quoted  
>> sections a couple of generations later. Top-posters who fail to trim  
>> never read the entire message they send.
>>
>> --
>> David Kelly N4HHE, dkelly@HiWAAY.net
>> ========================================================================
>> Whom computers would destroy, they must first drive mad.
>