Looking for kits to play around with, got knee deep in MCU wars

[technix]

Gee man what have I subscribed myself into... I was shopping for chips for my SushiBits Camera and got sidetracked. Now I have at least a sample of each mainstream microcontroller architecture... I have commitment issues, although maybe I should not submit to one architecture here?

Things in my handy grab bag:

* IAP15W4K61S4, AT89C51RC, IAP15F2K61S2, AT89C2051, IAP15W105, etc: 8051-compatibles
* ATmega162, ATmega32, ATmega328P, ATtiny2313, ATtiny85, etc: AVR 8-bit
* PIC18F4550, PIC16F72, PIC12F683, etc: PIC 8-bit
* dsPIC30F4011, PIC24FJ64GA002, etc: PIC 16-bit
* PIC32MX270F256B: PIC 32-bit
* STM32F030F4P6, etc: ARM Cortex-M0
* STM32F103ZET6, etc: ARM Cortex-M3
* STM32F407ZGT6, etc: ARM Cortex-M4F.
* LPC2103: ARM7TDMI
* CH563: ARM926EJ-S
* I also have an MSP430G2553 LaunchPad from my instructor as my pre-graduation gift.

Should I toss (or sell) some of those? If so, which architecture should I vent off first?

[mubes]

Lpc2103...It's nearly older than me, and that would be saying something!

[jnz]

Everyone here is going to have a different opinion.

Me for example, I have used PICs for 15 years, and fucking hate them. Oh you need a 16 bit PWM? Too bad!  So I would say dump everything 8bit including Atmel despite their support with Arduino. I'd dump the 8051 because lol you are more than 25 years too late there. And while I don't specifically dislike the PIC32, I didn't like the 16bit/33/DSP at all, and for me it all comes down to ARM.

So I'd say go with the STM32 because Cortex is the future as far as anyone can currently see. But you'll get a different opinion from everyone just like the other thread on the top of the heap right now asking the exact same question:
https://www.eevblog.com/forum/microcontrollers/is-it-worth-the-hassle-of-learning-a-new-uc-platfrom/

[Ian.M]

The PICs and the AVRs have their uses.  e.g. many of the 8 bit families have voltage ranges that will support operating from a single LiPO cell without any regulator, over its full charging and discharge voltage range and a sleep mode quiescent power consumption low enough you don't need any power switch.  There are many other applications that don't need the raw horsepower of a 32 bit processor. If you've already got a programmer/debugger for the PICs, and for the AVRs, I'd hang onto them.   

8051 family chips are a different matter - unless you have a strong interest in embedded MCU history to the point of wanting to build yourself a 8051 board, or anticipate working in an industry where legacy 8051 based products are still common, they'd be best boxed up and mailed to anyone who'll pay you postage and maybe a little beer money.

[wraper]

8051 family chips are a different matter - unless you have a strong interest in embedded MCU history to the point of wanting to build yourself a 8051 board, or anticipate working in an industry where legacy 8051 based products are still common, they'd be best boxed up and mailed to anyone who'll pay you postage and maybe a little beer money.

There are quiet a few modern MCUs with 8051 compatible cores which will beat any AVR/PIC in performance, available peripherals and for much less money.

[technix]

8051 family chips are a different matter - unless you have a strong interest in embedded MCU history to the point of wanting to build yourself a 8051 board, or anticipate working in an industry where legacy 8051 based products are still common, they'd be best boxed up and mailed to anyone who'll pay you postage and maybe a little beer money.

There are quiet a few modern MCUs with 8051 compatible cores which will beat any AVR/PIC in performance, available peripherals and for much less money.

Those STC15 series chips (the IAP15.* chips here) are a good example of those modern 8051 chips. 1T core at 30MHz or 35MHz. Also the STC chips are super cheap - I can order a whole tube of IAP15F4K61S4-30I-PDIP40 (61kB modified Harvard architecture supporting read-while-write, 1T core, 30MHz speed, supports on-chip debug) for less than US$10.

[beenosam]

If you're new to this kind of stuff, I believe the documentation (due to Arduino) for AVRs would make it easier. I have AVRs, MSP430s, and ARMs myself. I started with AVRs and found that moving to ARM was pretty easy. I'd suggest that to you, but you can look up the documentation and information for all these to see which looks best for you.

[rstofer]

I don't mind the newer ARMs but I am really fond of the LPC2106 - first ARM I used and all.

The thing is, those ARM7TDMI chips are fairly simple.  You just need a header file to define the various registers and a datasheet.  The peripherals are easy to set up and they are easy to use.  The LPC2148 is a tremendous upgrade but it's still simple to use.  Both require a bit of assembly code for startup.  The Cortex chips aren't suppose to require it but ST provides one anyway.

