EmbeddedRelated.com
Forums

AVR Beginner Questions - Ports and Speed

Started by Al Borowski February 8, 2004
Hi,

I'm just getting started in AVRs. The only other microcontroller I use 
frequently are the Microchip PIC devices, and I have some (very basic) 
questions.



1) If something in data memory space isn't a register or RAM, is it a port?



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?


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

For the innerloop of a project of mine, I have to read in a set of I/O 
pins, swap the nibbles (due to a bizarre PCB layout) and write it to the 
next place in an array. I currently have a PIC18F4320 @ 40 MHz, and the 
snippet is:

swapf <the Port>,w ;4 cycles
movwf POSTINC0 ;4 cycles

This takes 8 clock cycles @ 40 MHz --> can be done 5 million times/sec

The AVR code seems to be

IN <Reg>, <The Port> ; 1 cycle
SWAP <Reg> ; 1 cycle
ST X+, <reg> ; 2 cycles

4 clockcycles @ 16 MHz --> can be done 4 million times/sec. Are 
operations involving memory always slower on AVRs then PICs?

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

Thanks,

Alistair

<snip>


> > > Don't forget to look at the support code. The PIC version above always > writes to the same location so you need code to copy it somewhere else.
No it doesn't - With a PIC18xxx, POSTINC0 will increment the pointer automatically after the operation. The
> AVR writes to successive locations using the ST X+ instruction. I suspect > that this would be tricky to do on the average PIC chip.
Nope, the above code is all thats needed! For instance, to clear all 512 bytes of RAM: -------------------------------------- ClrMem ; clears the RAM in a PIC18F4320 lfsr 0,0 ; Point file select register 0 at 0 (start of RAM) ClrMemLoop clrf POSTINC0 ; clear the current byte and automatically look at the next one ifbit FSR0H, 1 ; if we've cleared all 512 bytes return ; we're done bra ClrMemLoop ; else clear the next one --------------------------------------------------- This AVR code does almost the same thing ------------------------------------------- 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 ClrMemLoop: st Z+, R0 ; clear that location sbrs Zh, 2 ; skip if needed rjmp ClrMemLoop ret ---------------------------------- cheers, Al
Thanks for the reply


<snip>


>> 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? > > > A port is a piece of IO, with several functions. > You have an out-port, where you write to. Then there is an in-port, > which you can read, and there are in-pins. The difference being : > reading the pins reads the pins, whereas reading the port reads the > ports. If the port was set as output, and the output is shorted, reading > the port reveals what was written, while the pins read the short. > Plus a port has alternate functions on its pins.
Thanks, but I guess i was unclear. I'm aware what an I/O port is, eg PORTA etc. What I was uncertain about was the data memory map of AVRs. The Atmega162's memory map looks like: Registers - 0-1F I/O Registers - 20-5F SRAM - 80 to 45F The AVR treats things like the STATUS register as ports - this had me confused for a while. Actually, I think after playing with the simulator I have the hang of things.
> >> >> 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? >> > skip if bit is set ? how would that work ?
The same way as a PIC, I suppose. EG ifbit <some byte in RAM> , 7 ; if the 7th bit is set bra <some label> ; do something <snip>
> PICs have a 4:1 clock divider, whereas AVR run on the clock itself.
Thats my point... Even taking that into account (not all AVR instructions are single cycle), the above code is still faster on a 40MHZ PIC then a 16 MHz AVR. Are there any faster AVRs? thanks, Al
> > Rene
PS thanks for the reply!

Al Borowski wrote:

