Hi myke (myke predko), in on Jul 8 you wrote: > Where the AVR archictecture falls short of the PIC is in the area of > register I/O (both I/O pin registers and other "SFR"). The AVR is designed > with three memory spaces (GPR, SFR and SRAM). While *some* of the GPRs are > bit addressable, none of the Special Function Registers ("SFR"), which > contain the Status Register, Interrupt control, and I/O functions, are which > means they have to be loaded into the GPR space, manipulated and then > written back. The lower SFR registers can be bit-manipulated with SBI/CBI and bit-tested with SBIC/SBIS. The IO Ports are accessable in this area. > Coupled with the different instruction timing, a PIC running > at the same speed as an AVR will definitely be able to do Parallel/Bit I/O > faster than an AVR. Reading an 8 bit IO port (IN) or writing it (OUT) takes 1 clock on AVR, that is 25% of what the PIC needs at the same speed. Even ORing a port with a literal is faster than on PIC: AVR: in W,PORTB ; in habit of PIC programming I named a ; register "W" ori W,0x12 out PORTB,W ; -> 3 cycles -> 300ns @ 10MHz PIC: movlw 0x12 iorwf PORTB,f ; -> 2 cycles -> 800ns @ 10MHz .. and this ALTHOUGH the PICs advantage is IO-ports in register-adr-space! Currently I'm using AVR for new projects most of the time. When you have plenty of cycles, it's so damn easy to do the impossible! In the past, I have done a software UART on 16C84. It was hard to hit baudrates above 9600bps (full duplex). On AVR I have done a 38400bps TOGETHER with a 100khz I2C slave! Just in software and using only a 10MHz XTAL (the part is rated 16 MHz). Just today I was programming a DPLL radio receiver. The ISR execution time worst case can sum up to >150 commands (syncword detection, PLL phase adjust, and again I included a full duplex UART). The radio and UART bit clocks have no common factors. On a PIC @ 10MHz, I'd reach a radio sampling rate of 17khz max 1s/(400ns*150). However I need 79200 Hz oversampled rate for the PLL! This project - just like most of my AVR projects - were not possible (in software only) without AVR. They would have required hardware UART, external radio bit clock recovery, or other preconditioning of the input signals. > The PIC really is the superior part if you're going to be programming in > assembly language. I found that I could dispense with the instruction data > sheet very quickly as I was developing applications (especially critically > timed ones). This is not true for the AVR. I thought the same way. But I changed my opinion after a few AVR projects. Now I don't want to miss them anymore! (but I keep my PICSTART+). > I found the Assembler to quite feature poor as well compared to MPASM How true.. > The programmer is alright, but I ended up designing my own programmer > because the $50 tool does not program parts in "Parallel mode"; this means > that the only reason why I would use a 1200 is lost; you can't enable the > internal timer and it will not do the whole Atmel line (my programmer will > also do the 20 pin 8051 parts - somebody said that the Atmel AT89Cx051 line > is virtually pin compatible with the AVR1200 (and 2313), but they don't > mention that the AT89Cx051 can't be programmed with the $50 kit). There > doesn't seem to be an Atmel development programmer that can program the > company's entire product set. Now you're not fair. You mentioned you'd advise a beginner to buy a $200 PICSTART+ over the AVR package. Yet you complain that the AVR parts are of no use to you because you spent only $50 bucks on inferior tools. You should get the MicroPRO from Equinox (don't confuse with MicroISP, another product of them). It programmes the AVR series in parallel mode (including the RC-OSC fuse bit). You get free updates on the web (www.equinox-tech.com). The programmer also does the ATMEL 89C family (89C2051, 89C52, and so on). They have a responsive email tech support. I think I paid about 350 DM for it, that's almost $200 US. When you spend that much on PIC, then do so on AVR, too (or don't complain about inferior tools).