I don't find the STM32F easy to use.  I am messing around with CubeMX and it generates a TON (or more) of setup code.  Layers of stuff to do what I used to do with a simple init() function.  The thing is, the chip is probably complex enough to need that code.  The good news is that I only have to use the peripherals, not initialize them.

I need more time with the STM32F because I haven't even read the instructions for the HAL.  Once I get used to the hand-holding I might get to like it.  Or not...

[whalphen]

Keep them all.  When you have your project objectives identified, then you can select the best MCU for the job.  It's useful to gain experience with different processors.  Even the 8051 core is good for the right purposes.  Sure, it has been around a long time, but there are good reasons why it's still in use.

[technix]

I don't mind the newer ARMs but I am really fond of the LPC2106 - first ARM I used and all.

The thing is, those ARM7TDMI chips are fairly simple.  You just need a header file to define the various registers and a datasheet.  The peripherals are easy to set up and they are easy to use.  The LPC2148 is a tremendous upgrade but it's still simple to use.  Both require a bit of assembly code for startup.  The Cortex chips aren't suppose to require it but ST provides one anyway.

I have almost no idea how to get the LPC2103 started. I have a J-Link, but how to use it? Also how to write the startup code? I know for sure that some assembler is required but how bad would it be?

Speaking of which, I may need to write a Cortex-M style SVD file for the LPC2103, as it would give me both a header file through an SVD compiler but also a lot more debugging details in Eclipse. (Yes I am using the fully open source Eclipse + GNU stack)

I don't find the STM32F easy to use.  I am messing around with CubeMX and it generates a TON (or more) of setup code.  Layers of stuff to do what I used to do with a simple init() function.  The thing is, the chip is probably complex enough to need that code.  The good news is that I only have to use the peripherals, not initialize them.

I need more time with the STM32F because I haven't even read the instructions for the HAL.  Once I get used to the hand-holding I might get to like it.  Or not...

I have created my own Cortex-M startup library (no assembler!) and I don't use HAL. That way things are quite a bit simpler.

[westfw]

Quote

* LPC2103: ARM7TDMI
* CH563: ARM926EJ-S

Meh.  Dead due to having been replaced by the Cortex series.  Nothing WRONG with them, but they're not like to get any improvements in the future.  Focus your efforts elsewhere.
Quote

* PIC18F4550, PIC16F72, PIC12F683, etc: PIC 8-bit
* AVR

Did you say "camera"?  The 8bit PICs have an architecture that severely limits the amount of RAM in a system.  4k, IIRC.
The AVR architecture is better, but the max on-chip RAM is something like 16k.

Quote

* PIC32MX270F256B: PIC 32-bit
* STM32F030F4P6, etc: ARM Cortex-M0
* STM32F103ZET6, etc: ARM Cortex-M3
* STM32F407ZGT6, etc: ARM Cortex-M4F.

Those are all viable, IMO.  In particular, architectural knowledge will travel to much larger system architectures.  The differences between CM0 and CM3 are ... very interesting, in their way.  32bit addresses make a lot of things really easy, someone at the expense of code density.  Beware those little "16k flash" ARM chips; it's pretty hard to get them to do as much as the 16k 8bit chips.

Quote

* dsPIC30F4011, PIC24FJ64GA002, etc: PIC 16-bit
* I also have an MSP430G2553 LaunchPad

Not sure.  That particular launchpad is "very small", but the architecture is on-par with AVR (16bit pointers, natively, though.)
I've heard good things about the 16bit PICs, especially in terms of the way it makes HW design easier, but both of these seem like a dead end for anything but niche applications.

Quote

8051-compatibles

You can get fast 8051 chips, and you can get 8051 cpus married to interesting peripherals and co-processing do-dads, but the architecture is "ugly" by "modern standards" (that generally means that it's hard to write compilers for, and it doesn't scale ("why would you ever need more than 256bytes of stack?".)  Assembly language programmers whose problems fit within the architectural limitations seem to be pretty happy with it.   I'm not really sure what that means, since you don't have to write your own compilers - they already exist.  I haven't used any 8051 C/etc compiler, so I don't know whether they tend to cause inconvenient limitations...)

[technix]

