Which Microchip processors should I get?

[A Hellene]

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.

You are quite right. BUT,

Are we talking about Brands popularity (Microchip or Atmel) or about uCU families (see: architecture) capabilities (PIC/AVR), in order for the OP to choose from?

Was not me the one who suggested the (non Microchip/Atmel but STM, perhaps) Cortex-M architecture as the next step performance level?


-George

<EDIT>: Additions...

[sasa]

Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...

If there is some simple logic control mid-range PICs with only 35 instruction set and much lower than 1K SRAM are pretty much good as any AVR with 120+ instruction set, probably much cheaper than AVRs. And reduced cost always means better position to beat competition and more annual income for any company...

When firmware is much more complex, AVRs clearly have advantage over 8-bit PICs - the same functionality in less flash and faster execution. Etc..

With (conditionally) recently making new generation of mid-range PIC family with much more SRAM and latest acquiring of ATMEL, the "war" is ended for sure for a while now.

Nothing to argue about, however educational purpose is completely free of any pro et contra discussion.

[Howardlong]

Yet, this is NOT intended to be the beginning of another uCU war

No, of course not. 

[nctnico]

Yet, this is NOT intended to be the beginning of another uCU war; it will be about FACTS only...

If there is some simple logic control mid-range PICs with only 35 instruction set and much lower than 1K SRAM are pretty much good as any AVR with 120+ instruction set, probably much cheaper than AVRs. And reduced cost always means better position to beat competition and more annual income for any company...

The latter depends entirely on the volume which companies usually grossly overestimate. Nowadays I'd go for ARM so at least you can use a free C compiler and don't worry about speed and different kind of memories. The 8 bit PICs have a slow and crappy architecture which sooner or later requires a massive amount of work to get a project going (try to use pointers on a PIC for example). This means a lot of extra engineering costs and time and making a product more expensive compared to the competition. Penny wise pound foolish.

[Ian.M]

Define 'free'.   XC8 in Free mode is licensed for commercial use.  However it doesn't do much optimisation unless you've paid for a Standard or Pro licence so bloats the code and RAM usage.

The architectures are crappy, and the lower/older you go in the Microchip PIC product range, the crappier they get, OTOH if you've got a compatible programmer and just need to wiggle a few pins to bring some other chip up, a PIC10F part can look rather cost effective

[nctnico]

If you have a microcontroller with a serial bootloader (like NXP's LPC ARM controllers for example) then the only thing you need for programming is a serial port. Some with USB can even behave as a mass storage device so you just drag & drop the firmware onto it. No need to mess around with programmers at all.

[CD4007UB]

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  )

For a beginner, it might help to start at the simpler end of the range of PIC microcontrollers. A good example is the PIC12F1840. It's only an 8-pin device but is still useful as a small MCU in a simple project. (In fact, it's also used by PICAXE with a BASIC interpreter as their 08M2.) If you have a PicKit2 (or similar programmer), you can program it in C/C++ (or assembly language, if you prefer). Of couse, you have to be prepared to dive into the datasheet, which, even for this simple MCU, is 382 pages long.

Programming a PIC from scratch is not as easy as with an Arduino or a TI Launchpad (with Energia), where you don't have to get to grips with low-level details. It is, though, a good idea to get at least some experience of this type of bare-metal programming.

[NorthGuy]

Are we talking about Brands popularity (Microchip or Atmel) or about uCU families (see: architecture) capabilities (PIC/AVR), in order for the OP to choose from?

Was not me the one who suggested the (non Microchip/Atmel but STM, perhaps) Cortex-M architecture as the next step performance level?

Engineering is not a popularity contest. Certainly, ARMs are popular, but does this make them more powerful?

Speaking about PIC16 architecture. It is certainly somehow clumsy, but it has what you need for MCUs. For example, you can set a bit anywhere in the memory with a single instruction such as

Code: [Select]

  bsf variable,0
Similarly, it can do increments, decrements, logical operation etc. How the all-powerful ARM fares against that? Here it is:

Code: [Select]

  ldr r1,[r0]
  orr r1,r1,#1
  str r1,[r0]
This is three instructions instead of one - three times slower (given all cache hits) and three times more code space. Doesn't sound very powerful, does it? And I don't even begin to discuss how the address of the variable got into r0.

But wait a minute, PIC's operation was atomic, but with ARM we now have 3 instructions. If an interrupt happens between loading and storing and try to modify other bits of the same variable ... Boom! Hopefully, your arm has LDREX/STREX instructiions. Then you can do:

Code: [Select]

again:
  ldrex r1,[r0]
  orr r1,r1,#1
  strex r1,r1,[r0]
  cmp r1,#0
  bne again
It is now 5 instructions and it takes much longer to execute, and even longer if an interrupt happens in the middle. Looks like 48 MHz STM32 with ARM hardly can keep up with 8 MHz (32 MHz FOSC) PIC16 doing simple bit-setting. Does it sound extremely powerful to you?

