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 

[technix]

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

Tell me about it... I never got around to a few projects percisely because I have no idea how to make USB work.

I have a few PIC16F1455 but never got around using them because exactly this...

[Luminax]

You might want to look at some of PIC's USB starter kit like the Low Pin Count dev board.
Downloading the PIC MLA library shows you what codes are available for which demo boards, and their codes are quite nice and clean and have the 'state-machine' type of programming style.

... I just turned this thread into a PIC thread did I not  sorry guys, carry on

[technix]

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.

How to convince Eclipse CDT that Apple-shipped LLVM/clang can handle the heat?

[technix]

You might want to look at some of PIC's USB starter kit like the Low Pin Count dev board.
Downloading the PIC MLA library shows you what codes are available for which demo boards, and their codes are quite nice and clean and have the 'state-machine' type of programming style.

I just have PIC16F1455 on breadboards.

... I just turned this thread into a PIC thread did I not  sorry guys, carry on

It's okay.

[TNorthover]

How to convince Eclipse CDT that Apple-shipped LLVM/clang can handle the heat?

I'm afraid I don't know. Most people that use those options write their own Makefiles; I've not encountered anyone trying to use Eclipse.

[Neganur]

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...

There is nothing suspicious about that post. Someone put effort into listing the benefits and capabilities of a platform, and I think it does contribute a whole lot more than other posts; screenshot from the working environment and all.

[Luminax]

You might want to look at some of PIC's USB starter kit like the Low Pin Count dev board.
Downloading the PIC MLA library shows you what codes are available for which demo boards, and their codes are quite nice and clean and have the 'state-machine' type of programming style.

I just have PIC16F1455 on breadboards.

... I just turned this thread into a PIC thread did I not  sorry guys, carry on

It's okay.

If you're willing to dig through pre-made code, I'd strongly suggest downloading Microchip's Library of Applications since they contain a lot of "header" codes for USB handler and the likes.
So far I've seen HID, CDC, MIDI and... a few others in there

[NorthGuy]

I just have PIC16F1455 on breadboards.

Depends on what you want.

You can use Microchip USB stack and you can get it up and running within few hours.

Or, if you want to study how USB works, you can read USB 2.0 specs, the PIC datasheet and write your own USB routines. This is, for sure, much longer road.

[splin]

Does anyone know how much FLASH space the free STM USB stack code takes up in an STM32F102? For some reason they don't seem to think it's worth mentioning in the specs or the user manual. I could try building it of course but finding the code to download on ST's website could take a while.

I sometimes wonder if ST's website administrators are fans of the horror film 'The Cube' where a group of people wake up in a maze of cube rooms which constantly rearrange themselves, presenting a fiendish challenge to the victims trying to work out how to escape...

[EDIT]:  I asked about code size as I have some STM32F102C4s which only have 16K bytes - it doesn't seem a lot to include a stack. However I see that there are other devices with USB periperals, including the PIC18F13K50 and ATmega8U2, which only have 8K of FLASH and 512 bytes of RAM. How much of that will be left after a USB stack?

[splin]

