AVR Beginner Questions - Ports and Speed

David Brown wrote:

>[ snip ]
>>>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.

Acknowledging your defense of the old stuff, the short names become a 
nightmare when the names resolve to almost identity. Eg.

TempCtrlV1.asm
TempCtrlMath.asm
TempCtrlComm.asm
TempCtrlLoop.asm
TempCtrlV2.asm

Why should I not have longer names, just because some lazy guys
have other stuff to do ? I myself write Win32 applications.
They are not such a big fuss. It is quite easy actually.

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

"Al Borowski" <aj.borowski@erasethis.student.qut.edu.au> wrote in message
news:40289ebc$0$1725$5a62ac22@freenews.iinet.net.au...
> <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:

This summary covers many such threads, but not this one:

>
> 1) Programming in C will get most jobs done faster
>

True.

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

Sometimes yes, sometimes no.  On bigger processors, a good compiler will
often be able to generate better code than an assembly programmer would
typically produce, since it can use optomisation techniques that would be
very awkward to use in assembly (as an example, a compiler might optomise a
divide-by-constant into a multiply-by-reciprical, and then into a series of
shifts and adds, while the assembly programmer might use a full-blown divide
routine to improve maintainability and readability).  On small processors,
however, it is generally true.

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

I don't write much in assembly these days, because of (1).  There are few
occasions when writing critical parts in assembly provides real gains.
However, I strongly advocate learning and understanding assembly, and
learning and understanding the underlying cpu architecture, in order to be
able to write better C code, and to aid checking and debugging.  Especially
on small processors, you cannot get the best out of your compiler and
microcontroller if you do not regularly examine the generated assembly code,
and write C code that fits the target.  For example, on some systems you are
best accessing an array directly, while on others it is best to use an
explicit pointer in the C code.  Chosing the optimal form for loops, or the
appropriate data types, can make a much bigger difference than the step from
optimal C code to hand-tuned assembly.  You must learn assembly so that you
can write optimised C code, not so that you can write optimised assembly.

> YMMV
>

Definitely true.

> Al
>

Al Borowski wrote:

> 2) Ports are mapped in the data memory space, and not a seperate I/O
> space - so why have does the concept of ports exist at all?
> 
> Is this for speed reasons - an IN takes 1 cycle, while an LDS takes
> 2 cycles? Why can't SBIS etc apply to the whole data memory range?

It's not only speed, it is also code size. 

> 3) From what I've read, AVRs are supposed to be much faster then
> PICs.

First of all, the AVR runs with the undivided clock. So it does more
instructions at the same frequency.

Then you don't have an accumulator, but several (more or less) general
purpose registers. This speeds up a lot of things.
However, for your example the AVR is taking more cycles than the PIC.
This can happen ;-)
 
> The AVR code seems to be
> 
> IN <Reg>, <The Port> ; 1 cycle
> SWAP <Reg> ; 1 cycle
> ST X+, <reg> ; 2 cycles

I don't see any room for optimisation here ;-(
The only thing would be moving the "swap" to a non-time critical
place, if possible.
 
> 4 clockcycles @ 16 MHz --> can be done 4 million times/sec. Are
> operations involving memory always slower on AVRs then PICs?

Think so.

> Register-Register operations look much faster, but they aren't
> heavily used in the speed critical parts of my application.

Looks like you need either a new chip or a new concept for your
aplication.

If you have fun programming PIC-assembler, you could try the
microcontrullers from Ubicom (formerly Scenix). However, they are not
available with large RAM.

/Jan-Hinnerk

"Rene Tschaggelar" <none@none.net> schreef in bericht
news:4028bec7$0$710$5402220f@news.sunrise.ch...
>
> Acknowledging your defense of the old stuff, the short names become a
> nightmare when the names resolve to almost identity. Eg.
>
> TempCtrlV1.asm
> TempCtrlMath.asm
> TempCtrlComm.asm
> TempCtrlLoop.asm
> TempCtrlV2.asm
>
> Why should I not have longer names, just because some lazy guys
> have other stuff to do ? I myself write Win32 applications.
> They are not such a big fuss. It is quite easy actually.

I have a file here, ANALFUN.C, that, yes you guessed it, keeps
all the analysis functions ;)


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

