AVR Beginner Questions - Ports and Speed

> > It is unbelievable that it took Microchip more than 10 years to come
> > up with a 32 bit version of MPLAB. The previous versions were 16bit.
> 
> What for?  At most the change speeds up emulation.

It improves overall system performance, since 16-bit applications in
modern Windows variants are handled in a completely separate layer,
almost like Win-OS/2 (and now I come to think of it - maybe they are
archaeologically related).

Hi,

<snip>

> Just as a suggestion, there's almost no need to write in assembly
> language.  You can accomplish more, and accomplish it more quickly, if
> you use a higher level programming language like C or C++.  It's an
> excellent skill to know assembly language, it gives to a handle on to
> what's really going on.  And it can also be very useful to look at the
> assembly code generated by the C compiler in order to aid debugging.
> But you'll end up writting better code if you start doing it in C or
> C++.

I agree that C is normally the way to go. I'm using assembly for 2 reasons:

1) For this application, every cycle counts. I spent 15 mins to shave 
100ns off the inner loop. I've moved from a 40 MHZ PIC (upto 10 MIPS) to 
a 24 MHz AVR (up to 24 MIPS) for speed reasons.

Even the AVR is probably underpowered for this project. I probably 
should use an ARM or something.

2) Believe it or not, but I prefer writing asm for small projects. Maybe 
I'm insane :-)


> 
> If you go to www.avrfreaks.com , you'll find a link to the gcc
> compiler for avr.  It's the same compiler that is used for linux, and
> it's been ported to quite a few processors.  I've used it for the
> Hitachi h82633, and it's excellent.  Best of all, it's free.  I
> suggest that you check it out.

Thanks for the suggestion, I'll give it a try.

Al

> 
> Dan
> 
> 

<snip>

I can see where this is going...

This is going to turn into yet another "C vs ASM" threads.

To head this off, I'll repeat the conclusions of all the other threads:

1) Programming in C will get most jobs done faster

2) Programming in ASM will take longer, but will produce smaller/faster code

3) One of the most productive strategies is to code in C, but optimise 
the time critical parts in ASM.

YMMV

Al

Meindert Sprang wrote:

> "Rene Tschaggelar" <none@none.net> wrote in message
> news:4027bc18$0$699$5402220f@news.sunrise.ch...
> 
>>What for ? A Win16 program assumes it can waist the cpu cycles and
>>they tend to run in some polling mode. Whereas a Win32 application
>>only uses cycles when something happens.
> 
> I think that is enirely up to the programmer. A properly programmed Win16
> program also only reacts on events, just like a Win32 program.
> 
I've seen to much already...
> 
>>Then the filenames of Win16 are in this outdated 8.3 form.
>>I'm sorry, but I'm used to long filenames.
>>Then the textfiles are limited to 32 or 64 kbytes.
> 
> 
> Since when? The fact the Notepad couldn't handle more that 64k doesn't mean
> a file cannot be longer in Win16.

Except the editor tends to be a notepad descendent.

> 
>>We're further used to have datafiles in the mydocument\whatever
>>directory, not where the application resides anymore.
> 
> What does that have to do with Win16/Win32? The files are where I store them
> or where the application has it's default path programmed or whatever.

Except when a path like '\my documents\mplab\project xyz\', (note the 
spaces) is not doable.


Rene

Ian Bell wrote:
> David Brown wrote:
> 
> 
>>If there are exceptions, then it is not a rule.  The common opinion among
>>PHBs is that C is "easier" than assembly, and therefore every embedded
>>project should be written in C and not assembly. 
> 
> 
> Forgive my ignorance but what is a PHB??

Pointy-Haired-Boss - The moronic manager from dilbert. http://dilbert.com

Al

> 
> Ian
> 

On Mon, 09 Feb 2004 08:41:42 +1000, Al Borowski
<aj.borowski@erasethis.student.qut.edu.au> wrote:


>ClrMem: ; writes zeros to memory, 100h to 3ffh
>
>	clr R0 ; clear R0
>	ldi ZH, 1 ; setup Z to point to the start of memory
>	ldi ZL, 0

Just as a suggestion, there's almost no need to write in assembly
language.  You can accomplish more, and accomplish it more quickly, if
you use a higher level programming language like C or C++.  It's an
excellent skill to know assembly language, it gives to a handle on to
what's really going on.  And it can also be very useful to look at the
assembly code generated by the C compiler in order to aid debugging.
But you'll end up writting better code if you start doing it in C or
C++.

