Which Microchip processors should I get?

[biv]

Hello there,

I recently found out that I could get free microprocessors from Microchip as a student. http://www.microchip.com/samples/

I can get 2 different microprocessors each month, up to 3 units of each.

I would like to get into learning about microprocessors but am unsure which ones to get/how to utilize this resource to the best of my ability.

I have been developing with the Atmega324A and Atmega328P but would like to learn about more processors.

Which ones would you suggest getting and trying out?

Thanks!
(I tried inserting the URL as a hyperlink but couldn't figure it out  )

[ataradov]

SAM D21 / SAM D11 may be a good choice for introduction to ARM. Or SAM S70/E70/V71 if you want to get some performance.

But you will need to design boards for them, so the value of that free service may not be as great as it seems.

It would be better to actually figure out a project, and pick a micro appropriate for that project.

[Ian.M]

Got a PIC programmer?  If not the free samples will be useless to you.  If using a 3rd party or older Microchip programmer always check it supports your PIC before ordering.

If you stick to DIP package parts you can develop on a solderless breadboard.   You could do a lot worse for an introduction to the 8 bit PICs than to follow the Gooligum PIC tutorials (register for free samples of the tutorials)

N.B. Microchip blocks free samples to users registered with a free email address, and allegedly blocks certain organisations and countries completely due to fraud e.g. packs of three PICS showing up on EBAY still in Microchip Samples packaging.   You should be fine if you have your own domain. or a corporate or .edu address or an address from an ISP that does *NOT* do free email.

[biv]

I don't have a PIC programmer, or even an AVRISP either. I have one on loan from my university(AVRISP mkII), and that will soon be going back to them. I have seen these small USB programmers and will probably have to buy some of those.

[biv]

But you will need to design boards for them, so the value of that free service may not be as great as it seems.

It would be better to actually figure out a project, and pick a micro appropriate for that project.

I don't mind designing boards for them, and would probably get a breakout board from them to test before making a PCB for the whole circuit.

I'm really bad at coming up with projects so that's probably something I should tackle soon.

[westfw]

You'd be a lot better off spending $10 and getting one of the "ready to go" development boards like the Xplained Minis:
http://www.microchipdirect.com/product/search/all/xplainedmini?mns=xplained%20mini
http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM164140

The "328p Xplained Mini" is essentially similar to an Arduino Uno, except it includes debug/programming circuitry and is about 1/3 the price.   That would give you the ability to run most Arduino examples, AND use a real IDE like Atmel Studio to do more rigorous development.  Also, once you develop SOME expertise, you can probably use such a board to program other chips (certainly true of the AVR chips, and I think most 8bit PICs now come with low-voltage programming enabled, and MAYBE the ARM/PIC32 chips via swd.)

[batteksystem]

Personally, I think PIC18F4520 would be a good choice, get one of them in DIP package to use on breadboard. Another one in a TQFP to learn schematic and layout design. You will need a PICKit 3 though, either original microchip or any chinese clone will work just as well. The only think I don't like is the MPLAB X development environment. I used to get a lot of samples in Hong Kong until they stop this sample service.

[sasa]

For PIC16F and PIC18F series, pretty much any low cost programmer you can make in 10 minutes is enough.

If want to have/test USB capability, old PIC18F2550/4550 is still in production. I started also 10 years ago with PIC16F84A, PIC16F628A and PIC16F877/887.

These are some basic PICs have quite a bit of examples on internet and books.

[mikeselectricstuff]

PIC32MX170F256B - 32 bit in DIP package with tons of flash and RAM, plenty of peripherals to play with

[Ian.M]

I'll leave recommendations for the 16 and 32 bit families to those that use them more than I do and only consider the 8 bit PICs.

The PIC18F4520 is a rather old device (released 2004) - second generation PIC18 that superseded the original PIC18F452 (released 2001).  If you are looking for a general purpose 40 pin PIC18 without USB or CAN bus, you'd do better with the PIC18F46K22 (released 2010).  Its 33% faster, has double the memory and more and better peripherals.  Also when you've used up your free samples, its about 25% cheaper.  In most applications, its a pin-compatible replacement for its predecessors with only minor code changes.   The 28 pin PIC18F26K22 is basically the same but with fewer pins, and the 20 pin PIC18F14K22 is similar but with lower specs, when you need something small and cheap.

There's more good Enhanced Midrange devices (PIC12/16F1xxx(x)) than you can shake a stick at. You really need to choose the peripherals and features you need for your application rather than picking a generic one to stock.

For the 'classic' standard midrange devices, consider the 18 pin PIC16F88,  28 pin PIC16F886 and 40pin PIC16F887.  All are top of the range for memory and peripherals and have built in silicon support for debugging, which is somewhat rare in  standard midrange devices.  If you need a standard midrange PIC12, get the PIC12F683 - again its the top end one in an 8 pin package.  No built-in debugging for this one, but loosing 3 pins to the ICSP/ICD interface isn't really viable with only 5 I/Os and one input only pin to start with.

For baseline PICs my recommendation is 'not with a long barge pole' - they are best totally avoided. There are better cheaper (non-Microchip) choices for their only remaining niche in high volume production when you need to squeeze every cent out of the cost of a simple MCU.

[sasa]

BTW, a bit of help in choice would be the following online filter:

http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1005

[mikeselectricstuff]

The new PIC16F15xxx are nice e.g. 16F15355 - lots of pin remappability, multiple UARTS, lots of PWM & other goodies. DIP up to 40 pins.
 

[22swg]

Hi Biv, take a look at PIC18FxxK42... a wealth of features speed and ram.... I would suggest however you walk before you run, 

[NivagSwerdna]

PIC24FJ128GA204 Curiosity Board is a nice into.  Has a programmer built on the board.

The earlier comments above have some good suggestions if you want to breadboard and later move to PCB and/or other packages.

The PICs have a large variety of peripherals... so which one you choose might depend on what you want to do... e.g. if you want to drive an LCD screen direct... get one with an LCD driver... etc..

PS
Microchip don't just do microcontrollers.... there are other interesting things to sample too. 

[JPortici]

IMHO you shouldn't get a MCU sample if you don't know for what you're going to use it.
What i would do is get samples of all those juicy ADCs/DACs/Digipots and whatever, you can reuse them with any mcu you want.

[Rasz]

I can get 2 different microprocessors each month, up to 3 units of each.

you live in Australia and have a low low price of ~$10 a month for deciding your future? cool

When picking microcontrollers look at what is well documented, doesnt have 100 page erratas, has healthy ecosystem and following so you can get online help if needed, not random microchip errata laden garbage because they were willing to spot you ~HALF A PIZZA a month. Its healthy to practice critical thinking, start recognizing when someone is bribing you and what are the repercussions.



If you really need one (and not because someone is willing to give you something for "free") get some dev boards, not bare chips. For example bluepill ($2 stm32 arduino compatible board), Teensy 3 (freescale arm), try different vendors.

IMHO you shouldn't get a MCU sample if you don't know for what you're going to use it.
What i would do is get samples of all those juicy ADCs/DACs/Digipots and whatever, you can reuse them with any mcu you want.

this!

[eugenenine]

IMHO you shouldn't get a MCU sample if you don't know for what you're going to use it.

OP is a student, use for it is educational, its called learning.

[jpanhalt]

Hello there,

I recently found out that I could get free microprocessors from Microchip as a student. http://www.microchip.com/samples/

I can get 2 different microprocessors each month, up to 3 units of each.

I would like to get into learning about microprocessors but am unsure which ones to get/how to utilize this resource to the best of my ability.

I have been developing with the Atmega324A and Atmega328P but would like to learn about more processors.

Which ones would you suggest getting and trying out?

Thanks!
(I tried inserting the URL as a hyperlink but couldn't figure it out  )

Just abuse that generosity all you want.  Then sell them on eBay.

Now, that is not being very decent and has led to other manufacturers pulling back from the freebies.  The decision is yours.  Ethically, you should request the minimum number to do what you need to do for your current project.  In your case, that might be three (3) 12F509's.

[Howardlong]

The new PIC16F15xxx are nice e.g. 16F15355 - lots of pin remappability, multiple UARTS, lots of PWM & other goodies. DIP up to 40 pins.

As are the PIC16F18xxx, similar specs/packages to the 16F15xxx series with a slightly different peripheral distribution. I also agree with your suggestion regarding the PIC32MX170F256B.

Maybe the OP would be interested in a Microstick II, it includes and onboard debugger and comes with four devices including PIC24, dsPIC33 and a PIC32MX250F128B (similar to the PIC32MX170F256B that adds USB but with a bit less memory). You can easily use the Microstick series on their own of on breadboard. The Microstick II is compatible with dozens of devices.

[A Hellene]

Well, if you insist on using 8-bitters, the following message will NOT be in favour of the PIC microcontrollers line of products.
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...

[...]
If you need to know the reasons why not to move from AVR to PIC, please take the time to read the quoted passage at this message.

Quoting someone competent in both architectures:
- The AVR has thirty-two target registers, sixteen of which can be an 'accumulator'; the PIC has one.
- The AVR can perform conditional jumps; the PIC can only skip one instruction conditionally.
- The AVR has individual vectors for each interrupt; the PIC has a single interrupt for all.
- The AVR has a contiguous RAM memory space; the RAM on the PIC is accessed either by setting one or two bits in the status register to select the required bank or by using an indirection register (and potentially another selector bit).
- AVR registers are accessible through specialised instructions or as direct memory addressing; PIC registers are available only through the paged memory system.
- AVR completes one instruction per clock cycle; the PIC requires four cycles.
- The AVR has a stack available to the program and potentially as large as the internal RAM; the PIC has eight levels, with no user stack.
- The PIC peripherals are generally not as useful as those of the AVR, in particular the timers (though the PIC can offer interrupts on more pins (I think) than the AVR).
In general, on the AVR you generate code which targets the 'accumulator' registers; on the PIC most operations target memory directly.

and,

[...]
[ * ] Since my words about Microchip were not inspiring at all, let me quote the words of one of the most perceptive and respectable acquaintances of mine, who witnessed the whole story as an Electrical Engineer:

How could they [Microchip, to include W register in with the rest of the 'files']? That would require knowledge of design, and they never designed a microprocessor in their entire existence. They bought a cheap third rate 1970s architecture that nobody else used or wanted, and kept it alive by bolting on extensions accessed through inconvenient SFRs. It still has a hardware stack, FFS - they couldn't even fix that. It's a miracle anyone could even write a C compiler that can cope with the limitations. One thing is clear - without a C compiler, it would have sunk without trace two decades ago if users were forced to understand and deal with its architecture and could compare it to everything else in the industry. It only survived because of ignorance.

Then they compounded their previous mistakes by licensing the second-rate MIPS core for advanced products, at the moment its market share was plummeting and ARM was becoming the industry standard. Granted that Atmel also went a bit sideways with the AVR32, but at least they designed it themselves, and they have an ARM line to fall back on.
[...]
Microchip didn't conjure anything up. They rooted in General Instrument's dumpster and pulled out an evolutionary dead-end from the mid-70s (PIC1650) that had been rejected as useless by the entire engineering community, and promoted it in the hobby magazines with free development software. They couldn't sell it otherwise, as no commercial designer would consider using it. If it didn't have C compilers nobody would use it today either, as it has the most painful assembler syntax ever devised. As a single chip so you don't need to understand the electronics, and with a compiler to cover up the horror underneath... well, what can I say? Any fool can use it.
[...]
Though I should add, I was working when the GI PIC1650 came out in the 1970s, and my company looked at it and rejected it in disgust. As for Steve Ciarcia, Steve tried everything once, but I observe he settled pretty firmly on the 8051 family for most of his Byte projects. It's Jeff Bachiochi who keeps the candle burning for PIC in Circuit Cellar these days.

The conclusions are yours...


-George

[jpanhalt]

Well, if you insist on using 8-bitters, the following message will NOT be in favour of the PIC microcontrollers line of products.
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...
-George

Of course your "facts" are not only dated but several are wrong.

Have you considered the enhanced mid-range PIC's that were introduced in 2008 or maybe a little before?   
Just a few examples:
1) The stack is accessible and up to 16 levels;
2) Relative jumps of +/- 256 with the "bra" instruction; and
3) Manipulations directly on the w register, like rotates, bit tests and so forth.

 