FWIW, as I happen to have Atmel visual studio 7 installed I tried building example 41 'an echo application by USB CDC interface' for a SAMD11 (16k Cortex M0+). It uses 11,700 bytes of code (71%) and 2792 bytes of RAM. (I can't for the life of me work out how to change compiler options to optimize for space - the 'help' doesn't seem to help; perhaps I'm too old for this... )

That's quite a lot, but I've no idea if this can be trimmed down significantly.

[NorthGuy]

However I see that there are other devices with USB periperals, including the PIC18F13K50 and ATmega8U2, which only have 8K of FLASH and 512 bytes of RAM. How much of that will be left after a USB stack?

It's hard to calculate precisely because it is spread around, but my code for PIC16F1454 is about 700 commands (give or take 100), which is approximately 10% of the available code memory.

[krho]

Does anyone know how much FLASH space the free STM USB stack code takes up in an STM32F102? For some reason they don't seem to think it's worth mentioning in the specs or the user manual. I could try building it of course but finding the code to download on ST's website could take a while.

I have a test project here for stm32f413 with MSD HAL stack and Os compiled project is 20640b Og is approximately 2000b more. There is a lot more code in there than just the USB MSD but as I've commented out the init code for that I trust the linker that it has thrown that out.

[hans]

Does anyone know how much FLASH space the free STM USB stack code takes up in an STM32F102? For some reason they don't seem to think it's worth mentioning in the specs or the user manual. I could try building it of course but finding the code to download on ST's website could take a while.

I sometimes wonder if ST's website administrators are fans of the horror film 'The Cube' where a group of people wake up in a maze of cube rooms which constantly rearrange themselves, presenting a fiendish challenge to the victims trying to work out how to escape...

[EDIT]:  I asked about code size as I have some STM32F102C4s which only have 16K bytes - it doesn't seem a lot to include a stack. However I see that there are other devices with USB periperals, including the PIC18F13K50 and ATmega8U2, which only have 8K of FLASH and 512 bytes of RAM. How much of that will be left after a USB stack?

For STM32F411 (with GCC set to compile for cortex m3 ISA), my USB soundcard project compiles to around 12.5k of code with space optimisations on. On -Og it is 14.5K.

On -Os, core USB modules is around 6K, USB audio device ~1K, startup + CMSIS around 2K, and application (with some floating point) 3.5K.

So 16K will be a squeeze. Perhaps if you can keep the USB driver code at -Os during development it is doable, but sounds to me like you want to buy 32K part for a development unit, and use the 16K on units you don't need debugging for.

[aandrew]

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.

Yeah, it's patent-free, a tiny core (for embedding into ASICs) and there is an enormous amount of old code out there that you can lift for your own projects. :-)

[aandrew]

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...

Dana is a well known and friendly admin from the Cypress PSoC forums. He (I think Dana is a he, please accept my apologies if I got this wrong) really believes in the product and his support is really quite good. I don't fault him on promoting the PSoC, although I do agree that some kind of disclaimer ("I might be biased, I work for Cypress") would be good.

Having said all that, I've made my feelings about the PSoCs available in other threads in this forum so I won't bother repeating it again here.

[splin]

It's hard to calculate precisely because it is spread around, but my code for PIC16F1454 is about 700 commands (give or take 100), which is approximately 10% of the available code memory.

That's impressive at just over 1Kbytes. Is it written in assembler? Someone on an MSP forum has reduced a TI MSP430 CD USB stack (in 'C') to 1.5K.

I have a test project here for stm32f413 with MSD HAL stack and Os compiled project is 20640b Og is approximately 2000b more. There is a lot more code in there than just the USB MSD but as I've commented out the init code for that I trust the linker that it has thrown that out.

Not so impressive! But I guess we aren't exactly comparing like for like.

For STM32F411 (with GCC set to compile for cortex m3 ISA), my USB soundcard project compiles to around 12.5k of code with space optimisations on. On -Og it is 14.5K.

On -Os, core USB modules is around 6K, USB audio device ~1K, startup + CMSIS around 2K, and application (with some floating point) 3.5K.

So 16K will be a squeeze. Perhaps if you can keep the USB driver code at -Os during development it is doable, but sounds to me like you want to buy 32K part for a development unit, and use the 16K on units you don't need debugging for.

14.5K is still an awful lot though compared to 1.5K. Again I guess it is a full featured implementation with robust error checking and handling etc. I had a closer look at the ATMEL SAMD11 example I compiled and the actual USB code is around 8000 bytes.

I also found an excellent ATMEL document, AVR4920 'ASF - USB Device Stack - Compliance and Performance Figures', which provides comprehensive performance information on their USB stack. It shows (see attached) code size of 6K bytes for a full speed CDC device on an ATxmega or an AT32UC3. I wish all manufacturers would supply similar information for their embedded firmware products.

I know Cortex code size can be a bit bigger than for some 8 or 16 bit processors but I'd like to think that 2 or 3K should be possible if 1 to 1.5K has been achieved on PICs and MSP430s.

And then there is the issue of USB id's. I believe that Microchip allow you to use one of theirs in your own PIC based USB product but do any others? ST? I know there are ways around having to pay $2k to get an official set of ids, but none of them are exactly ideal if you want to sell a product.

Apologies to the original poster if I have hijacked your thread, but you did post about MCUs with USB.

[Rasz]

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...

Dana is a well known and friendly admin from the Cypress PSoC forums

Wow, so It was a paid (employee on the clock) post after all

[NorthGuy]

That's impressive at just over 1Kbytes. Is it written in assembler? Someone on an MSP forum has reduced a TI MSP430 CD USB stack (in 'C') to 1.5K.

Yes, it is in assembler. But it wouldn't be much bigger with C. Most of the stuff is done by the PIC hardware. The USB code only needs to initiate transfers and parse requests on EP0. The biggest job is to serve descriptors during enumeration. It is HID, but CDC should be similar in size.

[technix]

It's hard to calculate precisely because it is spread around, but my code for PIC16F1454 is about 700 commands (give or take 100), which is approximately 10% of the available code memory.

That's impressive at just over 1Kbytes. Is it written in assembler? Someone on an MSP forum has reduced a TI MSP430 CD USB stack (in 'C') to 1.5K.

I have a test project here for stm32f413 with MSD HAL stack and Os compiled project is 20640b Og is approximately 2000b more. There is a lot more code in there than just the USB MSD but as I've commented out the init code for that I trust the linker that it has thrown that out.

Not so impressive! But I guess we aren't exactly comparing like for like.

For STM32F411 (with GCC set to compile for cortex m3 ISA), my USB soundcard project compiles to around 12.5k of code with space optimisations on. On -Og it is 14.5K.

On -Os, core USB modules is around 6K, USB audio device ~1K, startup + CMSIS around 2K, and application (with some floating point) 3.5K.

So 16K will be a squeeze. Perhaps if you can keep the USB driver code at -Os during development it is doable, but sounds to me like you want to buy 32K part for a development unit, and use the 16K on units you don't need debugging for.

14.5K is still an awful lot though compared to 1.5K. Again I guess it is a full featured implementation with robust error checking and handling etc. I had a closer look at the ATMEL SAMD11 example I compiled and the actual USB code is around 8000 bytes.

I also found an excellent ATMEL document, AVR4920 'ASF - USB Device Stack - Compliance and Performance Figures', which provides comprehensive performance information on their USB stack. It shows (see attached) code size of 6K bytes for a full speed CDC device on an ATxmega or an AT32UC3. I wish all manufacturers would supply similar information for their embedded firmware products.

I know Cortex code size can be a bit bigger than for some 8 or 16 bit processors but I'd like to think that 2 or 3K should be possible if 1 to 1.5K has been achieved on PICs and MSP430s.

And then there is the issue of USB id's. I believe that Microchip allow you to use one of theirs in your own PIC based USB product but do any others? ST? I know there are ways around having to pay $2k to get an official set of ids, but none of them are exactly ideal if you want to sell a product.

Apologies to the original poster if I have hijacked your thread, but you did post about MCUs with USB.

Will compiling with Cortex-M4F hard float help?

And can I use USB without ASF or HAL?

[splin]

Will compiling with Cortex-M4F hard float help?

I think the likelyhood that a USB stack uses any floating point is next to zero, so no. It is possible to take advantage of the larger resister set in the floating point unit in some circumstances but I don't know if the usual compilers can do this.

And can I use USB without ASF or HAL?

Of course you can write your own stack but that would be a lot of effort. I believe there is at least one open source USB stack project but I don't know anything about its status.

If you search around you should be able to find the source code for the USBASP atmel AVR programmer - I believe that implements USB on an atmega8 device that doesn't even have a USB peripheral. I don't think it is fully conformant with the USB specs, but it works well enough for its purpose.

[Neganur]

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...

Dana is a well known and friendly admin from the Cypress PSoC forums

Wow, so It was a paid (employee on the clock) post after all

you're jumping to conclusions imo and also, why is that relevant if the post was actually contributing to the OPs question (asking for mcu kits to play around with)?

[danadak]

@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...

I am the poster. I have used UPs since 72 and in recent years got tired of
doing designs with lots of analog crap around them. So I settled on PSOC
as the goto for most, not ALL designs. Its not the answer all, simply a very
good solution for many designs. With ARM M0 or M3 core plus all the other
stuff, plus the FPGA like fabric, its a home run in my mind.

Yes, I have a standard post, and do use copy and paste.



Regards, Dana.

[Rasz]

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...

Dana is a well known and friendly admin from the Cypress PSoC forums

Wow, so It was a paid (employee on the clock) post after all

you're jumping to conclusions imo and also, why is that relevant if the post was actually contributing to the OPs question (asking for mcu kits to play around with)?

its called disclosure. There is a difference between "this is the best chip I ever worked with" and "my employer makes the best chips"

I am the poster. I have used ....
Yes, I have a standard post, and do use copy and paste.

cool story, so are you employed or in any monetary contract with Cypress?
if answer is yes did it ever cross your mind to mention this in your copypasta?

[NorthGuy]

With ARM M0 or M3 core plus all the other stuff, plus the FPGA like fabric, its a home run in my mind.

or Zynq - https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html

Hardly can get anything better.

[technix]

With ARM M0 or M3 core plus all the other stuff, plus the FPGA like fabric, its a home run in my mind.

or Zynq - https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html

Hardly can get anything better.

Zynq is a bit too complicated for some embedded projects as it 1) does not support any easily hand solderable package, and 2) runs full Linux which is not necessary in most times.

