Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Atmel vs PIC

Status
Not open for further replies.
I've been working on with PICs since the 16C54, I see alot of Atmel chips look similar, same type of projects etc. Is there a reason one would choose one over the other?

For me the PIC is much eaiser to find, I have the tools to debug it and I'm familiar with it. I'm just curious to why you (the reader) chooses one vs the other.
 
For me the PIC is much eaiser to find, I have the tools to debug it and I'm familiar with it. I'm just curious to why you (the reader) chooses one vs the other.[/quote]

I started out as a PIC 18F64 fan for years. Then saw the Atmel 1200A and 2313 was a lot less money (or was at the time) for the same type chip. I found a program called RVKBasic compiler (free at www.bastoc.com) and built a programmer.

Use it all the time to bang out small projects. Also, I use the internal osc. to save a little more money and time as well. They are both good chips.

Atmel has a Mega8 and tiny series now and you get a lot of chip for a little money.
 
i use ATMEL cause it's faster and cheaper also. it is 20 MIPS (pic is under 10 as far as i know). and also the programmer is much easyer to build and use. i tryed to make a pic programmer and failed. tryied AVR programmer and succeeded and this was the main reason i chose AVR. and also one thing i like is that the AVR is designed for C not asm. and C is i think more logical than asm.
 
z8Encore rules! Here's the schematic for DIY programmer:

**broken link removed**
Thatt's right. 2 components total.
..and, I'm just going to go away now.
 
That is an circuit programmer/debugger. Actually making a seperate chip programmer is rather pointless, since it's one pin programmable full debug, unless you just want to program a bunch of chips that aren't attached to projects for some reason..
 
Very interesting Mark!

I take it that that just works all automagically with the ZDS II development environment?

I am curious because have just been looking at the readme for the ZDS IDE and it claims to need a RS-232 will full hardware handshaking. I'm wondering they a three wire interface (I assume the ground wire is required but not shown) needs a full hardware handshake?

It's not clear to me if ZDS is free like the PIC MPLab IDE is. Short of a download and install (and I'm at work, hence I can't try right now) it is hard to tell.

I've been looking at PIC alternatives and was looking at the AVR chips.

I hadn't really looked hard at Zilog since the development boards are all costly and I couldn't find a cheap programmer, but if the programmer and debugger is truly as simple as that and the development environmemt is also free that does change things.


inaPICle
 
The IDE, which is C compiler, assembler, debugger environmet, used to come with registration of a product, but I don't think you even need that now. You should be able to just download it:

**broken link removed**

As for handshaking, I'm assuming it's talking about the rs232 smart cable programmer, and not the target interface module, which is the schematic above. Anyway, unless you really want to make the programmer above, (and there's no problems with doing that) I would just get the USB programming cable from mouser or digikey. It's just $20.00.

As an example of using it. This is a project I'm doing right now. It's a remote for my camera. It can be programmed for delay shots, or light activated shots.
**broken link removed**

I took a shot of the 3 pin programming header I have on it, and one with the USB cable plugged in for programming/debugging. The 3 pin header is just power ground, and debug. Actually I'm not even certain power is needed anymore with the USB programmer. I should check that.

This is an excellent beginner/hobbyist uC, but there are downsides. There's support and support forums, but not nearly like the number for PIC's. It's a 3.3v device, which is a bonus sometime, and a hinderence others. It's also not available very much outside of NorthAmerica.
 
When I decided to get started with microcontrollers, I downloaded a bunch of data sheets, shopped around for programmers, looked at the compilers, prices of various chips. I went with Atmel, as it seemed like the best value all around. I don't know 'C', or much about compilers, so figured I'd be using Assembly. Atmel chips have 130 instructions, and 32 registers, PIC has 32 instructions, and only one register. Figured PIC would be kind of a pain to program in assembly. The one thing that really made me jump though, was the programmer. For $50, I got the AVR Dragon, it's USB, and covers most every programming mode, debug, and supports pretty much every chip they make. Does a lot more than I really need, and half the price of what I was looking to spend. The free software is great, compared to what I was reading about PIC (got to buy, or it's a good idea to purchase, unless you have a lot of patience).

For most hobbyists, doesn't make a huge difference. Most of these chips pack way more power and features than most will ever need or use. Speed? I usually need to slow things down, lots of delay loops...
 
Atmel chips have 130 instructions, and 32 registers, PIC has 32 instructions, and only one register. Figured PIC would be kind of a pain to program in assembly.

I would like to disagree. More instructions does not result in easier programming effort. In my opinion, programming in PIC assembly is so much simpler and straight forward.

Quite a few of the AVR 130 assembly instructions are really result of certain instructions with a specific parameter. In other words, the same ASM code will be generated using another instruction.

To give an counter example, one can't find "INC W" with PIC assembly, but Microchip can easily tell the user that INC W exists and use the assembler to translate "INC W" into the ASM code of "addlw 1" and it now suddenly has 36 instructions. ATMEL chooses to do that but Microchip doesn't.

