uC selection

Ok, no one is telling me to use it cause its my decision. I use PIC's cause its easy to get free samples and most of the dev tools are free. But I guess you get what you pay for. I'm interested in moving on if there is something better. I want a modern IDE and modern dev tools and not something from the

What do you mean "seems that PICs are only for hobbyists"? What data do you have to support that conclusion?

In my opinion, you use the component that meets your requirements.

For example, I recently started a project with an Atmel AVR. It seemed to fit my needs until I discovered a really nasty characteristic in its interrupt latency response. Now, I'm using a PIC (24F family) and it works perfectly.

At another company, I needed an inexpensive uC. One of the PICs suited my needs. That company shipped tens of thousands of units with the PIC in it.

Bob

People use what they are comfortable with or what they are told to use.

Bob

It's spelled "hobbyist". Just like "lobbyist". PICs are used in cheap, high volume applications where you won't even see the part number or logo. What language do you program in? What kind of applications? Simple button-LCD-I2C or more complex signal processing?

I have programmed in a large number of languages and thats not really the issue(python, php, C/C++/C#, java, assembly, pascal, etc..). The main thing is the funcitonality and scalability.

I'm looking at TI's chips right now and trying to see how consistent the chips are. I am not doing any advanced uC system's yet(just adc and pwm stuff ATM) but eventually I'd like to get into dsp(audio processing) and other stuff. I don't want to have to learn a new chip every time I move to a new application or be limited by the architecture. PIC's seem more like entry level more than anything else and I feel like the time invested in learning them might not pay off in the long run.

The only reason I'm using pic's now is cause of how easy was to get started and the majority of it was free/low cost(tools, chips, programmer, etc...).

atmel AVR's seem similar to intel chips which I am used too as I used to do a lot of programming(although its been years) in x86. I'm not at all sure about TI and AD chips but looking at TI's now.

Microchip seems to be selling around $1 billion of inventory per year... I imagine that a goodly fraction of it is their microcontrollers. I've read that the PICs have traditionally been one of the top few in the "total number of processors installed per year" for quite some time.

The PIC chips have an admittedly quirky architecture, but I believe they're one of the better bang-for-the- buck chips in many niches.

The Atmel micros I've worked with have been pretty nice to work with. In particular, the instruction and register sets are quite C-and-compiler-friendly, and the generated code is usually quite compact. Distinctly better than the PIC or 8051 in that respect, and better IMO than the X86.

I've used the PIC18F252 in a commercial product, which is still selling. This chip provides a lot more than "entry level" chips.

Take a look at some 8051 chips. I like the architecture much more than the PIC architecture and there are lots of companies who produces 8051 compatible chips. A nice website for searching for microcontrollers is this site:

The right microcontroller depends on many things. First define your requirements (technical requirements, like low power, required interfaces, ADC/DAC etc. and other requirements, like produced by multiple companies, like some 8051 chips, free development tools, price etc.) and then choose the chip which meets all requirements. Hobbyist requirements may be other than commercial requirements (e.g. for most commercial projects it doesn't matter to buy a good IDE and compiler).

If you just want to play a bit with a new architecture, Silicon Laboratories has some nice chips and development boards. I've bought one for evaluating the 8051 architecture:

Totally absurd. I'v read the thread, and you carry on about win3.1, IDE what not. I'v done video processing with an 8 pin PIC, with as only tool a scope and the gnu assembler..

A good musician can play wonderful music on a child's flute, a bad musician will still sound horrible on a Steinway,

You are too vague, look for a project first, then select a suitable micro. THAT is the way the professionals work. There is always a cost issue too. PICs win here many times. For more complex things the next step is more likely a small Linux based board, whatever processor does not matter, as you then program in C anyway.

#include

I finally got tired of the PIC's paging and banking schemes, not to mention the single "working register." That said, some apps match up pretty well with that architecture and it does show up inside many commercial products, especially white goods -- my outside HVAC unit is PIC-controlled. You probably have more PICs at home than you realize.

In the 8-bit world, I find the AVRs to be a comfortable architecture, especially with the deep set of general purpose registers and a nice instruction set. Handy for home/hobby, also, given that many parts are still available as 5V and DIP. In-system programmable with an inexpensive programmer (roll-yer-own is possible).

However, I'd recommend that you take a good look at the ARM family if you're interested in trying something new. No DIPs, so you'll need a dev board but fortunately these are available and cheap. Olimex has a bunch and they're distributed by Sparkfun. ARM cores also support multiply-and-accumulate (MAC) so, while they're not dedicated DSP chips, they're not incapable of DSP functionality.

what?

commercial

Upto the other month I'd used Pics for over 10 years, resulting in large numbers being used in a mainly industrial environment. Surely that's commercial use?. If quantities are vast ('consumer', e.g. mice) then Pics in the form of (say) Holtek parts turn up but are then not directly recognisable. Look in suppliers catalogues under "micros". There's maybe 10 micro types on offer and that's what industry will be using in it's products. Quantities out there inversely proportional to page pricing. I recently changed to the Atmel AVR series and found it a vast improvement on the Pic. Not a commercial decision, just that the AVR is clean enough to not have to waste intellectual effort wrangling with Pic style idiosyncrasies, hence leaving more quality time with the 'reason-for-the-product-the-first-place' analogue bits.

Yeah, I agree. It was annoying but I moved to PIC24's and C so you don't have to worry about that stuff as much.

I've heard a lot about the AVR's and I guess its time to look into them. IIRC they are 8-bit though. Not that it probably matters if its coded in C but I'd rather have a 16-bit architecture(and preferably a 32-bit one if its not much more expensive).

I'll look. I was looking at some of the ARM based TI chips but there quite expensive compared to pics(10x or so).

The more I get into the PIC the more I dislike it instead of the reverse. Although what I do like aobut it is the large number of perepherials built in... but the C libraries are crappy(essentially just macro wrappers of the assembly code instead of actually being much more useful) and its a pain to program inassembly because of its architecture(at least from what I'm used too with x86))

I've read some comparisions and it seems that the AVR is a little better but I'm not sure. I can deal with a few issues with PIC but some are might be just too much. For example, I was messing with the ADC library and some of the macro's in the adc.h header were renamed wrong when using standard bitflag combinding(not the AND_OR which was named right and corresponded to the "docs"). Another is that one of the functions do not set the unimplemented bits to 0 resulting in the ADC module not working(luckily I made a mistake and set them to 0 and it worked so I didn't spend a week trying to figure out why). Of course I spected the unimplemented bits to allow for either 0 or 1 but I guess not... ;/

I'll try to get some AVR and see what its like.

Thanks, Jon

Thanks. That site is pretty handy. I'll try to get me an ARM processor soon and hopefully I'll get some use out of it. I'll look into the 8051 too and see.

Some of the smaller LPC parts are now cheaper than the bigger PICs. For instance, the LPC2101 is only $3.32 (single qty) at digi-key.

The smaller PICs make a lot of sense, but as soon as you need more I/Os, more memory or horsepower, the PICs don't look so good anymore.

Real men use 8051s. Lots of people make them. They have a very nice instruction set and can, if needed, address quite large amounts of external memory. If one 8051 isn't good enough use two or more.

hat?

r to

ial

ems

is a

Over the last 30 years, I've designed using 6502, 8080/5, 8051 derivatives, Z80 derivatives, several PIC families, and numerous Motorola/Freescale chips. For me, the development tools are the key preference factor. Good tools save time and aggravation. For small to medium production volumes, you can easily spend any savings on chips in the development process. Even for large volume projects, time to market may be more important than chip cost.

My main complaint about Microchip is that their tools remain relatively buggy. I've spent hours with their engineers working through obscure problems, only to find out that someone there knows about the problem, but Microchip and/or their tools partner hasn't gotten around to documenting or fixing it yet.

I've come to favor Freescale chips and their CodeWarrior tools. At first, I hated CW for its complexity. It seemed like gross overkill for many projects. However, since Freescale bought Metrowerks and they came out with Version 5, using CW has gotten a lot simpler. For me, it has a good combination of advanced features and simplifying 'templates'. Compiler code efficiency and execution speed are astonishingly good and bugs are very rare.

YMMV. Paul Mathews

But it's very much the issue. PIC's architecture doesn't suit it well to C. AVR's architecture is much cleaner and better suited for high level languages. In assembly you can do whatever you want, but let's face it, it's a pain.