[Howardlong]

The best microcontrollers are the ones that pay the rent.

Reports of the death of the 8 bit market are exaggerated to paraphrase Mark Twain: we've been hearing them for a couple of decades now ;-)

A reasonable approach when it comes to landing a job would be to have at least some grounding and understanding across the market.

[Ian.M]

Well, if you insist on using 8-bitters, the following message will NOT be in favour of the PIC microcontrollers line of products.
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...
-George

Of course your "facts" are not only dated but several are wrong.

Have you considered the enhanced mid-range PIC's that were introduced in 2008 or maybe a little before?   
Just a few examples:
1) The stack is accessible and up to 16 levels;
2) Relative jumps of +/- 256 with the "bra" instruction; and
3) Manipulations directly on the w register, like rotates, bit tests and so forth.

Additionally 'BRW' does a computed relative branch of up to +256 locations based on the W contents.

Even the PIC18C core, introduced back in 2000, (and its successor PIC18F cores) support most of the above: The return stack is 31 levels with a modifiable top of stack and stack pointer so is fully accessible although not directly memory mapped.  'BRA' has a 10 bit signed address offset but the  conditional branches only have an 8 bit signed address offset, and W is mirrored as the memory mapped WREG.

It would appear A. Hellene's knowledge of the 8 bit PIC families was a decade out of date already when he first registered here.