1. Get rid of 8051 chips, unless you are trying to save every penny or trying to reuse legacy software, otherwise I don't think 8051 plays any roles in modern MCU market. Maybe Silabs 8051 is a different story, but that's all about peripherals, not the core.
2. Get rid of ARM7/9/11 chips, no one uses them anymore. ARM7 is more expensive and power hungry compared with modern CM, and the same for ARM9/11 compared with CA.
3. Get rid of old PICs and AVRs (those legacy models, like ATtiny85), they are not good for product design -- these legacy chips are more expensive than their modern enhanced counterparts. This is a pricing model that stimulates engineers to use new, modern chips. Their code security may also be defeated, so cloning your product is easier if you use those old chips. Keep Arduino compatible ones if you want to use Arduino library, otherwise don't use them.
4. PIC32 seems to be an oddball chip to me, not many people are using them, same for AVR32. The same extends to PIC24 and dsPIC. Unless you have a specific use (PIC32/AVR32 for ultra low cost GUI application or USB2.0 with on chip PHY for AVR32, or high res PWM for dsPIC), I don't recommend using them. Also, pro version of their compilers are not cheap.
5. Keep some modern AVR and PIC 8-bitters, just in case. But I personally don't like them, and I prefer CM0 for that purpose (low cost, low power, quick prototyping). For cost reduction, take a look at STM8.

So, I would say keep those STM32 chips, keep dsPIC chips and PIC18/24 if you really have a use for them. Keep Arduino compatible AVR chips like 328P, then get rid of all others.

I don't think there are any better 8-pin AVR than ATtiny85...

[TheDane]

Gee man what have I subscribed myself into... I was shopping for chips for my SushiBits Camera and got sidetracked. Now I have at least a sample of each mainstream microcontroller architecture... I have commitment issues, although maybe I should not submit to one architecture here?

Should I toss (or sell) some of those? If so, which architecture should I vent off first?

Use the right device/tool for the job. 
Some devices are perfect for one thing, and utterly crap at other stuff.

To throw you a bit from where you started and give you some extra options, I recommend that you look into FPGA/CPLD's - on those you can implement most processor core architectures (commonly imported as pre-compiled IP's or blocks in the design software), and all/most glue logic to other hardware - such as high speed digital displays and cameras.
Compact stuff, capable of almost anything - if you can get the software running 
- oh, and the price is       

Work with the various compilers, debuggers and systems until you have found the one(s) that works best for you, and you like using.

If you don't have your future planned out in details for the next 10+ years (or really strapped for ca$h), I recommend keeping the ones you have. A fun (one off?) project to do, is easier to do when done on an evaluation board - obviously 
Then get rid of any of the systems/components you don't like, if you need so. Original components/systems in quantity can be a gold mine to certain businesses, but I say pay off your loans and mortgage before investing money in components as it is a long and uncertain road - you sound somewhat young, if you got a TI Launchpad pre-graduation gift 

PS - I see you're missing the popular ESP WiFi modules, SW is written in Arduino/C++(Eclipse)
https://www.penninkhof.com/2015/06/esp8266-programming-from-eclipse/
http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family

[technix]

Gee man what have I subscribed myself into... I was shopping for chips for my SushiBits Camera and got sidetracked. Now I have at least a sample of each mainstream microcontroller architecture... I have commitment issues, although maybe I should not submit to one architecture here?

Should I toss (or sell) some of those? If so, which architecture should I vent off first?

Use the right device/tool for the job. 
Some devices are perfect for one thing, and utterly crap at other stuff.

To throw you a bit from where you started and give you some extra options, I recommend that you look into FPGA/CPLD's - on those you can implement most processor core architectures (commonly imported as pre-compiled IP's or blocks in the design software), and all/most glue logic to other hardware - such as high speed digital displays and cameras.
Compact stuff, capable of almost anything - if you can get the software running 
- oh, and the price is       

Work with the various compilers, debuggers and systems until you have found the one(s) that works best for you, and you like using.

I have a few MAX II EPM570 CPLD and a Cyclone IV EP4CE6 kits too.

If you don't have your future planned out in details for the next 10+ years (or really strapped for ca$h), I recommend keeping the ones you have. A fun (one off?) project to do, is easier to do when done on an evaluation board - obviously 
Then get rid of any of the systems/components you don't like, if you need so. Original components/systems in quantity can be a gold mine to certain businesses, but I say pay off your loans and mortgage before investing money in components as it is a long and uncertain road - you sound somewhat young, if you got a TI Launchpad pre-graduation gift 

PS - I see you're missing the popular ESP WiFi modules, SW is written in Arduino/C++(Eclipse)
https://www.penninkhof.com/2015/06/esp8266-programming-from-eclipse/
http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family

NodeMCU. I have that too.

[danadak]

PSOC -



For me what stands out is -