[NorthGuy]

Zynq is a bit too complicated for some embedded projects as it 1) does not support any easily hand solderable package, and 2) runs full Linux which is not necessary in most times.

If someone can afford Zynq they certainly can afford a reflow oven, which makes it easier than hand soldering.

You don't have to run Linux if you don't want to.

[jmsigler]

With ARM M0 or M3 core plus all the other stuff, plus the FPGA like fabric, its a home run in my mind.

or Zynq - https://www.xilinx.com/products/silicon-devices/soc/zynq-7000.html

Hardly can get anything better.

Could also look at Microsemi's SmartFusion2 chipset which has an m3 and fpga fabric. I've built a board with an older qfp smartfusion chip and it wasn't too bad.

[tszaboo]

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...

This forum has a bunch of PSoC fanboys. Anytime you ask, why they like it: Because it has a bunch of gimmicky features, nobody asked for, and you need to look for the application to use it. I talked with a junior support engineer at Cypress. He told me he is new at the company, and he has no idea what all these features can be used for.

[AndyC_772]

I'm not entirely sure that 'junior support engineer is clueless' really qualifies as news, though, does it? 

I looked at PSoC last year but was disappointed at the lack of flexibility in analogue routing, and the poor performance of the digital logic. It's no substitute at all for a proper CPU + FPGA.