[A Hellene]

Well, if you insist on using 8-bitters, the following message will NOT be in favour of the PIC microcontrollers line of products.
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...
-George

Of course your "facts" are not only dated but several are wrong.

Have you considered the enhanced mid-range PIC's that were introduced in 2008 or maybe a little before?   
Just a few examples:
1) The stack is accessible and up to 16 levels;
2) Relative jumps of +/- 256 with the "bra" instruction; and
3) Manipulations directly on the w register, like rotates, bit tests and so forth.

Regarding the mid-range PICs of 2008, even the 1999 (now obsolete) AT90S family of the AVR (that predated the Tiny, the Mega and the XMega 8-bit AVR families) were ahead of those specifications above:
[1]: AT90S: The stack was limited ONLY by the (internal/external) SRAM amount.
[2]: AT90S: How can this beat the relative branch and the relative jump AVR instructions?
[3]: AT90S: Just a (very) small subset of the AVR 16 general purpose registers direct bit/byte manipulation capabilities...

Just try to built that with an 8-bit PIC...

If anyone needs something faster than that, with almost the same power consumption, they should feel free to ignore the 16-bit machines and directly go for the 32-bit ARM Cortex-M architecture (the M0+/M4/M7 flavours).


-George

[mikeselectricstuff]

Well, if you insist on using 8-bitters, the following message will NOT be in favour of the PIC microcontrollers line of products.
Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...