1) Routability
2) Fast 12 bit SAR A/D and slow 20 bit DelSig
3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFB
can be used as a GP fast processor block, similar to RISC block
4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGA
like capability
5) Onboard Vref
6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....
7) LCD,  COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB
9) Custom components capability, create with schematic capture or Verilog
10) DMA to offload processes like filters, COM, Display
11) ARM M0 (PSOC 4) or M3 (PSOC  5LP) or 8051 core(PSOC 3)
12) Extensive clock generation capabilities
13) All components supported by extensive prewritten APIs

https://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

http://www.cypress.com/documentation/code-examples/psoc-345-code-examples

Great video library

Attached component list.  A component is an on chip HW resource.

Free GUI design tool with schematic capture, "Creator". Components have rich API library attached
to each component. Compilers free as well.

PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as well

https://www.elektormagazine.com/labs/robot-build-with-cypress-psoc

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc

Start with this $ 10 kit -





http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and


Regards, Dana.

[technix]

I am very suspicious why there are preformatted posts about Cypress PSoC everywhere. It seem to me that someone is copy/pasting things around in a lot of MCU-centric posts. Hmm...

[james_s]

It depends on what you want to do, and what language you prefer. Most microcontrollers these days can be programmed in C, and once you can do that, the choice of platform is probably going to be more about which development software you find most appealing and which programming hardware works best for you. If you want to build or modify existing projects you come across it might make sense to go with whatever platform they use. Otherwise find something you like and stick with it, for the most part chips in the same class can do roughly the same thing. 8 bit stuff like PIC and AVR are similar, 32 bit ARM when you need more power, PSOC is great if you need extremely flexible IO, it's a bit like a microcontroller and FPGA rolled into one. Sometimes you need everything and the kitchen sink, other times a tiny inexpensive 8 pin (or less!) microcontroller is perfect.

Consider each another tool in the toolbox and use what you're most comfortable using. People get very passionate about their platform of choice but in the end it's just a tool and what you can do with it is mostly down to your ability, much like the quality of music has much more to do with the musician than the brand of instrument they play.

[Luminax]

I am very suspicious why there are preformatted posts about Cypress PSoC everywhere. It seem to me that someone is copy/pasting things around in a lot of MCU-centric posts. Hmm...

I think that's the third one I saw... hmmm
That aside, that's quite some collection you have there! Are they in 'Kits' or just single chips?
The first main problem with ANY MCUs is setting the dev-env. PIC have that quite easy as long as you have the budget to shell out for its universal PICKIT3 programmer, and although the free XC compiler is nowhere near as effective for code optimizations, it works really well.
Atmel used to be in the easy-to-medium-hard area where you can choose from the many available cheap programmers and see if it works with AVRDude or the likes. Recent years version of Atmel Studio leaves a lot to be desired (yes, I hate Visual Studio).

And then there's the oddball spectrums like Renesas, NXP, etc... those are much much harder to initially set up for, is way more expensive, and you'll be hard-pressed to search for information from their 'community', but it seems to have quite an extensive development libraries and attachments, and a lot of industries are using them making them sort of an 'industry standard'.

Your case, though, is clearly the case of having prepared a full blown chef's kitchen for cooking a sunny-side up 

[Gibson486]

PICs were great to learn on, but when I started using them for real, I began to not like them as much and then when they started messing around with MPLAB, that was the nail in the coffin.

[TheDane]

I am very suspicious why there are preformatted posts about Cypress PSoC everywhere. It seem to me that someone is copy/pasting things around in a lot of MCU-centric posts. Hmm...

I think that's the third one I saw... hmmm
That aside, that's quite some collection you have there! Are they in 'Kits' or just single chips?

This is the first I have seen as I just turned on my PC and reloaded this post. I think it fits quite well into this thread.
That's a nice dev. board with nice features - just a shame it is out of stock at RS Denmark, and Farnell is down for maintenance.
Later  , and imho one can never have too many boards 

I seem to recall the Cypress FX2LP development board sold for a pretty low price like this one is priced at, and a marvelous tool was developed and later open sourced: 8-bit logic analyzer, and up to 24MHz sampling rate. With this kind of specs, I wonder what some extremely smart people will cook up in the near future with this new baby

[technix]

That aside, that's quite some collection you have there! Are they in 'Kits' or just single chips?

Most of them single chips, either in straight DIP, or on adapter boards for breadboard prototyping. There are a few kits but those are fairly bare and primitive.

The first main problem with ANY MCUs is setting the dev-env.