[tszaboo]

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...

This forum has a bunch of PSoC fanboys. Anytime you ask, why they like it: Because it has a bunch of gimmicky features, nobody asked for, and you need to look for the application to use it. I talked with a junior support engineer at Cypress. He told me he is new at the company, and he has no idea what all these features can be used for.

They are quite useful. You can save BOM cost and size by using integrated features such as comparators, opamps, and UDBs for simple but obscure serial protocol phy.
The random routable ADC allows for arbitrary ADC sequence, which is a feature not many MCUs have.
Their touch sense is top notch among "free" integrated cap sense in MCUs. So does their analog peripherals like opamps.
PSoC is easy to use with good software library, easy to use as Arduino, while still being high quality and versatility. Compiler and IDE is also good and free, with low cost kits and debuggers.
And finally, PSoC is cheap at low quantity. Their marketing strategy is not to sell 1 off at ridiculously high price and offer huge discount at 100k pcs.

They are amongst the most expensive microcontrollers you can buy. The built in opamps have the analog performance of a 7 cent LM358. I think this tells it all: The cheapest PSoC with cortex M3 costs twice as much, as a regular Cortex M3 from the same company.

[westfw]

Quote>[PSoC is] no substitute at all for a proper CPU + FPGA.Any microcontroller is no substitute for a $1000 Xeon CPU augmented by a $1000 FPGA.
Fortunately, not all problems require that, and sometimes a slow microcontroller with some configurable logic is just the thing...

I've followed PSoC for quite a while, and I was pretty pleased with the direction taken in PSoC 4 and 5 - adding general purpose "standard" microcontroller peripherals that DON'T require the configurable logic to do things.  I'm pretty sure that there are a lot of "mostly SW" engineers that are really happy not to need to build a UART before they can do serial IO.

[NorthGuy]

It's analog routing is quite flexible compared to most MCUs, though that's only limited to 1 bank of IO. However, try to find a cheap MCU with arbitrary ADC sequencing support, mixed SE/diff ADC and comparator?