> I'm just getting started in AVRs. The only other microcontroller I use > frequently are the Microchip PIC devices, and I have some (very basic) > questions. > > 1) If something in data memory space isn't a register or RAM, is it a port? > > 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?
A port is a piece of IO, with several functions. You have an out-port, where you write to. Then there is an in-port, which you can read, and there are in-pins. The difference being : reading the pins reads the pins, whereas reading the port reads the ports. If the port was set as output, and the output is shorted, reading the port reveals what was written, while the pins read the short. Plus a port has alternate functions on its pins.
> > 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? >
skip if bit is set ? how would that work ?
> > 3) From what I've read, AVRs are supposed to be much faster then PICs. > > For the innerloop of a project of mine, I have to read in a set of I/O > pins, swap the nibbles (due to a bizarre PCB layout) and write it to the > next place in an array. I currently have a PIC18F4320 @ 40 MHz, and the > snippet is: > > swapf <the Port>,w ;4 cycles > movwf POSTINC0 ;4 cycles > > This takes 8 clock cycles @ 40 MHz --> can be done 5 million times/sec > > The AVR code seems to be > > IN <Reg>, <The Port> ; 1 cycle > SWAP <Reg> ; 1 cycle > ST X+, <reg> ; 2 cycles > > 4 clockcycles @ 16 MHz --> can be done 4 million times/sec. Are > operations involving memory always slower on AVRs then PICs? > > Register-Register operations look much faster, but they aren't heavily > used in the speed critical parts of my application. >
PICs have a 4:1 clock divider, whereas AVR run on the clock itself. 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:4026db13$0$1757$5a62ac22@freenews.iinet.net.au...
> Hi, > > I'm just getting started in AVRs. The only other microcontroller I use > frequently are the Microchip PIC devices, and I have some (very basic) > questions. > > > > 1) If something in data memory space isn't a register or RAM, is it a
port?
> > > > 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? > > > 3) From what I've read, AVRs are supposed to be much faster then PICs. > > For the innerloop of a project of mine, I have to read in a set of I/O > pins, swap the nibbles (due to a bizarre PCB layout) and write it to the > next place in an array. I currently have a PIC18F4320 @ 40 MHz, and the > snippet is: > > swapf <the Port>,w ;4 cycles > movwf POSTINC0 ;4 cycles > > This takes 8 clock cycles @ 40 MHz --> can be done 5 million times/sec > > The AVR code seems to be > > IN <Reg>, <The Port> ; 1 cycle > SWAP <Reg> ; 1 cycle > ST X+, <reg> ; 2 cycles > > 4 clockcycles @ 16 MHz --> can be done 4 million times/sec. Are > operations involving memory always slower on AVRs then PICs? > > Register-Register operations look much faster, but they aren't heavily > used in the speed critical parts of my application. > > Thanks, > > Alistair >
Don't forget to look at the support code. The PIC version above always writes to the same location so you need code to copy it somewhere else. The AVR writes to successive locations using the ST X+ instruction. I suspect that this would be tricky to do on the average PIC chip. If you use some of the AVR's 32 registers instead of SRAM on the AVR you will certainly get faster code. Peter --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/04
Al Borowski wrote:
> Thanks for the reply > > > <snip> > > >>> 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? >> >> >> >> A port is a piece of IO, with several functions. >> You have an out-port, where you write to. Then there is an in-port, >> which you can read, and there are in-pins. The difference being : >> reading the pins reads the pins, whereas reading the port reads the >> ports. If the port was set as output, and the output is shorted, >> reading the port reveals what was written, while the pins read the short. >> Plus a port has alternate functions on its pins. > > > Thanks, but I guess i was unclear. I'm aware what an I/O port is, eg > PORTA etc. What I was uncertain about was the data memory map of AVRs. > > The Atmega162's memory map looks like: > > Registers - 0-1F > I/O Registers - 20-5F > SRAM - 80 to 45F > > The AVR treats things like the STATUS register as ports - this had me > confused for a while. > > Actually, I think after playing with the simulator I have the hang of > things.
Ah, I see. They could be adressed as if they were RAM.
> >> >>> >>> 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? >>> >> skip if bit is set ? how would that work ? > > > The same way as a PIC, I suppose. EG > > ifbit <some byte in RAM> , 7 ; if the 7th bit is set > bra <some label> ; do something
Ah, I see, you mean it is restricted to registers 16-31. Yes. strange.
> > >> PICs have a 4:1 clock divider, whereas AVR run on the clock itself. > > > Thats my point... Even taking that into account (not all AVR > instructions are single cycle), the above code is still faster on a > 40MHZ PIC then a 16 MHz AVR. Are there any faster AVRs?
No there are not. The ADC and the PWM are slower than on the PICs. I tend to enhance the hardware when required though. A small CPLD does wonders for digital stuff. One of the main advantages is that the AVR has 3 pointer (index) registers. And that there are useable tools around. 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. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
Rene Tschaggelar wrote:
>
... snip ...
> > 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. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer wrote:

> Rene Tschaggelar wrote: > > ... snip ... > >>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. >
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. 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. We're further used to have datafiles in the mydocument\whatever directory, not where the application resides anymore. This 16 bit legacy stuff, beside the banking bull**** made me change over to AVR 7 or so years ago. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
"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.
> 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.
> 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. Meindert