I started with PIC and tried AVR next. I like them both. Really there is not much difference between them regarding hobby usage.

For anyone considering using them, I would recommend starting with PIC first. For beginner, it is easy to mess up an AVR with configuration fuses setting and lock oneself off the chip if one don't fully understand what one is doing. A parallel HV programmer(an STK500 or Dragon) is then needed to render the AVR back to factory default settings.
 
It wont be long before Amtel is part of microchip anyway, just go to the microchip site and read the doccy.
 
I would like to disagree. More instructions does not result in easier programming effort. In my opinion, programming in PIC assembly is so much simpler and straight forward.

Quite a few of the AVR 130 assembly instructions are really result of certain instructions with a specific parameter. In other words, the same ASM code will be generated using another instruction.

To give an counter example, one can't find "INC W" with PIC assembly, but Microchip can easily tell the user that INC W exists and use the assembler to translate "INC W" into the ASM code of "addlw 1" and it now suddenly has 36 instructions. ATMEL chooses to do that but Microchip doesn't.

I started with PIC and tried AVR next. I like them both. Really there is not much difference between them regarding hobby usage.

For anyone considering using them, I would recommend starting with PIC first. For beginner, it is easy to mess up an AVR with configuration fuses setting and lock oneself off the chip if one don't fully understand what one is doing. A parallel HV programmer(an STK500 or Dragon) is then needed to render the AVR back to factory default settings.

I hadn't done any programming since moving up from the 8-bit computers, so figured on having to do all the work myself. 1k of program storage didn't seem like much at the time, and figured much of it would be used up shifting things around and temp storage on a PIC, where the AVR had it in hardware. I know now, that you can do pretty much the same things with either chips, storage and speed haven't been a problem, and don't expect to see any in a while. The compiler for the PIC makes up the difference in software and pseudo-opcodes.

I haven't destroyed or locked any AVR, been over 2 years now, and have done some abusive things. They hold up pretty well. I pretty much use the HV programming, as most of the time I don't see a need to put a header on my pcb for reprogramming, I do use sockets though.

For a hobbyist, either chip will work about the same. Will admit that there are far more resources and projects on the web for PIC, but AVR has grown very quickly over the past 2 years. I think Microchip is dreaming on the buy out, unless they figure on some how forcing it.
 
I have built a HV programmer for AVR but I have never have the need to use it for several years. The programmer is gathering dust.

Now you are familiar with AVR, why not take sometimes to play around with PIC too? It is also great fun when tools like "programmer+debugger" PICKIT2 is available from Microchip and is not that expensive.

For UK hobbyists, the PICKIT2 is a bargain if you bought the EPE magazine and get the deal from Microchip Direct. The offer doesn't end till January next year so hurry up.
 
If you're doing high speed or time critical I/O handling an AVR is 4 times faster than a pic on carefully written code, this is mostly noticed by ASM programmers as you have very tight control over code timing in ASM. AVR's are much friendlier for ASM programmers do to the large register file, and offer speed boost to do significantly decreased paging when using C code compared to a PIC. By large and far I have to agree with Harvey, I spent several months researching PICs/AVRs and other architectures and found AVR the hands down winner for me. I haven't seen an AVR PDF that has it listed and I think the major advantage PICs have is their timers can be clocked asynchronously. I think all AVRs are bound to the sampling of the system clock, so PICs definitly have the hand up in situations like frequency counters.
 
I haven't seen an AVR PDF that has it listed and I think the major advantage PICs have is their timers can be clocked asynchronously. I think all AVRs are bound to the sampling of the system clock, so PICs definitly have the hand up in situations like frequency counters.
Neither is synchronous. They both will run from external clocks and both are synchronized to the internal clock. "So PICs definately have" no hand up and you are left with performance and power characteristics to decide on.

If someone told you that AVR timers could not respond to external signals they were lying. You are quite right, counters border on useless if they can not respond to the outside world-and the silicon designers know it!
 
Last edited:
Are you sure? Nigel mentioned this a ways back and I checked the PDF for the PIC he was talking about and it specifically stated the timer was asynchronously clockable. I can't remember the model of the pic though. I thought it was neat because the PDF stated the timer was rated for 50mhz even on a much slower part clock so they were good for frequency counters. You could only sample the timer on a system clock boundry but the timer itself ran asynch, perfect for frequency counters.
 
Are you sure? Nigel mentioned this a ways back and I checked the PDF for the PIC he was talking about and it specifically stated the timer was asynchronously clockable. I can't remember the model of the pic though. I thought it was neat because the PDF stated the timer was rated for 50mhz even on a much slower part clock so they were good for frequency counters. You could only sample the timer on a system clock boundry but the timer itself ran asynch, perfect for frequency counters.
You will have to specify next time...it was not so in the ATtiny that I looked at, and now looking at a 16F876 data sheet it is mentioning the "asynchronous mode" but I am not finding the counter spec. I am seeing it a bit picky for reading the counter-you need to stop it before reading it.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top