Have you looked at Microchip PICs lately? ADCs, DACs, comparators, op-amps which can be internally interconnected. CPU independent logic cells which can trigger ADCs, timers etc. For a fraction of the cost ...

[danadak]

@Rasz

Wow, so It was a paid (employee on the clock) post after all

How did you jump to that conclusion ?


The PSOC Cypress forums had a store where a poster could earn points and redeem. That store ended long before I stopped posting over there. But I did redeem some points 7 years ago for a GPS and fish finders before the store came to an end. No, I was not employed, contractor, or otherwise at Cypress. I was, prior to all the posts at Cypress and eevblog  an FAE at Future, as such responsible for many CPU lines, Cypress one of them. Also Freescale, Zilog, uChip, forgot the rest.


@NANDBlog

They are amongst the most expensive microcontrollers you can buy. The built in opamps have the analog performance of a 7 cent LM358. I think this tells it all: The cheapest PSoC with cortex M3 costs twice as much, as a regular Cortex M3 from the same company.

Not exactly. the parts range from < $ 1 to < $ 20, in unit prices. Yes, OpAmps  outperform LM258, but not by much. Cypress does not offer bare M3, just PSOC M3. The high end parts have multiple A/D, DAC, DSP, Onboard Ref, route fabric, MSI like logic predefined components, or roll your own, and a ton of other HW.

This forum has a bunch of PSoC fanboys. Anytime you ask, why they like it: Because it has a bunch of gimmicky features, nobody asked for, and you need to look for the application to use it. I talked with a junior support engineer at Cypress. He told me he is new at the company, and he has no idea what all these features can be used for.

Maybe talk to experienced FAEs and users would be a better idea. Gimmicky, if I need a vanilla OpAmp, PGA, TIA, Comparator, nice to have it onboard. If I need a filter, eg. DSP, nice that its there. Or spend another $ 4-$6 to add it externally. If I need some specific msi like logic, or my own LUT, Verilog, nice to have it onboard. If I need a 20 bit A/D ……its there……….


No one should think ANY CPU/Vendor is perfect, such is true of PSOC. But many designs fit quite nicely into their architecture. Read their annual report on shipments, quite illuminating.


Regards, Dana.

[tszaboo]

Not exactly. the parts range from < $ 1 to < $ 20, in unit prices. Yes, OpAmps  outperform LM258, but not by much. Cypress does not offer bare M3, just PSOC M3. The high end parts have multiple A/D, DAC, DSP, Onboard Ref, route fabric, MSI like logic predefined components, or roll your own, and a ton of other HW.

I have to repeat myself. Digikey. I filter for Cortex M3, Cypress. Cheapest is MB9BF121JWQN-G-JNE2 which is a FM3 microcontroller, from cypress, cost is 3.36 dollars for single quantity, 1.7 in high quantity. Cheapest PSoC is CY8C5467LTI-LP003 7.53 dollars in single quantity, 4 in thousands. Both of them is made by Cypress. Competetive pricing? Hell no.
Yes, there are cheaper ones. Cortex M0+ usually. For people, who think having a grand total of 3 communication interfaces is enough.
I am just wondering, if PSoC fanboys lost all connection with reality, or they are getting payed to do these posts.

[^_^]

You get what you pay for.
If you want configurable architecture, don't want to put external components, then why not?
Also, Cypress surely has a great way to approach the newcomers compared to other vendors.

[westfw]

Psoc5, with CM3, is relatively expensive.   The psoc4, with cm0, is significantly cheaper (also having less programmable logic.  Down to "none", IIRC.)

[alexanderbrevig]

These discussions are always good fun so I'll chip in with my point of view.
PSoC is fun and a good way to get your feet wet with programmable logic. I know opinions differ, but I for one love their IDE, their framework and their general attitude toward newbs.  Great online community!
Their approach to BLE is the quickest way I've seen, and I wish I started with them instead of Nordic back when I was trying to figure out what the f*ck a GATT is. Also, it's fun to be able to make a matrix keypad driver that takes up no CPU time. Niche needs, but the cost is not too high for projects where you want to cut down on PCB spins due to silly mistakes or erratas.

Nordic Semiconductor is the way to go for mass production BLE. I found it an up-hill battle the first, second and third time. But eventually you learn to spend some time getting everything set up right. I've ended up using gcc and their CLI tools from linux. It's the way to go for NS I think. Good online community.