If you go to www.avrfreaks.com , you'll find a link to the gcc
compiler for avr.  It's the same compiler that is used for linux, and
it's been ported to quite a few processors.  I've used it for the
Hitachi h82633, and it's excellent.  Best of all, it's free.  I
suggest that you check it out.

Dan

"Dan" <dan@dontspammecauseidontlikit.com> wrote in message
news:54eg20t4edui8v1nsn8em2cfuibrv2t8bf@4ax.com...
> Just as a suggestion, there's almost no need to write in assembly
> language.  You can accomplish more, and accomplish it more quickly, if
> you use a higher level programming language like C or C++.  It's an
> excellent skill to know assembly language, it gives to a handle on to
> what's really going on.  And it can also be very useful to look at the
> assembly code generated by the C compiler in order to aid debugging.
> But you'll end up writting better code if you start doing it in C or
> C++.

NONSENSE!!!!!!

Many projects I do NEED at least a piece of assembly. Futher, I very often
check the produced assembler from the compiler to be able to 'fine tune' the
C-code to produce the fastest assembly code.
I also once hired a programmer that up till that moment had only written C
for the PC/DOS/Windows platform. His job was to port C code for a TI DSP to
C code for a Motorola DSP. Apart from a very generic piece of C code in this
project, that was developed to be ANSI as much as possible, there was so
much low level hardware interaction involved that he just HAD to check the
resulting assembly code. And he found it an eye-opening experience to be
able and to be forced to look at the resulting assembly.

I strongly believe that it is an illusion that you can develop a good
embedded application without good knowledge about the assembly of the
processor to be used.

This reminds me of a story in Embedded Systems Programming: a harddisk
manufacturer produced harddisks with their firmware written in assembly.
Management believed all the crap about producing better code with C and
forced the developers to rewrite the firmware in C, before implementing new
features. After three months of struggling, the developers reverted to
assebler and implemented the new features in a week.

Meindert

"Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> schreef in bericht
news:40288489$1@news.nb.nu...
> "Dan" <dan@dontspammecauseidontlikit.com> wrote in message
> news:54eg20t4edui8v1nsn8em2cfuibrv2t8bf@4ax.com...
> > Just as a suggestion, there's almost no need to write in assembly
> > language.  You can accomplish more, and accomplish it more quickly, if
> > you use a higher level programming language like C or C++.  It's an
> > excellent skill to know assembly language, it gives to a handle on to
> > what's really going on.  And it can also be very useful to look at the
> > assembly code generated by the C compiler in order to aid debugging.
> > But you'll end up writting better code if you start doing it in C or
> > C++.
>
> NONSENSE!!!!!!
>
> Many projects I do NEED at least a piece of assembly. Futher, I very often
> check the produced assembler from the compiler to be able to 'fine tune'
the
> C-code to produce the fastest assembly code.
> I also once hired a programmer that up till that moment had only written C
> for the PC/DOS/Windows platform. His job was to port C code for a TI DSP
to
> C code for a Motorola DSP. Apart from a very generic piece of C code in
this
> project, that was developed to be ANSI as much as possible, there was so
> much low level hardware interaction involved that he just HAD to check the
> resulting assembly code. And he found it an eye-opening experience to be
> able and to be forced to look at the resulting assembly.
>
> I strongly believe that it is an illusion that you can develop a good
> embedded application without good knowledge about the assembly of the
> processor to be used.
>
> This reminds me of a story in Embedded Systems Programming: a harddisk
> manufacturer produced harddisks with their firmware written in assembly.
> Management believed all the crap about producing better code with C and
> forced the developers to rewrite the firmware in C, before implementing
new
> features. After three months of struggling, the developers reverted to
> assebler and implemented the new features in a week.

There are always exceptions to the rule. Rule of thumb is that
assembler is dead.

-- 
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)

"Rene Tschaggelar" <none@none.net> wrote in message
news:4027fe0f$0$712$5402220f@news.sunrise.ch...
> Meindert Sprang wrote:
>
> > "Rene Tschaggelar" <none@none.net> wrote in message
> > news:4027bc18$0$699$5402220f@news.sunrise.ch...
> >
> >>What for ? A Win16 program assumes it can waist the cpu cycles and
> >>they tend to run in some polling mode. Whereas a Win32 application
> >>only uses cycles when something happens.
> >
> > I think that is enirely up to the programmer. A properly programmed
Win16
> > program also only reacts on events, just like a Win32 program.
> >

Win16 programs which do a lot of communication (such as with an emulator)
are frequently very bad at handling multi-tasking properly, and have a lot
of busy-waiting loops.  Co-operative multitasking just does not have the
same functionality as pre-emptive multi-tasking and multi-threading.  Of
course, a well-designed Win16 will still be better than a badly designed
Win32 program.