"David Brown" <david@no.westcontrol.spam.com> schreef in bericht
news:c0afcv$dm5$1@news.netpower.no...

> This summary covers many such threads, but not this one:

Another one came to mind. If assembly takes more time, and
time is not an infinite resource, the final application is
bound to have either less performance or less functionality
and presumably lack both.

Yet another reason to sweep assembly where it belongs. And
that's a rather small arena, getting smaller by the day.


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

Frank Bemelman wrote:
> "Rene Tschaggelar" <none@none.net> schreef in bericht
> news:4028bec7$0$710$5402220f@news.sunrise.ch...
> 
>>Acknowledging your defense of the old stuff, the short names become a
>>nightmare when the names resolve to almost identity. Eg.
>>
>>TempCtrlV1.asm
>>TempCtrlMath.asm
>>TempCtrlComm.asm
>>TempCtrlLoop.asm
>>TempCtrlV2.asm
>>
>>Why should I not have longer names, just because some lazy guys
>>have other stuff to do ? I myself write Win32 applications.
>>They are not such a big fuss. It is quite easy actually.
> 
> 
> I have a file here, ANALFUN.C, that, yes you guessed it, keeps
> all the analysis functions ;)
> 
> 

Thanks for trying Frank,
you're not dragging me back to stone age.
I'm happy with Win32.

Rene

"Rene Tschaggelar" <none@none.net> schreef in bericht
news:4028d2fa$0$703$5402220f@news.sunrise.ch...
> Frank Bemelman wrote:
> > "Rene Tschaggelar" <none@none.net> schreef in bericht
> > news:4028bec7$0$710$5402220f@news.sunrise.ch...
> >
> >>Acknowledging your defense of the old stuff, the short names become a
> >>nightmare when the names resolve to almost identity. Eg.
> >>
> >>TempCtrlV1.asm
> >>TempCtrlMath.asm
> >>TempCtrlComm.asm
> >>TempCtrlLoop.asm
> >>TempCtrlV2.asm
> >>
> >>Why should I not have longer names, just because some lazy guys
> >>have other stuff to do ? I myself write Win32 applications.
> >>They are not such a big fuss. It is quite easy actually.
> >
> >
> > I have a file here, ANALFUN.C, that, yes you guessed it, keeps
> > all the analysis functions ;)
> >
> >
>
> Thanks for trying Frank,
> you're not dragging me back to stone age.
> I'm happy with Win32.

No of cource not - drives me nuts too, those older apps that
still work with 8.3 filenames. In particular because it isn't
much work to re-compile everything for win32, in general. It
was just an example of a silly abbreviation.


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

"Rene Tschaggelar" <none@none.net> wrote in message
news:4028bec7$0$710$5402220f@news.sunrise.ch...
> David Brown wrote:
>
> >[ snip ]
> >>>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.
>
> Acknowledging your defense of the old stuff, the short names become a
> nightmare when the names resolve to almost identity. Eg.
>
> TempCtrlV1.asm
> TempCtrlMath.asm
> TempCtrlComm.asm
> TempCtrlLoop.asm
> TempCtrlV2.asm
>
> Why should I not have longer names, just because some lazy guys
> have other stuff to do ? I myself write Win32 applications.
> They are not such a big fuss. It is quite easy actually.
>
> Rene

I don't think I made myself very clear.  I prefer to have long file names
available, as 8 letters is a bit too limiting.  My point was just that
unless you have such unfortunate name combinations as in your example, then
micros~1 mangled names are usable when necessary.  I have a few old
development programs that are Win16 (or even Dos16) - I'd prefer Win32
versions, but they are still useable.

I was not condemning long file names as such, only unnecessarily long file
names.  I also find file and directory names with spaces in them to be a
real pain, especially for use with command-line programs, or when passing
names as parameters to other programs.  You can generally get around any
limitations using inverted comments (unless some real smart-ass has used
inverted commas in the file name...), but why make things difficult for
yourself?

"Frank Bemelman" <fbemelx@euronet.invalid.nl> wrote in message
news:4028cf5e$0$235$a344fe98@news.wanadoo.nl...
> "David Brown" <david@no.westcontrol.spam.com> schreef in bericht
> news:c0afcv$dm5$1@news.netpower.no...
>
> > This summary covers many such threads, but not this one:
>
> Another one came to mind. If assembly takes more time, and
> time is not an infinite resource, the final application is
> bound to have either less performance or less functionality
> and presumably lack both.
>