I do have a good collection of debug probe hardware - Atmel ICE for AVR, PICKit 3 for PIC, two J-Link clones for various ARMs, U8W-Mini for STC 8051 and Altera USB Blaster clone for FPGA work and unidentified chips (as it works as a straight USB to JTAG converter without architecture or manufacturer limitation with OpenOCD)

My dev environment is built on top of macOS Developer Preview (weird, right? And yes I am the type of developer that pays the yearly tax to Apple.) Keep in mind that macOS on Intel CPU is UNIX in all senses - heritage (through BSD,) branding (passed the SUS certification) and functionality.

PIC have that quite easy as long as you have the budget to shell out for its universal PICKIT3 programmer, and although the free XC compiler is nowhere near as effective for code optimizations, it works really well.

PIC and ARM are by far the easiest platform to work on. MPLAB X and the associated compilers are cross platform compatible.

Atmel used to be in the easy-to-medium-hard area where you can choose from the many available cheap programmers and see if it works with AVRDude or the likes. Recent years version of Atmel Studio leaves a lot to be desired (yes, I hate Visual Studio).

It is sad that avarice avrdude is not playing nice with the much newer Atmel ICE and is acting up a lot, making AVR a no-go under macOS. And yes I hate the Windows-based development environment now, although I was an avid Windows hacker back then. Once you go UNIX there is no way back. The shell is just too damn easy to use.

And then there's the oddball spectrums like Renesas, NXP, etc... those are much much harder to initially set up for, is way more expensive, and you'll be hard-pressed to search for information from their 'community', but it seems to have quite an extensive development libraries and attachments, and a lot of industries are using them making them sort of an 'industry standard'.

For ARM the GNU toolchain and Eclipse CDT is very available, and it is rumored that the Apple LLVM/clang toolchain came standard with Xcode can also be used to build programs for Cortex-M. Renasas is a brand I never thought about using, although there are rumored J-Link support and GNU toolchain.

Your case, though, is clearly the case of having prepared a full blown chef's kitchen for cooking a sunny-side up 

I'll have to admit that yes this is quite an overkill for dev kit setup.

[Rasz]

Those STC15 series chips (the IAP15.* chips here) are a good example of those modern 8051 chips. 1T core at 30MHz or 35MHz. Also the STC chips are super cheap - I can order a whole tube of IAP15F4K61S4-30I-PDIP40 (61kB modified Harvard architecture supporting read-while-write, 1T core, 30MHz speed, supports on-chip debug) for less than US$10.

this will be extremely important ... if you work at a toy manufacturer making next 20 million units of farting tickle me elmo doll, but not in the real world
Saving pennies art a cost of code readability (C vs assembler), portability and dev time is so 10 years ago. This is a reason nobody except Chinese uses 8051 anymore.

[TNorthover]

For ARM the GNU toolchain and Eclipse CDT is very available, and it is rumored that the Apple LLVM/clang toolchain came standard with Xcode can also be used to build programs for Cortex-M.

It can. The best way to do it for a pure MachO build is by passing "-arch armv7m" (Cortex-M3 by default) or "-arch armv7em" (Cortex-M4F, hard-float ABI) to the compiler. That'll get you a nice AAPCS ABI rather than iOS's weird and ancient APCS if you'd copied XCode's command line ("-arch armv7s -mcpu=cortex-m3").

Alternatively you could install an ELF binutils and use "-target arm-none-eabi" instead. Clang itself would then behave basically the same as it does on ELF platforms.

[NorthGuy]

First of all, you don't chose MCU once and for all. You usually get a project and then you chose the MCU which fits the best. Different projects will require different MCUs.

Besides obvious stuff (e.g. if you want to communicate with UART, you need an UART module on the chip), there are three factors:

- cost
- size
- power consumption

If none of these factors matter, get the most powerful chip - very fast, lots of memory etc. It'll be easier.

If any of these three factors is of any concern, then the most powerful chip will not meet your needs - it'll be too expensive, too bulky and will consume too much power. In this case, you need to do some work with datasheets to figure out what meets your constrains.

Don't dwell on architectures. There's not much difference here. Devil is in the details. But don't use things which are 15-20 years old. A lot of progress has been made lately.

[Luminax]

The trend with MCU these days is in the Peripherals. Even using one architecture, you'd often go down the rabbit hole choosing which ONE of the many selection from that particular architecture with different available peripherals and all sorts of wonderful stuffs.

Nowadays I mainly select ones that have at least :

1) At least a 10-bit ADC with 100ksps or better conversion rate
2) Internal adjustable oscillator (while allowing options for external oscillator)
3) Some sort of PWM control
4) Serial interface (I2C, SPI, USART)

Optionally USB is a great thing to have included, but going down that path is another rabbit hole altogether