> I've seen to much already...
> >
> >>Then the filenames of Win16 are in this outdated 8.3 form.
> >>I'm sorry, but I'm used to long filenames.
> >>Then the textfiles are limited to 32 or 64 kbytes.
> >
> >
> > Since when? The fact the Notepad couldn't handle more that 64k doesn't
mean
> > a file cannot be longer in Win16.
>
> Except the editor tends to be a notepad descendent.

Simple editor components are frequently based directly on a text box
component, which is limited to 64k on Win16.  Handling any data greater than
64k is a hassle in Win16, so programmers only do it if it is necessary.

>
> >
> >>We're further used to have datafiles in the mydocument\whatever
> >>directory, not where the application resides anymore.
> >
> > What does that have to do with Win16/Win32? The files are where I store
them
> > or where the application has it's default path programmed or whatever.
>
> Except when a path like '\my documents\mplab\project xyz\', (note the
> spaces) is not doable.
>

Such paths work with Win16 programs - you just have to put up with calling
it "mydocu~1\mplab\projec~1\".  Of course, "My documents" is a daft place to
put anything useful in the first place - just because MS provides stupid
defaults doesn't mean you have to use them.  For a programmer and a
developer, life is often easier if you stick to path names without spaces,
and short sensible names are much easier to remember and type than long
descriptive ones.

>
> Rene

"Frank Bemelman" <fbemelx@euronet.invalid.nl> wrote in message
news:40288a05$0$93686$cd19a363@news.wanadoo.nl...
> "Meindert Sprang" <mhsprang@NOcustomSPAMware.nl> schreef in bericht
> news:40288489$1@news.nb.nu...
> > "Dan" <dan@dontspammecauseidontlikit.com> wrote in message
> > news:54eg20t4edui8v1nsn8em2cfuibrv2t8bf@4ax.com...
> > > Just as a suggestion, there's almost no need to write in assembly
> > > language.  You can accomplish more, and accomplish it more quickly, if
> > > you use a higher level programming language like C or C++.  It's an
> > > excellent skill to know assembly language, it gives to a handle on to
> > > what's really going on.  And it can also be very useful to look at the
> > > assembly code generated by the C compiler in order to aid debugging.
> > > But you'll end up writting better code if you start doing it in C or
> > > C++.
> >
> > NONSENSE!!!!!!
> >
> > Many projects I do NEED at least a piece of assembly. Futher, I very
often
> > check the produced assembler from the compiler to be able to 'fine tune'
> the
> > C-code to produce the fastest assembly code.
> > I also once hired a programmer that up till that moment had only written
C
> > for the PC/DOS/Windows platform. His job was to port C code for a TI DSP
> to
> > C code for a Motorola DSP. Apart from a very generic piece of C code in
> this
> > project, that was developed to be ANSI as much as possible, there was so
> > much low level hardware interaction involved that he just HAD to check
the
> > resulting assembly code. And he found it an eye-opening experience to be
> > able and to be forced to look at the resulting assembly.
> >
> > I strongly believe that it is an illusion that you can develop a good
> > embedded application without good knowledge about the assembly of the
> > processor to be used.
> >
> > This reminds me of a story in Embedded Systems Programming: a harddisk
> > manufacturer produced harddisks with their firmware written in assembly.
> > Management believed all the crap about producing better code with C and
> > forced the developers to rewrite the firmware in C, before implementing
> new
> > features. After three months of struggling, the developers reverted to
> > assebler and implemented the new features in a week.
>
> There are always exceptions to the rule. Rule of thumb is that
> assembler is dead.
>

If there are exceptions, then it is not a rule.  The common opinion among
PHBs is that C is "easier" than assembly, and therefore every embedded
project should be written in C and not assembly.  The reality is that C is
much better than assembly for many types of tasks, but writing in assembly
is much better for other tasks.  And even when you are writing in C, an
*understanding* of the assembly is essential - you can't understand a cpu
architecture without understanding its assembly language, and you can't
write small, fast and reliable code (in any language) for a cpu without
understanding it properly.  How good the code must be depends on various
factors, such as the balance between time spent in development and the size
and speed of the required microcontroller, but writing top-quality code in C
requires that you examine the generated assembly code and have enough
understanding to know how the generated code works, and how it can be
improved upon.  Whenever I start working with a new microcontroller, I write
my first few programs (often just test programs) in assembly - even if all
the rest of the development will be in C.