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. 

[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!

[JPortici]

heh, while the issues i'm having may be depending on something in my hardware configuration, doesn't change the fact that the support is officially in beta while the "real" pk3 is fully supported. they should be exactly the same thing, right?

[eugenenine]

So being a student are there any general area you are interested in, IOT, robotics, etc?  Look for ones that meet those interests.
I bought a pickit 3 a couple years ago after selling my stuff a decade or so before that.  I got the pack with the 44 pin demo board so I ordered a couple of the equivalent but in dip form so I could protoboard them.
I subscribe to Microchip's mailing list and when they introduce or highlight something that interests me I'll order a couple.  I'm not a student so I have to order through mouser or digikey but I usually just stick a pair on an existing order so the cost is trivial.  I always buy in pairs in case I let the smoke out of one

[westfw]

[ARM is better than AVR is better than PIC, etc]

By my calculations, a modern 8bit PIC (PIC16f1707 is the datasheet I happen to be looking at) can set a bit in any IO register in two (14-bit) instructions:

Code: [Select]

   movlb bank(regAddr)
   bsf offset(regAddr), regBit
A modern AVR requires 3 instructions, two of which are 32bits long - 10 bytes (because not all IOregs are accessible via SBI):

Code: [Select]

    lds r16, regAddr
    ori r16, bit
    sts r16, regAddr
A modern ARM CM0 takes a whopping 5 instruction plus 2 data words, for 18 bytes total:

Code: [Select]

    ldr r1, =regAddr
    ldr r2, [r1]
    ldr r3, =regBit
    orrs r2, r3
    str r2, [r1](ok, you could do that with only 16 bytes by changing the load of regBit to a mov (immediate) and a shift, adding one instruction but deleting 4 bytes of constant.)
(Cortex m3 and so on are better (14 bytes, one less register used) because orr gets a thumb2 "immediate" mode.)

This doesn't include "secondary effects" - the PIC code sets the memory bank register, the AVR and ARM codes use one or more of the GP registers, etc.  Nor ease of applicability to more general or less general cases.  And it's not really meant to show "better" in any real sense.  It's just a reminder that these things are more complicated than they seem at first glance.
(Now, I don't actually program any of these in assembly language on a regular basis, so I'd be happy to see these "improved."   But I did look pretty carefully, and checked C output, so I'm pretty sure that these are pretty accurate.)
(I've been finding the CM0 "16-bit thumb-only" instruction set to be pretty depressing.  Especially since it's being positioned against 8bit chip with versions having similar flash content.  But then, I guess you're not supposed to program it in assembly...)

[ataradov]

ARM can be optimized a bit:

Code: [Select]

    ldr r1, =regAddr
    ldr r2, [r1]
    mov r3, #1
    lsl r3, r3, #N
    orrs r2, r3
    str r2, [r1]
More instructions, but less data and lower overall memory usage. And if we are only setting low 8 bits (we are comparing against 8-bitters, aren't we?), then lsl is not needed, mov can take 8 bit immediate.

It is useless to compare 32-bit and 8-bit MCUs in this respect.

[NorthGuy]

And if we are only setting low 8 bits (we are comparing against 8-bitters, aren't we?), then lsl is not needed, mov can take 8 bit immediate.

If you use LDRB/STRB then you only need to access low 8 bits to reach everywhere.

It is useless to compare 32-bit and 8-bit MCUs in this respect.

Why not? By strange coincidence, all modern (perhaps not all) 32-bit processors are RISC. IMHO, RISC is not a good idea for embedded systems which execute code from flash. Of course, 32-bitness is a good thing, but is it so good that it overshadow all the  drawbacks of RISC-ness?

[ataradov]

Of course, 32-bitness is a good thing, but is it so good that it overshadow all the  drawbacks of RISC-ness?

For me, it absolutely is. And we are really talking about CM0+. CM3 and up have a lot of good instructions for this kind of stuff.

You can't compare isolated chunks of code like this. There is a lot of optimizations that come from reusing the same constants, values in registers, etc. And that's where good compiler comes in. And GCC for ARM is a very good compiler.

Furthermore, a lot of peripherals in 32-bit world are designed with registers that have set/clear on write, so you only need one write to set or  clear a set of bits. This also ensures atomic operation.

[westfw]

If you use LDRB/STRB then you only need to access low 8 bits to reach everywhere.

Yeah, but I had set the bar at "set any bit in an IO register", and in the ARM world, many of those registers can only be accessed as 32bit quantities.  It's an interesting look at why you might want your GPIO registers to be 8bit, too.

You can't compare isolated chunks of code like this. ...
a lot of peripherals in 32-bit world are designed with registers that have set/clear on write, so you only need one write to set or  clear a set of bits. This also ensures atomic operation.

Yes, and yes.   There seems to be a big problem in general defining what "typical 8bit embedded code" actually looks like.  This sort of "set one bit at a time" is very common.  ARM will show you benchmarks on how a 32bit CPU is SO much better at doing 32bit math, which is obviously true, but 32bit math is somewhat avoided by 8bit programmers.  It's hard to separate the needs from the habits...

Cases like this are interesting to explore, to see what special cases are used and when they fail.  The AVR has "sbi" that can set SOME ioreg bits.  And it has "in/out" that would shorten the code for SOME other bits.  But then if you want to make the address and bit be variables, the code bloats up even more and you get (close to) Arduino's digitalWrite() at ~50 instructions.  Whereas the ARM code is already much more "generic" and doesn't HAVE a bunch of special case instructions to tempt the assembly-language programmer or frustrate the compiler writer.

all modern (perhaps not all) 32-bit processors are RISC.

Intel x86 is far from RISC (perhaps far from "modern" as well, but it's still the elephant in the room.)  I'm a bit stunned that there aren't more x86 microcontrollers out and about, now that the original instruction set is out of IP protection.
Also Motorola Freescale NXP "Coldfire", which is essentially 68k.

[ataradov]

I'm a bit stunned that there aren't more x86 microcontrollers out and about

x86 ISA is only efficient if supported by a very complicated multilevel cache system. Otherwise it will lose big time.

[nctnico]

[ARM is better than AVR is better than PIC, etc]

By my calculations, a modern 8bit PIC (PIC16f1707 is the datasheet I happen to be looking at) can set a bit in any IO register in two (14-bit) instructions:

Code: [Select]

   movlb bank(regAddr)
   bsf offset(regAddr), regBit
A modern AVR requires 3 instructions, two of which are 32bits long - 10 bytes (because not all IOregs are accessible via SBI):

Code: [Select]

    lds r16, regAddr
    ori r16, bit
    sts r16, regAddr
A modern ARM CM0 takes a whopping 5 instruction plus 2 data words, for 18 bytes total:

Code: [Select]

    ldr r1, =regAddr
    ldr r2, [r1]
    ldr r3, =regBit
    orrs r2, r3
    str r2, [r1](ok, you could do that with only 16 bytes by changing the load of regBit to a mov (immediate) and a shift, adding one instruction but deleting 4 bytes of constant.)
(Cortex m3 and so on are better (14 bytes, one less register used) because orr gets a thumb2 "immediate" mode.)

You forgot about ARM Cortex bit-banding and seperate bit set/clear registers on typical peripherals found in an ARM microcontroller which reduce a bit set/clear operation to two instructions.

[westfw]

You forgot about ARM Cortex bit-banding and seperate bit set/clear registers on typical peripherals

I didn't "Forget."   Few CM0 chips include bit-banding, and it doesn't help much anyway (you still need to load a 1 or 0 to store to the bitband region.)  I didn't include the bitset/clear registers, because they're not present for all IO registers (which was my target) (frequently they're only present for GPIO pin registers. (which is one of the places they're most needed, of course.))

which reduce a bit set/clear operation to two instructions.

Show me?  I don't think you can get less than three instructions/8bytes (Hmm.  Better than the AVR!)

Code: [Select]

   ldr r1,=bitband(regAddr, regBit)  ;; doesn't matter if direct reg or "set" register?
   mov r2, #1
   str r2, [r1]