"Assuming that C is better than assembly in all ways, it is better to write
the application in C than assembly.  QED."

You are determined to re-state your mantra no matter what, aren't you?  If
you don't like assembly, then that's fine - don't use it.  But leave the
rest of us to choose the right tool for the right job.

Short development time is *one* aspect of picking the right tools, but it is
not the only one.  It might take longer to write a program if you want to
check all the generated assembly rather than simply assuming your C compiler
is bug-free, has a perfect optimiser, and is able to read your mind, but the
resulting program will be more efficient (and perhaps have fewer bugs, since
you have checked it more carefully).  That will often equate to smaller and
cheaper hardware and lower clock speeds.

To step up a level for comparison, why do people still use C when
programming on PCs?  After all, using a language like Python would lead to
far shorter development times and avoid a great many common bugs and
security holes that often appear in big C programs (since the language helps
avoid buffer overflows and memory allocation issues).  If you want to get
the very best out of a python program, however, it can be a great help to
understand the underlying virtual machine and function implementations,
which are written in C, and it may make sense to write C-level extensions to
your python code.


> Yet another reason to sweep assembly where it belongs. And
> that's a rather small arena, getting smaller by the day.
>
>
> --
> Thanks, Frank.
> (remove 'x' and 'invalid' when replying by email)
>
>
>

"David Brown" <david@no.westcontrol.spam.com> schreef in bericht
news:c0al8d$gc7$1@news.netpower.no...
>
> "Frank Bemelman" <fbemelx@euronet.invalid.nl> wrote in message
> news:4028cf5e$0$235$a344fe98@news.wanadoo.nl...
> > "David Brown" <david@no.westcontrol.spam.com> schreef in bericht
> > news:c0afcv$dm5$1@news.netpower.no...
> >
> > > This summary covers many such threads, but not this one:
> >
> > Another one came to mind. If assembly takes more time, and
> > time is not an infinite resource, the final application is
> > bound to have either less performance or less functionality
> > and presumably lack both.
> >
>
> "Assuming that C is better than assembly in all ways, it is better to
write
> the application in C than assembly.  QED."
>
> You are determined to re-state your mantra no matter what, aren't you?  If
> you don't like assembly, then that's fine - don't use it.  But leave the
> rest of us to choose the right tool for the right job.

I'm in favour of the right tool for the right job. Just wondered
about possible consequences. That's why I started with *If*.

> Short development time is *one* aspect of picking the right tools, but it
is
> not the only one.  It might take longer to write a program if you want to
> check all the generated assembly rather than simply assuming your C
compiler
> is bug-free, has a perfect optimiser, and is able to read your mind, but
the
> resulting program will be more efficient (and perhaps have fewer bugs,
since
> you have checked it more carefully).  That will often equate to smaller
and
> cheaper hardware and lower clock speeds.
>
> To step up a level for comparison, why do people still use C when
> programming on PCs?  After all, using a language like Python would lead to
> far shorter development times and avoid a great many common bugs and
> security holes that often appear in big C programs (since the language
helps
> avoid buffer overflows and memory allocation issues).  If you want to get
> the very best out of a python program, however, it can be a great help to
> understand the underlying virtual machine and function implementations,
> which are written in C, and it may make sense to write C-level extensions
to
> your python code.

Why? More mature tool chains, and more experience with it. Which is not
a reason for not looking around. Like there are other convenient tools
too, such as Delphi or VB. It depends on what you do and where you are.

My mantra is not to ban assembly, my latest project had ~15% assembly
for good reasons. My previous project less than 0.1%. That project
was a total makeover of an inherited 100% assembly project. Running
on the same hardware. Proves nothing, but it does make clear that
assembly certainly isn't the holy grail that we are supposed to believe
it is.

For all practical - rule of thumb - purposes, assembly is dead. I have
not seen one single line of assembly in Dr. Dobbs for the last ten years.
It's reserved for small arenas such as 'close to the metal' drivers and
what have you.

You might say I get upset, when I hear die-hard assembly coders ;)


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