STM is fine, I've got to know the F103 quite well now and it's been an up hill battle. I would definitly point the next guy toward an F4. They have serious silicon bugs with some of their chips and one in the F103 bit me bad They are higly configurable/mappable but also quite complex and their HALs often works but are bloated and changing so much the arduino way of finding someone who has already done it is often a no go. I got an unofficial devboard and basically had to reimplement every demo for every peripheral I wanted to use. The good thing; they fix bugs and add workarounds in a good tempo. A very fractioned, weird community. I'd rather ask on here if I have questions.

PIC32MZ is my new for-hobby curiosity. So far I'm really pleased with most everything. Their HAL seems good, and the online community seems good. Seems to be an excellent peripheral-to-peripheral piping machine, and the MZ seems to be capable to do some dsp style things too. At least for my small FIR tests

Texas Instruments is my go-to for radio experimentation. They have excellent tools, and getting from 0 to a custom sub-gig protocol that actually works and is demo-able takes less than a day. Solid library of example code, nice and relatively light weight HALs. All in all I like them (just stay away from the older RF chips, they should be deprecated if you ask me).

NXP/ Freescale I'll probably not touch again until I have to. It was no fun. Nothing about using it was fun, for me at least.

What more? I still bring out my wiring/arduino board if I just want to do something as quick as possible. Like setting up some I2C test slave or the like.
I do think having some kind of LUA/JS/MicroPython kit in the bag is good to. They are fun and makes for good demonstrations (i.e talks at your work or whatever).
Lastly, some Linux device is nice too. Get one if only to say you know your way around it. The day might come when you need to impress someone with a face tracking gizmo, just don't tell them it's 40 lines of python straight off of the internet

This post turned out a lot longer than I intended, but there you go.
I tend to solve relatively small problems for clients who "have an idea", this has led me to implement little things with a lot of different platforms. None of them is the definitive best - and even if any were I'd recommend anyone to pick up more than one family and more than one manufacturer.
Those clients that "has an idea", some times even has the idea that you must use this or that family or that special manufacturer. Never a good day when the Idea Guy tries to also be the EE. 

[danadak]

@NANDBlog

I have to repeat myself. Digikey. I filter for Cortex M3, Cypress. Cheapest is MB9BF121JWQN-G-JNE2 which is a FM3 microcontroller, from cypress, cost is 3.36 dollars for single quantity, 1.7 in high quantity. Cheapest PSoC is CY8C5467LTI-LP003 7.53 dollars in single quantity, 4 in thousands. Both of them is made by Cypress. Competetive pricing? Hell no.
Yes, there are cheaper ones. Cortex M0+ usually. For people, who think having a grand total of 3 communication interfaces is enough.
I am just wondering, if PSoC fanboys lost all connection with reality, or they are getting payed to do these posts.

I stand corrected. Forgot about the buyout by Cypress of > Spansion > Fujitsu FM3 family, yes the Fuji parts are cheaper.

The following are selector guide/prices from Cypress, show PSOC 5LP parts < $4, 1KU.


http://www.cypress.com/PSoCPSG


Of course we have not discussed whats on the part of interest, memory sizes, and all the rest.

Not getting paid to post,  are you ?

Price of course to user is total system cost. Of course those are not the only considerations, and
we are ignoring OEM negotiated pricing quite different than public price lists. Non Cypress fanboys
should compare all attributes of design requirements.

PSOC is NOT the answer to all designs. Just many.



Regards, Dana.

[technix]

Will compiling with Cortex-M4F hard float help?

I think the likelyhood that a USB stack uses any floating point is next to zero, so no. It is possible to take advantage of the larger resister set in the floating point unit in some circumstances but I don't know if the usual compilers can do this.

At least using GCC and LLVM/clang, with -O2 or higher optimization level the compiler will perform automatic vectorization and make use of the FPU registers that way. This happens even in some library routines which receives optimized versions, and that includes memset and memcpy, which I make use of in my C startup code. This forces me to switch on the FPU the first instruction into the reset vector, just so the heavily optimized memcpy and memset would work.

[VEGETA]

Well, for me I like Arduino boards for doing anything fast and easy. However, being a PIC fan I have the all famous obsolete PIC16F877A which I use often. I don't recommend getting a dev board for PIC since it is very easy to use the chip itself and a good learning material.