Of course, this is only one particular operation, but this is not the only situation where PICs fare well. However, if you want to multiply bunch of 32-bit numbers as they do in benchmark tests, STM32 will go way ahead. If you really want to do lots of 32-bit arithmetics or floating point, it would be silly to take PIC16. This is something that PIC16 cannot do. But for simple embedded tasks, PIC16 is actually quite efficient.

[nctnico]

Perhaps you should do more research before posting! Ofcourse ARM controllers have ways to set or clear bits on a GPIO so a single store instruction does the job. No need for read-modify-write and atomicity isn't an issue.

[NorthGuy]

Perhaps you should do more research before posting! Ofcourse ARM controllers have ways to set or clear bits on a GPIO so a single store instruction does the job. No need for read-modify-write and atomicity isn't an issue.

Perhaps you're responding to my post (since yours is next to mine), but I was discussing the instruction set and haven't say a word about GPIOs, so I don't understand what you wanted to say and why it is relevant.

[nctnico]

Perhaps you should do more research before posting! Ofcourse ARM controllers have ways to set or clear bits on a GPIO so a single store instruction does the job. No need for read-modify-write and atomicity isn't an issue.

Perhaps you're responding to my post (since yours is next to mine), but I was discussing the instruction set and haven't say a word about GPIOs, so I don't understand what you wanted to say and why it is relevant.

GPIOs are the only place where bit-flipping is really necessary. And yet if you insist on using bits there are ARM controllers which have SRAM bits mapped to a memory address so you can set/reset a single bit with a single instruction if you want to.

[mikeselectricstuff]

GPIOs are the only place where bit-flipping is really necessary.

And interrupt flags.

[NorthGuy]

GPIOs are the only place where bit-flipping is really necessary.

I don't think so. Using flags is a very common programming technique. Besides, what I said also applies to increments, decrements, and other operations. PICs can do it directly in the memory.

It is even more advanced in PIC24/dsPIC33 where you can read from one memory location, perform an operation and store it at a different memory location, such as

Code: [Select]

add w0,[w1++],[w2++]
which executes all in one cycle. Not to mention no-overhead looping, which (as an example) lets you add very long numbers at a rate of 1 byte/cycle.

Any of these operations would take several instructions in ARM, so the overall performance of the ARM processor per MHz is nowhere close.

Of course, ARM can do 32-bit multiplication very quickly, and there are cases where this is important, but in many other cases it is not - what you read from sensors/ADC is usually 8-bit or 16-bit, rarely 32. So, I wouldn't equate 32-bitness with performance.

And yet if you insist on using bits there are ARM controllers which have SRAM bits mapped to a memory address so you can set/reset a single bit with a single instruction if you want to.

Interesting. I've never came across such beasts. What are they?

[Howardlong]

And yet if you insist on using bits there are ARM controllers which have SRAM bits mapped to a memory address so you can set/reset a single bit with a single instruction if you want to.

Interesting. I've never came across such beasts. What are they?

"Bit banding" is available in Cortex M3 and M4(f) by mapping a 32MB address space to a 1MB physical address space. Cortex M3, M4(f) and M7 also have some additional bit field manipulation instructions.

[hans]

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.

This shouldn't even be an argument; just a discovery that there are multiple architectures in the world.

The AVR is register based, load/store architecture as most modern architectures.
The 8-bit PICs still uses an accumulator architecture.

Both have their advantages and disadvantages (e.g. chip area). The AVR has 32 registers, but that also means a large context to save on an interrupt or context switch. Other architectures like ARM struggle with this as well, e.g. a huge selling point for Cortex m3 CPU's over ARM7TDMI was the better interrupt latency.

Also the AVR has a powerful instruction set, but also quite inconsistent. E.g. on ATMEGA328P there is a subtract-carry with immediate instruction, but no add-carry with immediate instruction. You can use MUL unsigned on all registers in the map, but MUL signed on only r16-r31. Memory loads only work on r16-r31 as well. AVRs have X/Y/Z registers for indirect pointer accessing, of which X does not support offsets - yet the GCC compiler likes to use the X register like that. Hence the GCC flag "mstrict-x".