[...]
If you need to know the reasons why not to move from AVR to PIC, please take the time to read the quoted passage at this message.

Quoting someone competent in both architectures:
- The AVR has thirty-two target registers, sixteen of which can be an 'accumulator'; the PIC has one.
- The AVR can perform conditional jumps; the PIC can only skip one instruction conditionally.
- The AVR has individual vectors for each interrupt; the PIC has a single interrupt for all.
- The AVR has a contiguous RAM memory space; the RAM on the PIC is accessed either by setting one or two bits in the status register to select the required bank or by using an indirection register (and potentially another selector bit).
- AVR registers are accessible through specialised instructions or as direct memory addressing; PIC registers are available only through the paged memory system.
- AVR completes one instruction per clock cycle; the PIC requires four cycles.
- The AVR has a stack available to the program and potentially as large as the internal RAM; the PIC has eight levels, with no user stack.
- The PIC peripherals are generally not as useful as those of the AVR, in particular the timers (though the PIC can offer interrupts on more pins (I think) than the AVR).
In general, on the AVR you generate code which targets the 'accumulator' registers; on the PIC most operations target memory directly.

and,

[...]
[ * ] Since my words about Microchip were not inspiring at all, let me quote the words of one of the most perceptive and respectable acquaintances of mine, who witnessed the whole story as an Electrical Engineer:

How could they [Microchip, to include W register in with the rest of the 'files']? That would require knowledge of design, and they never designed a microprocessor in their entire existence. They bought a cheap third rate 1970s architecture that nobody else used or wanted, and kept it alive by bolting on extensions accessed through inconvenient SFRs. It still has a hardware stack, FFS - they couldn't even fix that. It's a miracle anyone could even write a C compiler that can cope with the limitations. One thing is clear - without a C compiler, it would have sunk without trace two decades ago if users were forced to understand and deal with its architecture and could compare it to everything else in the industry. It only survived because of ignorance.

Then they compounded their previous mistakes by licensing the second-rate MIPS core for advanced products, at the moment its market share was plummeting and ARM was becoming the industry standard. Granted that Atmel also went a bit sideways with the AVR32, but at least they designed it themselves, and they have an ARM line to fall back on.
[...]
Microchip didn't conjure anything up. They rooted in General Instrument's dumpster and pulled out an evolutionary dead-end from the mid-70s (PIC1650) that had been rejected as useless by the entire engineering community, and promoted it in the hobby magazines with free development software. They couldn't sell it otherwise, as no commercial designer would consider using it. If it didn't have C compilers nobody would use it today either, as it has the most painful assembler syntax ever devised. As a single chip so you don't need to understand the electronics, and with a compiler to cover up the horror underneath... well, what can I say? Any fool can use it.
[...]
Though I should add, I was working when the GI PIC1650 came out in the 1970s, and my company looked at it and rejected it in disgust. As for Steve Ciarcia, Steve tried everything once, but I observe he settled pretty firmly on the 8051 family for most of his Byte projects. It's Jeff Bachiochi who keeps the candle burning for PIC in Circuit Cellar these days.

The conclusions are yours...


-George

Few people will argue that AVR is a "nicer" CPU architecture, but the fact that Microchip now owns Atmel shows that the architecture just doesn't matter.