However, I came to see some good boards such as GR-SAKURA and GR-PEACH from Renesas, but it is not popular and don't have support like other famous boards. In my opinion, Renesas wants to get into beginner/hobbyist market using their powerful AZ series of MPUs but their methods are wrong. They don't get the idea that it is useless for a beginner board if it is hard to get, pricey, and has poor support and few examples.

Other than that, I wanted to get STM discovery boards since they are cheap and a good start in ARM MCUs after spending time using PICs and Arduinos.

[technix]

Well, for me I like Arduino boards for doing anything fast and easy. However, being a PIC fan I have the all famous obsolete PIC16F877A which I use often. I don't recommend getting a dev board for PIC since it is very easy to use the chip itself and a good learning material.

However, I came to see some good boards such as GR-SAKURA and GR-PEACH from Renesas, but it is not popular and don't have support like other famous boards. In my opinion, Renesas wants to get into beginner/hobbyist market using their powerful AZ series of MPUs but their methods are wrong. They don't get the idea that it is useless for a beginner board if it is hard to get, pricey, and has poor support and few examples.

Other than that, I wanted to get STM discovery boards since they are cheap and a good start in ARM MCUs after spending time using PICs and Arduinos.

I have always been breadboard guy... STM32 on breadboard adapters too. Although I also had a few STM32-based Arduino-compatibles.

[Luminax]

Well, for me I like Arduino boards for doing anything fast and easy. However, being a PIC fan I have the all famous obsolete PIC16F877A which I use often. I don't recommend getting a dev board for PIC since it is very easy to use the chip itself and a good learning material.

However, I came to see some good boards such as GR-SAKURA and GR-PEACH from Renesas, but it is not popular and don't have support like other famous boards. In my opinion, Renesas wants to get into beginner/hobbyist market using their powerful AZ series of MPUs but their methods are wrong. They don't get the idea that it is useless for a beginner board if it is hard to get, pricey, and has poor support and few examples.

Other than that, I wanted to get STM discovery boards since they are cheap and a good start in ARM MCUs after spending time using PICs and Arduinos.

The biggest point in getting a dev-board is not to actually set you up for starting into the chip, it's more to do with the code examples that usually comes prepackaged with the dev-board.
Unfortunately for me... element14 seems to stock 'old version' and buying from microchip direct is a bit putting-off with the high shipping cost... so I sometimes ended up with a dev-board that's designed and deployed with codes based on very very very old sets of environment (in the case of PIC, old version of MPLAB and old coding-style/old MLAs)

[VEGETA]

Luminax

Yes you are right, but I don't really know a good and widespread PIC board unlike Arduino boards. Thus I try to use it myself for more learning.

[Luminax]

I believe their mainstay is Explorer 16 Board. If you look into Microchip MLA, there's Explorer 16, PIC18 Plug-In-Modules(PIM) and starter kits, etc. Buying a starter kit/demo board/development board to match a readily available library of application is one way of going about it.

Come to think of it... maybe I should make some demo board... hmmmmm..... profit $$ ?? 

[technix]

I believe their mainstay is Explorer 16 Board. If you look into Microchip MLA, there's Explorer 16, PIC18 Plug-In-Modules(PIM) and starter kits, etc. Buying a starter kit/demo board/development board to match a readily available library of application is one way of going about it.

Come to think of it... maybe I should make some demo board... hmmmmm..... profit $$ ?? 

Might as well be. I will look into those too.

[ptricks]

One comment about the 8051.
Yes it is old, really old, but.....
The core of the 8051 is still used in lots of new products mainly because it is so well understood and easy to implement, it is a true controller not so much a processor as the newer chips like pic, avr . Even the space shuttles used them for control.
The popular ESP8266 wifi module uses an 8051 core for the controller .
Learning the 8051 is easy and I wouldn't toss it aside as it is a very capable little chip that doesn't require much to use. I like the RX variety that have built in serial bootloaders, I think they were made by philips.

[TJ232]

The popular ESP8266 wifi module uses an 8051 core for the controller .

Isn't it a Tensilica LX106?

Yes, it is a 32-bit RISC CPU: Tensilica Xtensa L106 running at 80 MHz.