And I could go on.. Of course this is a limitation from the 16-bit instruction words (valid reason for PIC24 to use 24-bit instructions); but they chose to implement a feature rich ISA, which eventually grew in to this heterogenous instruction set (a nice way of saying it's a mess). It makes coding for the AVR in assembly harder (AVR-GCC7 still generates strange looking code), but you can create higher performance programs because it is more capable.

The PICs are really quite straight forward and simple. Yes, you can be frustrated by the CLK/4 ratio and the very limited memory model of an accumulator architecture - but that's the way it is. And as long you're dealing with stuff in tenths of microseconds, it's probably fast enough.

For learning get both architectures. Discover differences for yourself.

[nctnico]

It is even more advanced in PIC24/dsPIC33 where you can read from one memory location, perform an operation and store it at a different memory location, such as

Code: [Select]

add w0,[w1++],[w2++]which executes all in one cycle. Not to mention no-overhead looping, which (as an example) lets you add very long numbers at a rate of 1 byte/cycle.

That won't execute in one cycle because it needs two memory access cycles. Besides that ARM Cortex Mx has similar indexing operation (both post and pre -indexed) and the Cortex M4 (and higher) have SIMD instructions to speed up DSP algorithms. Also ARM microcontrollers usually have several memory busses capable of doing an instruction fetch, DMA transfer and memory access at the same time (modified harvard). ARM has a huge amount of resources to throw at creating really clever CPUs for microcontrollers so don't think they'll leave out anything which makes their cores perform considerably less than the CPUs from a competitor.

[NorthGuy]

That won't execute in one cycle because it needs two memory access cycles.

PIC24's instruction cycle is two clock long.

ARM has a huge amount of resources to throw at creating really clever CPUs for microcontrollers so don't think they'll leave out anything which makes their cores perform considerably less than the CPUs from a competitor.

This is not a question of performance. They only need to make you believe they cores MUST be better than others, make sure you don't question their performance, and you will buy them. Real performance doesn't really mater. As you can see, it is working brilliantly. Marketing dollars go a long way compared to R&D. Of course, it all will be in the dust as soon as the next popular thing emerges.

[A Hellene]

Yet, this is NOT intended to be the beginning of another uCU war

No, of course not. 

 

Hey, guys! The best CPU is the one that does the job.

-George

[nctnico]

That won't execute in one cycle because it needs two memory access cycles.

PIC24's instruction cycle is two clock long.

ARM has a huge amount of resources to throw at creating really clever CPUs for microcontrollers so don't think they'll leave out anything which makes their cores perform considerably less than the CPUs from a competitor.

This is not a question of performance. They only need to make you believe they cores MUST be better than others,

Well so far you haven't shown me anything the ARM can't do and/or is particulary slower at.

[NorthGuy]

Well so far you haven't shown me anything the ARM can't do and/or is particulary slower at.

No. I'm not a match to ARM marketers.

[JPortici]

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.

even more, he shouldn't get an MCU from the free samples program.
he should buy one of the inexpensive st or cypress or atmel or nxp boards or even the mplab xpress board.. and get samples of ADCs, DACs, Other chips, which won't care a bit which processor is talking to them.

[Howardlong]

Note that the MPlAB Xpress board is that it’s programmer only, there’s no debug on board. While this might not be a problem for everyone, it's a significant limitation for many. On the other hand, the Microchip Starter Kit, Curiosity and Microstick boards all offer onboard debug.

[Ian.M]

If Microchip wished to restrict their free samples program to registered companies or to account holders at major component distributors they could easily do so.   Instead they supply samples to hobbyists and students without quibbling.   If they can persuade one out of a hundred students to design in Microchip parts in a high volume commercial product after they graduate it will pay for all the free samples.  As a bona fide student, don't be reluctant to make use of manufacturers' free samples, but please don't abuse the program by ordering parts you do not need or by not contributing to the user community.

The advantage of a Microstick is it has a very cheap on-board debugger, all the decoupling required and a suitable crystal.  With care and good layout, you can do exactly the same with a bare chip, a PICkit 3 and a solderless breadboard.

The MPLAB Xpress boad is a joke - they could have given it a PKOB debugger and either used their remote debugging capability to support cloud based development or provided a PKOB firmware module that implements a mass storage drop a file programmer.

[JPortici]

Note that the MPlAB Xpress board is that it’s programmer only, there’s no debug on board. While this might not be a problem for everyone, it's a significant limitation for many. On the other hand, the Microchip Starter Kit, Curiosity and Microstick boards all offer onboard debug.

suggested only because it was in the sub 10 €/$/whatever class
to re-iterate my point, if one need a suggestion for a "free" mcu, even if it is for learning he probably doesn't know how to choose one, to understand what he needs, he probably doesn't have the tools to program his free mcu so it's pointless.

get peripherals/addon chips instead, they'll create the need and the requirements.

I actually prefer no debugger than the pile of crap that is the PKOB. If you want a pickit 3 that freeze a hundred times more and has worse part support* that a pickit3... please use the PKOB.

*MPLABX 4.0.1, PIC32MK GPE board, PICKIT3 has production grade support, PKOB has beta support on both programming and debugging. At least one in three times i hit pause or a breakpoint was hit, connection would be lost and the only thing i could do would be disconnect everything, kill every process, reconnect and retry. PK3 and ICD3 of course had no problems.

And because it's not only for brand new boards, last i checked the same situation applies for the dsPIC33EV CAN-LIN starter kit... which is several years old now

[Howardlong]

I can't say I've encountered such symptoms with PKOB boards such as Starter Kit, Curiosity or Microstick boards, or PicKit3 for that matter.

I do frustratingly get problems connecting to the debugger (can be any of PKOB, PickKit, ICD3, RealICE) on random occasions, sometimes it seems to be to do with the specific USB port, other times it's not so clear what fixes the problem, restarting the IDE and/or reconnecting the debugger fixes it sometimes. FWIW, I usually power the target from the debugger.

Recently I had a scenario where I needed to reboot after each debugging session which seemed to be hub-related, I don't use that hub anymore!