Moving into 32-bit MCU

[MAntunes]

Hi guys!
I've been using the PIC24FV16KM202 with the Microstick dev-board for all my school and personal projects for a while, but I would like to learn something new and move to a 32-bit MCU.

The natural flow of thing would be to move on to a PIC32, but I would like to have your opinion on this.

I've been searching for a while and what I would like is:
 - ease of setup/programming;
 - relatively cheap dev-board (I don't care about Arduino headers or similar);
 - the more peripherals the better, and easy to use.

I do mostly control stuff.

I've been searching and came across a lot of brands/series:
 - STM32
 - PIC32MX
 - Atmel SAM
 - NXP LPC

Which do you think will be the best the best bet? What are the pros and cons of each one?

Thank you!

[ebclr]

Wanna the most flexible device on 32 bit?

http://www.cypress.com/documentation/development-kitsboards/cy8ckit-043-psoc-4-m-series-prototyping-kit

https://www.youtube.com/user/CypressSemi/videos

[NorthGuy]

Your Microstick may support some of the small PIC32 as well. Look at the docs.

If you program in C, it won't be much different. 32-bit MCUs typically require more setup, but the compiler/IDE will absorb most of it.

[MAntunes]

Your Microstick may support some of the small PIC32 as well. Look at the docs.

If you program in C, it won't be much different. 32-bit MCUs typically require more setup, but the compiler/IDE will absorb most of it.

Unfortunatly not, my Microstick is this one: http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM240013-2
So I'd have to get another dev-board like the Microstick II.
And yes, I program in C.

Wanna the most flexible device on 32 bit?

http://www.cypress.com/documentation/development-kitsboards/cy8ckit-043-psoc-4-m-series-prototyping-kit

https://www.youtube.com/user/CypressSemi/videos

I thought about PSoC also. But would it be the best bet to learn about MCUs and their peripherals?
Their IDE, being mostly graphical, seems to make everything too simple (?). And if I needed to work with another MCU, at work/school, I would have to learn everything again.
That's only my opinion and I may be wrong.

Also, I'd like to know if there are any good tutorials/books about these MCUs (the ones I mentioned in my first post).

[timb]

Your Microstick may support some of the small PIC32 as well. Look at the docs.

If you program in C, it won't be much different. 32-bit MCUs typically require more setup, but the compiler/IDE will absorb most of it.

Unfortunatly not, my Microstick is this one: http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DM240013-2
So I'd have to get another dev-board like the Microstick II.
And yes, I program in C.

Wanna the most flexible device on 32 bit?

http://www.cypress.com/documentation/development-kitsboards/cy8ckit-043-psoc-4-m-series-prototyping-kit

https://www.youtube.com/user/CypressSemi/videos

I thought about PSoC also. But would it be the best bet to learn about MCUs and their peripherals?
Their IDE, being mostly graphical, seems to make everything too simple (?). And if I needed to work with another MCU, at work/school, I would have to learn everything again.
That's only my opinion and I may be wrong.

Also, I'd like to know if there are any good tutorials/books about these MCUs (the ones I mentioned in my first post).

You setup the logic and analog peripherals in a graphical manner, but you still have to actually write code and program the ARM portion. That's the same as any other ARM MCU.

You don't even need to use Cypress' software to do that, if you don't want to; you can download any ARM toolchain and IDE you want, in fact PSoC Creator is using gcc-arm-eabi-none as the backend compiler, which is pretty much the standard. Also, their IDE is pretty good in and of itself.

Basically the "Schematic Editor" portion of PSoC Creator is used to setup and wire together the flexible analog (op-amps, ADCs, DACs, filters, etc.), logic (and/or/xor/not/flip-flops, etc.), communication blocks (SPI, UART, I2C, etc.), clocks and I/O pins.

Once everything is wired together you write code, program and debug in the same software, outside of the Schematic Editor mode. So in that regard it's just like any other IDE and compiler.

So yes, setting up and wiring together the peripherals is easier than most MCUs, but code is code.

Also, every MCU has a different set of peripherals anyway. A Cortex M4 part from ST will have a completely different memory map and set of registers than one from TI with the same CM4 core. (TI, NXP, Cypress, ST, etc. all buy the same IP from ARM, that is the MCU core itself, then they add their own set of peripherals; that's what makes each part from each vendor unique.)

So you'll always have to learn new stuff when moving between vendors; that knowledge is never portable.

[stj]

look at the ST NUCLEO stuff = specially the 144 series.

you can get a 200MHz+ F746 for about 25Euro's with 144pins and ethernet and USB-OTG complete with a USB ST-LINK programmer on the board.
i dont think that can be bettered!
http://www.carminenoviello.com/2016/01/22/getting-started-stm32-nucleo-f746zg/
 

[MAntunes]

look at the ST NUCLEO stuff = specially the 144 series.

you can get a 200MHz+ F746 for about 25Euro's with 144pins and ethernet and USB-OTG complete with a USB ST-LINK programmer on the board.
i dont think that can be bettered!
http://www.carminenoviello.com/2016/01/22/getting-started-stm32-nucleo-f746zg/
 

Yes, I've looked at the STM Nucleo boards, especially at the smaller ones, that you can put on a breadboard. I don't really need the power of a Cortex M7, a M0+ would really be enough for what I do right now.
But STM has me somewhat devided. The parts are cheap (so are the dev-boards) but for what I have read, they are less straight forward to program.

Does anyone know how does STM compare to NXP or Atmel SAM in terms of ease of programming?

You setup the logic and analog peripherals in a graphical manner, but you still have to actually write code and program the ARM portion. That's the same as any other ARM MCU.

You don't even need to use Cypress' software to do that, if you don't want to; you can download any ARM toolchain and IDE you want, in fact PSoC Creator is using gcc-arm-eabi-none as the backend compiler, which is pretty much the standard. Also, their IDE is pretty good in and of itself.

Basically the "Schematic Editor" portion of PSoC Creator is used to setup and wire together the flexible analog (op-amps, ADCs, DACs, filters, etc.), logic (and/or/xor/not/flip-flops, etc.), communication blocks (SPI, UART, I2C, etc.), clocks and I/O pins.

Once everything is wired together you write code, program and debug in the same software, outside of the Schematic Editor mode. So in that regard it's just like any other IDE and compiler.

So yes, setting up and wiring together the peripherals is easier than most MCUs, but code is code.

Also, every MCU has a different set of peripherals anyway. A Cortex M4 part from ST will have a completely different memory map and set of registers than one from TI with the same CM4 core. (TI, NXP, Cypress, ST, etc. all buy the same IP from ARM, that is the MCU core itself, then they add their own set of peripherals; that's what makes each part from each vendor unique.)

So you'll always have to learn new stuff when moving between vendors; that knowledge is never portable.

OK, I think I understand you.
So what would you recomend to a "beginner"?

[stj]

when you say "ease of programming", do you mean writing the code, or uploading to the device?

http://electronut.in/stm32-start/

[MAntunes]

when you say "ease of programming", do you mean writing the code, or uploading to the device?

http://electronut.in/stm32-start/

Actually both, but mainly writing the code.
When I search for STM32 programing it all seems very confusing due to all the aproaches you have (Standard Peripheral Library, CubeMX, etc).

[timb]

look at the ST NUCLEO stuff = specially the 144 series.

you can get a 200MHz+ F746 for about 25Euro's with 144pins and ethernet and USB-OTG complete with a USB ST-LINK programmer on the board.
i dont think that can be bettered!
http://www.carminenoviello.com/2016/01/22/getting-started-stm32-nucleo-f746zg/
 

Yes, I've looked at the STM Nucleo boards, especially at the smaller ones, that you can put on a breadboard. I don't really need the power of a Cortex M7, a M0+ would really be enough for what I do right now.
But STM has me somewhat devided. The parts are cheap (so are the dev-boards) but for what I have read, they are less straight forward to program.

Does anyone know how does STM compare to NXP or Atmel SAM in terms of ease of programming?

You setup the logic and analog peripherals in a graphical manner, but you still have to actually write code and program the ARM portion. That's the same as any other ARM MCU.

You don't even need to use Cypress' software to do that, if you don't want to; you can download any ARM toolchain and IDE you want, in fact PSoC Creator is using gcc-arm-eabi-none as the backend compiler, which is pretty much the standard. Also, their IDE is pretty good in and of itself.

Basically the "Schematic Editor" portion of PSoC Creator is used to setup and wire together the flexible analog (op-amps, ADCs, DACs, filters, etc.), logic (and/or/xor/not/flip-flops, etc.), communication blocks (SPI, UART, I2C, etc.), clocks and I/O pins.

Once everything is wired together you write code, program and debug in the same software, outside of the Schematic Editor mode. So in that regard it's just like any other IDE and compiler.

So yes, setting up and wiring together the peripherals is easier than most MCUs, but code is code.

Also, every MCU has a different set of peripherals anyway. A Cortex M4 part from ST will have a completely different memory map and set of registers than one from TI with the same CM4 core. (TI, NXP, Cypress, ST, etc. all buy the same IP from ARM, that is the MCU core itself, then they add their own set of peripherals; that's what makes each part from each vendor unique.)

So you'll always have to learn new stuff when moving between vendors; that knowledge is never portable.

OK, I think I understand you.
So what would you recomend to a "beginner"?

The PSoC is a good place to start for any skill level I think. Their driver library is very easy to use and all the components have full documentation (on PDF no less) showing you what all the code functions do along with how to setup the components themselves in the schematic view.

I'd recommend picking up the $10 PSoC 5LP kit to start with. It's their high end chip, which can plug right into a breadboard and includes a little USB programming dongle. It might just be the best deal going right now, in terms of dev kits.

I can also recommend TI's LaunchPad line of boards as a very good value; their hardware is very easy to use, too. Look at the Tiva C LaunchPad if you want speed (it's a Cortex-M4) and the MSP432 for low power (it's a CM0).

[Syntax_Error]

Check these out:

https://www.youtube.com/playlist?list=PLPW8O6W-1chwyTzI3BHwBLbGQoPFxPAPM

Videos use the TI Stellaris/TivaC Launch Pad board with ARM Cortex M4F. The videos are very informative.

[daflory]

If you're already using MPLABX and the PIC24, then the PIC32 would be the easiest. You already have the tools and know how to use them; at most you'd just need to download the PIC32 compiler.
I have not found the PIC32 to be harder to get started with (at the blinking LED level) than the other PIC's. Of course the PIC32 has tons of complex features but learning to use those is not obligatory and is just a matter of studying the data sheets and programming guide.

Microchip has a nice selection of inexpensive PIC32 dev boards on their MicrochipDirect online store. If you are a student with an .edu email you can get 25% off last time I checked.

[MAntunes]

Check these out:

https://www.youtube.com/playlist?list=PLPW8O6W-1chwyTzI3BHwBLbGQoPFxPAPM

Videos use the TI Stellaris/TivaC Launch Pad board with ARM Cortex M4F. The videos are very informative.

Thank you very much. Will give them a look!

The PSoC is a good place to start for any skill level I think. Their driver library is very easy to use and all the components have full documentation (on PDF no less) showing you what all the code functions do along with how to setup the components themselves in the schematic view.

I'd recommend picking up the $10 PSoC 5LP kit to start with. It's their high end chip, which can plug right into a breadboard and includes a little USB programming dongle. It might just be the best deal going right now, in terms of dev kits.

I can also recommend TI's LaunchPad line of boards as a very good value; their hardware is very easy to use, too. Look at the Tiva C LaunchPad if you want speed (it's a Cortex-M4) and the MSP432 for low power (it's a CM0).

Thank you very much! Will give that PSoC board a look! It certainly looks cheap for what it offers!

If you're already using MPLABX and the PIC24, then the PIC32 would be the easiest. You already have the tools and know how to use them; at most you'd just need to download the PIC32 compiler.
I have not found the PIC32 to be harder to get started with (at the blinking LED level) than the other PIC's. Of course the PIC32 has tons of complex features but learning to use those is not obligatory and is just a matter of studying the data sheets and programming guide.

Microchip has a nice selection of inexpensive PIC32 dev boards on their MicrochipDirect online store. If you are a student with an .edu email you can get 25% off last time I checked.

Thank you for your opinion! I have to search a bit about the several PIC32 series (MX, MZ, MM, MK).

Any other opinion is more than welcome.

[Gibson486]

Lots of the info you find on ST is old info, so be careful what you read. With cubemx, it is actually not a horrible platform for a beginner. You still need to dig deep (for example, getting PWM out to work out the box is not that straight forward and they have the worst I2C examples I have ever seen). No matter which platform you choose, you are going to hit a wall at some point and you will need help. That is just how it is.

The one thing I will say is that everyone is pushing towards a HAL and trying to ditch the standard libs. That is sort of the trend at the moment. For example, ST has ditched the standard lib and now has a low level lib in their place, which is essentially just the standard lib rewritten in some cases, but they still want you to use the HAL. Go figure. 

[stj]

quick question:
what programming language do you use?

[Gibson486]

C

[NorthGuy]

Thank you for your opinion! I have to search a bit about the several PIC32 series (MX, MZ, MM, MK).

MX is, sort of, a base model. They have a little bit older MK-4 core and there's a big variety - different sizes and different periphery specializing at USB, Ethernet, CAN etc.

MZ is a performance chip. Can run at 250 MHz. It has FPU, DSP and core which can use MicroMips. But, IMHO, the CPU runs faster than periphery can handle. It still has very nice performance features such as 3 MHz ADCs, high speed USB etc.

MM is more like PIC16 with 32-bit MicroMips core. The most practical one unless you want lots of memory (such as for Graphics) or speed.

MK is very new, just released. I haven't seen it yet. But it has MicroMips and DSP, double USB, and I think the set of periphery is better than in MX.

[suicidaleggroll]

MSP432 is a decent choice if you don't need hundreds of MHz or USB.  The launchpad is cheap, TI provides examples showing how to use basically all of its peripherals, and it can be programmed using open source tools (gcc, make, etc.) on Mac, Linux, or Windows.  No IDEs or special programming environments necessary.

[carljrb]

and the MSP432 for low power (it's a CM0).

The MSP432 is actually a Cortex M4F part, just like the Tiva C. It's a low power oriented part, like the classic MSP430 series. Whereas Tiva is the high performance, "full featured" option (higher clock speeds, more memory, peripherals like USB OTG, CAN, etc). There's a very limited selection of MSP432 MCUs (2 models total), whereas digikey lists nearly 300 different TM4C parts.

The price difference between both dev boards (MSP-EXP432P401R and EK-TM4C123GXL) is pennies, so one might as well pick the better suited part. Otherwise, it's the same dev tools (free as in beer CCS or whatever you prefer), good libs (MSPWare or TivaWare), same decent RTOS (TI-RTOS or many 3rd party options), etc. It really comes down to low power vs performance/features.

Edit: if you can afford the $30, the EK-TM4C1294XL is a very nice board, especially after soldering the CLP headers on the side. The NUCLEO-F767ZI from ST Micro looks quite nice too (about $5 more but for a Cortex M7 part) but I didn't get to try it.

[technix]

MZ is a performance chip. Can run at 250 MHz. It has FPU, DSP and core which can use MicroMips. But, IMHO, the CPU runs faster than periphery can handle. It still has very nice performance features such as 3 MHz ADCs, high speed USB etc.

PIC32MZ even got a MMU onboard and can run full-blown Linux. It is more likely that it would be smarter to use PIC32MZ as a MCU, couple it with some PSRAM and SPI NOR Flash, load U-Boot into the Flash (Microchip should default to this) and launch a Linux kernel from there.

[JPortici]

All those multi 100 mhz chip runs much faster than the peripherals, the high speed is just there to crunch numbers.
Re: new parts It's been about a year but "soon" 32MZ DA with display controller should come out. that is going to be interesting. Anyway, page is up and everything. still no datasheet
Also, there is the pic32wk (which is inside microchip's wifi modules) you can find a datasheet but no product page

MK is for industrial stuff (which is great!!) even though i could see myself use one for our automotive modules (4x CAN and a crapton of timers, IC and PWM, which our current dspics of choice lacks)
in this case i am thankful that the core speed is that higher than the peripherals so that everything can be in order before the next operation

Sadly, no high speed (sub ns resolution) pwm like in one of the aforementioned dspic (this is an if-only moment, just like if only the mx had 12 bit adc)
datasheet is there http://www.microchip.com/design-centers/32-bit/architecture/pic32mk-family
yeah, seems like the peripherals are better,
 pic24 : pic32mx = dspic : pic32mz/mk

Keep in mind that these high speed mcus also have caches, which may give unexpected results in first projects.
then i suggest you set up your projects + clock tree with harmony so that you have the startup code ready and then give it the middle finger and access the peripherals directly if you can
this at least is what i'm doing, because i'm not expert enough in pic32 to write my own startup code yet (i've only played with them so far, nothing for work)

unfortunately these new cores are very pricey, i don't know how much it's worth it to use them instead of arm counterparts
though arms with all those peripherals, M4F/M7 core are not being sold for peanuts either

[technix]

All those multi 100 mhz chip runs much faster than the peripherals, the high speed is just there to crunch numbers.
Re: new parts It's been about a year but "soon" 32MZ DA with display controller should come out. that is going to be interesting. Anyway, page is up and everything. still no datasheet
Also, there is the pic32wk (which is inside microchip's wifi modules) you can find a datasheet but no product page

MK is for industrial stuff (which is great!!) even though i could see myself use one for our automotive modules (4x CAN and a crapton of timers, IC and PWM, which our current dspics of choice lacks)
in this case i am thankful that the core speed is that higher than the peripherals so that everything can be in order before the next operation

Sadly, no high speed (sub ns resolution) pwm like in one of the aforementioned dspic (this is an if-only moment, just like if only the mx had 12 bit adc)
datasheet is there http://www.microchip.com/design-centers/32-bit/architecture/pic32mk-family
yeah, seems like the peripherals are better,
 pic24 : pic32mx = dspic : pic32mz/mk

Keep in mind that these high speed mcus also have caches, which may give unexpected results in first projects.
then i suggest you set up your projects + clock tree with harmony so that you have the startup code ready and then give it the middle finger and access the peripherals directly if you can
this at least is what i'm doing, because i'm not expert enough in pic32 to write my own startup code yet (i've only played with them so far, nothing for work)

unfortunately these new cores are very pricey, i don't know how much it's worth it to use them instead of arm counterparts
though arms with all those peripherals, M4F/M7 core are not being sold for peanuts either

I really would rather see a SDRAM and NAND controller on PIC32MZ DA EBI along with the LCD controller. With LCD controller (and thus a framebuffer) it makes so much more sense to run Linux on this thing. Or at least a PIC32MZ DA MCM chip that connects the SDRAM and NAND controller internally to a SDRAM and a MLC NAND dice (and what was the EBI pins only capable of functioning as LCD interface.) If such an MCM chip can be priced within $5 it can give Raspberry Pi 0 a run for its money.

[MAntunes]

Sorry for answering so late.
So, I've decided to go for PIC32...
Just have to choose the line. All of them have curiosity boards except for MK...
Which one would you go for?

[Sal Ammoniac]

Sorry for answering so late.
So, I've decided to go for PIC32...
Just have to choose the line. All of them have curiosity boards except for MK...
Which one would you go for?

MX. It's the most mature.

[ebclr]

Why not

Dual core 600 Mips , Wifi and Bluetooth embedded





https://www.exploreembedded.com/wiki/Overview_of_ESP32_features._What_do_they_practically_mean%3F

[danadak]

Cypress 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


An example of digital filter design, operating in background while rest of
PSOC doing other stuff






Dev board for $ 10

https://www.google.com/search?q=psoc+digital+filter+image&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwjnrsXU07rUAhVP9GMKHaH_CkkQ7AkIPA&biw=1366&bih=648#tbm=isch&q=psoc+image&imgrc=eguoTYfRItp2TM:

There is also a Pioneer board for $ 25 that has Arduino footprint to take expansion cards, PSOC 4.

Regards, Dana.

[technix]

Sheesh. The PSoC folks are reckless... There are a lot of other options out there folks, often cheaper or better documented and supported, PSoC isn't everything.

[NorthGuy]

I looked at the Cypress PSoC website, and seems like they're not that much different from PICs or other MCUs, except for terminology.

"Programmable Routing & Interconnect" instead of "Peripheral pin select"

"Programmable Digital Blocks" instead of "Periphery"

"Programmable Analog Blocks" instead of "Analog periphery"

"CPU Subsystem" instead of just CPU.

Of course, I couldn't go through all the details, but from a glance look, they're just MCUs with bunch of hype around.

Xilinx also have PSoCs, and Xilinx's "Programmable Routing & Interconnect" is something totally different. Perhaps, Cypress think that by using the same words they can promote their products better.

[Scrts]

MZ is a performance chip. Can run at 250 MHz. It has FPU, DSP and core which can use MicroMips. But, IMHO, the CPU runs faster than periphery can handle. It still has very nice performance features such as 3 MHz ADCs, high speed USB etc.

PIC32MZ even got a MMU onboard and can run full-blown Linux. It is more likely that it would be smarter to use PIC32MZ as a MCU, couple it with some PSRAM and SPI NOR Flash, load U-Boot into the Flash (Microchip should default to this) and launch a Linux kernel from there.

Have you done a blinker on such linux based system? Or SPI connections? Do you have examples?

Because I've tried linux on AT91 and it was a huge learning curve and pain to make it working. Bare metal was plug & play within hours. I did not have linux experience and for most of microcontroller applications - I don't want to learn it.

[Sal Ammoniac]

Why not

Because the ESP32 uses an obscure 32-bit MCU (the Xtensa LX6) with limited development support. The Nordic nRF52 is a much better choice. It also has built-in Bluetooth, but it's based on an industry standard ARM Cortex-M4 microcontroller.

[Howardlong]

Sorry for answering so late.
So, I've decided to go for PIC32...
Just have to choose the line. All of them have curiosity boards except for MK...
Which one would you go for?

MX. It's the most mature.

I agree, the MX. The PIC32MX1xx/2xx have a number of advantages, namely:

o Available in DIP28, easy to breadboard
o Doesn't need Harmony framework
o Will work on the 3.3v version of the Microstick you have
o Peripherals often similar to other PICs

(The PIC24FV16KM202 you're using now is a really handy chip, it's my favourite for running directly off Lithium cells, and it has some nice peripherals, particularly PWM.)

[MAntunes]

Thank you all.
I'm indeed looking at the Microstrick II, that supports PIC32MX, dsPIC33 and PIC24.
I'll look for some cheap new or used board.

Thank you!

[newbrain]

I looked at the Cypress PSoC website, and seems like they're not that much different from PICs or other MCUs, except for terminology.

I would not like to sing the praises of Cypress PSoCs too much (I am not their employee or an investor...and we have the resident PSoC expert, danadak), but the list above is a bit superficial, and maybe reading Chapter 7 and 8 of this document could help a better understanding.

"Programmable Routing & Interconnect" instead of "Peripheral pin select"

Not many MCUs have the complete freedom to assign any peripheral to any pin, though some do, granted.
But most of the ones I know have very limited possibility of internal peripheral interconnection (e.g. you can trigger an ADC from a timer, but rarely you can do the opposite...).
PSoC internal routing allows you complete freedom in arranging the "peripherals" (better: components).

"Programmable Digital Blocks" instead of "Periphery"

This, I think is the fundamental difference with any other MCU: a complete set of predefined peripherals is available (timers, PWM, I2C, SPI, ADCs and DACs etc. etc.) but one if free to define and design their own.
The internal fabric is similar to an FPGA, admittedly a very small one, and Verilog can be directly used, if desired.
In the graphical editor, all the usual logic (and analog) building blocks can be found: flip-flops, gates, registers, muxes, clocks etc.
In addition to those, higher level design is possible using state machines and direct programming of the UDBs (Universal Digital Blocks).
Some of the default peripherals are implemented in fixed function loginc, other in programmable logic and several in both according to the needed flexibility.

"Programmable Analog Blocks" instead of "Analog periphery"

Very much what said above holds: op amps, comparators, analogue muxes, DACs and ADCs, references can be freely interconnected and routed to any pin.

Of course, I couldn't go through all the details

I think that if you read through the chapter mentioned above, you can get a good grasp of how PSoCs differ from the usual MCUs: among the ones I've fiddled with (STM32Fx, NXP lpc43S67, ATmega and ATtiny, TI MSP432, I admit I have an addiction to cheap dev boards  ) I find it pretty unique.

The only gripe I have is that one is bound to their Windows IDE (for the HW schematic entry part, for the SW I mostly use VS Code), but at least is quite decent.

The APIs are simple and clear, and well documented.

Once again: I'm not on crusade to defend or advertise PSoCs, I just find them handy (and the PSoC5LP gum-stick dev board is really cheap  ) and it is easy to come up with mixed HW/SW designs (at least for simple needs) using close to zero external components.

[NorthGuy]

I would not like to sing the praises of Cypress PSoCs too much (I am not their employee or an investor...and we have the resident PSoC expert, danadak), but the list above is a bit superficial, and maybe reading Chapter 7 and 8 of this document could help a better understanding.

Thank you. This is very interesting reading. I like the idea of creating your own peripherals with ULB. I also like the idea of different IO voltages for different pins.

You can actually interconnect stuff in modern PICs too. They even have logic cells which you can configure as logic gates or flip-flops. Timers became quite sophisticated. And you can connect elements. Not freely, but they're getting better and newer ones give more freedom and less restrictions on the interconnect. Of course, it doesn't get even close to building your own peripherals, but these small PICs are 5-10 times cheaper than the PSoC you quoted.

PSoCs are priced close to high end PICs such as new PIC32MZ DA with 32Mbytes of RAM. PSoC's price is also very close to the low end real FPGAs, such as Spartan-6 (and hopefully Spartan-7). Spartans are much better in creating your own peripherals, allow different IO voltages, and can handle speeds nearly 10 times faster than PSoCs.

It is wonderful to watch the enormous diversity of modern MCUs. I hope the vendors will keep it that way.

[westfw]

You can actually interconnect stuff in modern PICs too. They even have logic cells which you can configure as logic gates or flip-flops.

My interpretation is that the PIC CLCs compare to the PSoC Logic blocks about the way a GAL16V8 (simple PLD) would compare to Mach110 (smallish CPLD.)  Except that the CLCs are usually smaller than a GAL16V8, and there tend to be fewer of them on a chip than there are UDBs on a PSoC.

(So I looked into it a bit deeper, and this isn't very close.  But it still might be a useful comparison.  A Microchip CLC might be useful for combining the output from a timer with the output from a serial peripheral to produce a modulated waveform on a pin.  The PSoC UDBs are suitable for building an entirely new "modulated serial output peripheral" that doesn't use the base chip's peripherals...)

(OTOH, the CLCs are easily understandable and probably useful, while the UDBs have a CPLD/FPGA-like learning curve (if you want to go beyond pre-packaged functions.))

[danadak]

Adding to what newbrain said -

1) PSOC 5LP family has an internal DSP engine that can function as another
processor, in fact the PSOC 6 family imminent has a true dual processor architecture.
Cortex M0+ and Cortex M4. The DSP engine can be programmed to do some non
standard math or control, or used in its standard config as a digital filter, FIR or IIR,
dual channel, up to 128 taps in FIR.

2) The routing is pretty general, except that the analog has a preferred, not mandatory,
ports. There is a tool to analyze the switch paths in case one wants to deviate from the
norm.

3) User can create custom components (chip functionality) using Verilog or schematic
capture using all the predefined basic logic elements.

4) I am not a PSOC expert, just an active user. There are people on their website supporting
designers that I would classify as knowing a lot more than I do, Bob Marlowe being one. He
is very active over there helping.

5) Recently analog primitives have been added so one can build special analog capability.
I do not know yet how complete that is. But looks interesting. I worked in the field as
an FAE with a number of companies doing dual processor designs, for reliability, non-
stop computing, etc..

6) The on board bandgap ref is +/-  .1%, not too shabby.

7) DMA facility quite good, in terms of triggering, chaining, background operations etc..

Dual ADCs, 12 bit SAR + 20 bit DelSig, or dual 12 bit SAR.

9) There are several families, some sub $1, all with various HW resources. Even Bluetooth is
targeted by one family. The high end parts are not cheap, but when fully used very competitive.
All use same tool, PSOC Creator. Free, including compiler.

10) Some people are doing PSOC development on MAC using Parallels. Linux I see activity
on web, at your own risk I gather.

11) Several wizards make life easy setting up components like digital filter, DMA, routing evaluation,
clock system, ADC setup......


Just a few of the good things in a PSOC.


Regards, Dana.

[helius]

...

PSoC is a trademark proprietary to Cypress. SoC is a general industry term that has been with us for decades. It is like "Phone" vs "iPhone".
Xilinx is not a MCU company, and the Zynq chips are not like typical MCUs. They have no flash memory, for example, and a higher price structure.

The Cypress PSoCs have uncommitted logic arrays. Calling them just another peripheral is very strange and makes me question how much you can possibly know about electronics. This is like calling a 16R4 "just a buffer". It hardly makes any sense at all.
There have been MCUs with built-in programmable logic blocks before, like the discontinued uPSD from WSI/ST and E5 from Triscend/Xilinx.

[Dave_PT]

Why not

Because the ESP32 uses an obscure 32-bit MCU (the Xtensa LX6) with limited development support. The Nordic nRF52 is a much better choice. It also has built-in Bluetooth, but it's based on an industry standard ARM Cortex-M4 microcontroller.

And BLE alone is not yet enabled ...
They still have a lot of work to make the SDK usable and reliable.

[Dave_PT]

Thank you all.
I'm indeed looking at the Microstrick II, that supports PIC32MX, dsPIC33 and PIC24.
I'll look for some cheap new or used board.

Thank you!

Choose one and learn this one well.
The others are all the same ... more or less peripheral or configuration methods, but the basis is the same.

What matters is working with an MCU and learning what happens behind everything you are doing (low level).
In recent months I have used 3/4 different MCU brands. Besides some settings (as it is perfectly normal) it's pretty much the same thing in all ...

[ebclr]

Do nRF52 runs faster than esp32?  How much 1/100th ?

I guess the topic was performance / dollar

https://blog.classycode.com/esp32-floating-point-performance-6e9f6f567a69

[NorthGuy]

9) There are several families, some sub $1, all with various HW resources.

I looked at some PSoCs at the low end. I looked at one for about $1 (PSoC 4000 family), one for about $3 (PSoC 4100 family), one for about $5 (CY8C28xxx). Perhaps I selected wrong ones (there are almost 1000 parts to choose from and it's hard to pick up the good ones without knowing). Unfortunately, none of them have any ULBs. Looks like ULBs can only be found at the high end. Is this correct?

[danadak]

Look at PSOC 3 and PSOC 5LP. Also PSOC 42xx series. All have
UDBs.

If you open Creator, do a scratch project, there is a device selector wizard
that shows all parts, families, capabilities, and is filterable.

"Project", "Device Selector" from main menu.


Regards, Dana.

[NorthGuy]

Look at PSOC 3 and PSOC 5LP. Also PSOC 42xx series. All have
UDBs.

Found some 42xx with UDBs for about $5. Do you know if there's any document which would describe the structure of the UDB in details?

[newbrain]

Look at PSOC 3 and PSOC 5LP. Also PSOC 42xx series. All have
UDBs.

Found some 42xx with UDBs for about $5. Do you know if there's any document which would describe the structure of the UDB in details?

Welcome to the cult! 
We'll meet under the cypress tree after sunset.
Danadak will officiate.
All hail the PSoC!

Sorry...on a more serious note:

This is the technical reference manual for the PSoC5 LP, section E describes the architecture of UDBs and macrocells.

I see you are interested in the 4200, here is its TRM, section D16.

An application note for designing UDB based components.

[danadak]

Some training videos -


http://www.cypress.com/training/free-online-video-training-and-tutorials-cypress


http://www.cypress.com/search/all/udb?f%5B0%5D=meta_type%3Avideos


Regards, Dana.

[macboy]

Look at PSOC 3 and PSOC 5LP. Also PSOC 42xx series. All have
UDBs.

Found some 42xx with UDBs for about $5. Do you know if there's any document which would describe the structure of the UDB in details?

The CY8C4245AXI-483 has 4 UDB blocks and is ~$2.50 (USD) in singles.  This is the same chip as on the CY8CKIT-049-42XX which is a $4 gumstick size dev board that can be use used on a DIP breadboard, and has USB interface for programming, debugging, and UART communications.

To play with PSoC 5, try the CY8CKIT-059. At $10, it costs far less than the single qty of the PSoC 5LP chip that it has on-board. And it uses another lesser PSoC 5 for its USB programming/debugging interface. The PSoC 5LP chip seems expensive unless you need some of the advanced capabilities (20 bit ADC, DSP, UDBs, etc.), in which case it might be a bargain. If you are just looking for a 32 bit MCU with a bunch of ordinary boring digital peripherals then this is a poor choice.

[NorthGuy]

This is the technical reference manual for the PSoC5 LP, section E describes the architecture of UDBs and macrocells.

I see you are interested in the 4200, here is its TRM, section D16.

An application note for designing UDB based components.

Thank you.

Looks like pure logic resources of UDB are minimal. The most configurability comes from the biggest UDB element which they call "Datapath". It has two small FIFOs and a special kind of CPU in between. It only has space for 8 instructions and PC doesn't increment as it does in normal PC. The PC is rather selected by the associated logic, which allows all sorts of sequencing. The datapath's CPU can do shifts which is handy if you want to do some sort of SERDES, or it can add/subtract which can be used for different sorts of counters/PWM etc. The datapath is a very clever solution which allows creating different sort of customizable peripheral. I like the idea. But it is far from fully programmable logic.

[macboy]

This is the technical reference manual for the PSoC5 LP, section E describes the architecture of UDBs and macrocells.

I see you are interested in the 4200, here is its TRM, section D16.

An application note for designing UDB based components.

Thank you.

Looks like pure logic resources of UDB are minimal. The most configurability comes from the biggest UDB element which they call "Datapath". It has two small FIFOs and a special kind of CPU in between. It only has space for 8 instructions and PC doesn't increment as it does in normal PC. The PC is rather selected by the associated logic, which allows all sorts of sequencing. The datapath's CPU can do shifts which is handy if you want to do some sort of SERDES, or it can add/subtract which can be used for different sorts of counters/PWM etc. The datapath is a very clever solution which allows creating different sort of customizable peripheral. I like the idea. But it is far from fully programmable logic.

You've been confused by incomplete information. The "Datapath" is only part of the UDB. The PLD portion is another. This is a fully programmable digital logic block akin to a CPLD. It can be programmed using a graphical tool or by using Verilog directly. You need to look at AN82250 as well as the above linked file which talks only about the datapath portion.

[danadak]

By the way, the $ 10 dev board  CY8CKIT-059 is actually a dual PSOC 5LP processor board,
one used for debug programming, the other the target. So you can actually do a dual design
and program each of them for different functional use. There are limitations on the available I/O
on the snap off debug/programming board, but still you get quite a lot of horsepower with
the 2 processors.




Regards, Dana.

[danadak]

NorthGuy :

You can actually interconnect stuff in modern PICs too. They even have logic cells which you can configure as logic gates or flip-flops. Timers became quite sophisticated. And you can connect elements. Not freely, but they're getting better and newer ones give more freedom and less restrictions on the interconnect. Of course, it doesn't get even close to building your own peripherals, but these small PICs are 5-10 times cheaper than the PSoC you quoted.

Not true in general, the prices range from < $ 1 into mid teens, and that's not high volume designs.
Attached is 1 KU talk to nobody pricing.

PSoCs are priced close to high end PICs such as new PIC32MZ DA with 32Mbytes of RAM. PSoC's price is also very close to the low end real FPGAs, such as Spartan-6 (and hopefully Spartan-7). Spartans are much better in creating your own peripherals, allow different IO voltages, and can handle speeds nearly 10 times faster than PSoCs.

For sure, FPGAs are more general, with one significant limitation, analog is sparse. They have many advantages,
I am looking at a design that will take both a PSOC and an FPGA, because FPGA can give me very high speed
wide counters in the 100 Mhz area. But all the other stuff I need to do much more easily realized on the PSOC.


Regards, Dana.

[NorthGuy]

This is a fully programmable digital logic block akin to a CPLD.

Yes, but it is very small. One UDB has two PLDs. Two PLDs have roughly the same logic resources as 1/2 Xilinx 7-series CLB (setting apart the fact that Xilinx's CLBs are much more powerful and way faster). So, entry level PSoC devices with 2 UDBs have equivalent of 1 CLB. High end PSoC devices with 24 UDBs have equivalent of 12 CLBs. For comparison, the smallest Spartan-7 (XC7S6) has 469 CLBs.

The Datapath part of the UDB is much more massive, and this is what you would use to create your custom peripherals, with PLDs used to aid the process.

[NorthGuy]

I am looking at a design that will take both a PSOC and an FPGA, because FPGA can give me very high speed
wide counters in the 100 Mhz area. But all the other stuff I need to do much more easily realized on the PSOC.

If you have enough logic resources in your FPGA then you can run soft-core processer (or several of them). You can design your own soft-core processor to meet your needs exactly. If you already have FPGA, adding external ADCs and/or DACs (or perhaps some MCU which specializes on Analog stuff) might be a better solution.

[danadak]

The solution with PSOC gave me this part of design -

1) 2 ADC, one SAR, one DelSig, both which I needed.
2) Precision reference.
3) 1 VDAC
4) 1 IDAC
5) 1 Wavedac
6) 2 OpAmps
7) 1 Comparator

The rest of the stuff DMA, DSP, COM I could have gotten from FPGA,
but choose PSOC because a significant portion of the routing on PCB
could be eliminated by keeping this stuff in PSOC. And its there with the
analog, makes sense to use it.


Regards, Dana.

[donotdespisethesnake]

It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

In reality, there are many good 32-bit options, but there is no perfect choice. NXP, ST are easy to get into. Microchip SAM D21 and similar are gaining traction due to Arduino support.

Personally, I would look at the software, not the hardware. Find an IDE you are comfortable with, then see if there are some cheap boards supported well by the IDE. The actual manufacturer is almost irrelevant. 90% of your code is application level which is portable to any 32 bit MCU. The hardware specific stuff is usually a small portion of the code, and unless you like re-inventing the wheel, you will use a HAL library, or at least use it's functions as a base for your own libraries..

[donotdespisethesnake]

It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

PSoC software is REALLY easy to use. It's pretty much Arduino, you have good quality, MISRA certified libraries for many all hardware blocks, and for hardware block designing, it's like LEGO.

Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.

[technix]

It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

PSoC software is REALLY easy to use. It's pretty much Arduino, you have good quality, MISRA certified libraries for many all hardware blocks, and for hardware block designing, it's like LEGO.

Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.

I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.

Personally I am more comfortable with AVR and STM32, but you may want to look to my posts and see parts I am talking about - for some scenarios I was talking about PIC, I have a blog series about 8051 and some posts about the 8051-based STC15 line, and my four queued projects are based on NXP LPC2368 (ARM7TDMI,) Allwinner V3s (Cortex-A7 MP1,) Microchip AT91SAM9260 (ARM926EJ-S,) and Mediatek MT7688 (MIPS24KEc,) none of which is either AVR or STM32.

[nctnico]

Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.

I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.

IMHO what sets microcontrollers apart are bugs, ease of use (both software and hardware) and electrical quality of the design. The latter is about things like crystal startup, logic input levels, output drive capability, susceptibility to latch-up and ESD, adequate margins in supply voltage, etc.

[westfw]

what sets microcontrollers apart are bugs, ease of use (both software and hardware) and electrical quality of the design.

Ah.  And Documentation.  Some vendors have notably worse documentation than others.  FTDI doesn't much document the architecture of their Vinculum2 chip at all.   Intel's documentation for their chips (even the supposedly embedded-friendly Quark chips and Curie modules) has been late, hidden behind NDA agreements, or sucky.
For ARM chips, there's a great deal of variation in how many different datasheets you'll need.  It's pretty common to have a chip data sheet describing pinouts, a family datasheet documenting how the vendor peripherals work, and a pointer to ARM documentation if you want to know about the ARM peripherals (SysTick, NVIC), instruction set(s), or architecture (that's at least 2 and perhaps 3 ARM manuals to go with your 2 vendor manuals.  Fun, eh?)
A couple of vendors/devices I've looked at stand out as having unusually complete single datasheets - the TI Tiva series is one, and the Atmel SAM3X is another (interestingly (?), the Atmel SAMD chips go back to omitting the ARM-side documentation that the SAM3X datasheet includes.)

A lot of this is more relevant to the "moving" part; once you gain some familiarity with an ARM chip or two, you'll have figured it out and it probably won't bother you too much to have a separate ARM TRM document.  But when I was first looking at ARM, it was driving me crazy.  (and I think the ARM documentation has improved.  I could swear that when I was first looking, they has Cortex M documentation that said essentially "This supports the standard ARM v7 instruction set except for all the non-thumb instructions."  Now there are distinct manuals !)

This applies to any vendor libraries, too.  In general, I think the libraries suck and avoid them, but they CAN be useful examples for understanding how the chip actually works.   IFF they're reasonably documented and the source code is browseable.  My current peeve is that I can't figure out how to browse Atmel ASF source unless I add it to a "project" first (possible, but annoying.)  ST, IIRC, had a nice library doc/source browser, but it was based on windows .CHM files and therefore not as nice on non-windows systems.  A lot of libraries have DOXYGEN-generated documentation that has a description of every individual function, but seem to lack any overall explanation of philosophy, high-level operation, or interdependencies.   ("Yes, the uart_init() function has an argument of uart_init_params with type uart_init_parms_t.  That's just ... swell.  Thanks.")  The vendors that have changed their library philosophy a couple of times in the last decade (samlib->ASF->Start, or stmlib->cube->whatever) don't make it any easier (but at least they're DOING something...)

A lot of it seems to be "Everything sucks; I'm just going to bang my head against this arbitrary choice until I understand it, and I hope the second one will be easier."

[NorthGuy]

I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.

What sets MCUs apart is the purpose. One MCU may be more suitable for one purpose, the other for some other purpose. IMHO, the biggest mistake people make is choosing "good" MCUs instead of choosing MCUs which are the most suitable for the task. Of course, to be able to choose, you must know what is available and monitor how the available choices change with time.

[nctnico]

I have long thinking about that. Every 32-bit MCU works as well as the next (maybe except a few corner cases) and there is no single specific reason one line of products is better than the next. Maybe you have more experiences in something but that does not automatically makes it better for the next person.

What sets MCUs apart is the purpose. One MCU may be more suitable for one purpose, the other for some other purpose. IMHO, the biggest mistake people make is choosing "good" MCUs instead of choosing MCUs which are the most suitable for the task. Of course, to be able to choose, you must know what is available and monitor how the available choices change with time.

If you choose a good MCU family then it will have a family member which is suitable for a specific task without needing to rewrite most of your existing software or make changes in your eco system (programmer). NXP has been such a vendor for me. Almost every microcontroller based project I have made during the past decade has a different NXP ARM microcontroller in it due to project specific requirements. If I had choosen to use ST this would have been much harder to do.

[danadak]

Should we revive the vacuum tube vs transistor debate ?

For folks that have a difficult time making decsions/evaluations, use a
weighted decision matrix, Excel, works like a charm when too many
variables are involved for our gerbil sized brain pans. Actually i should
not assume others have my limitations.

The real "smell" test of PSOC is try it before you buy it. If you cant figure
out in 30 minutes, watching a couple of their videos, move on, you are not
meant for PSOC. If you are a PCB manufacturer who makes money off area
of PCB, don't use a PSOC. If you like large boxes, lots of heat, don't use a
PSOC. If you have applications that have no analog, no need for digital filter
in signal chain, don't care about what pin carries what signal, don't need a
precision reference, don't like ARM cores, don't need a 20 bit A/D or a fast
SAR 12 bit, or both, don't like DMA, especially do not want to design your
own specialized on chip component, don't use a PSOC.

Lots and lots of reasons to NOT use a PSOC.

Regards, Dana.

[nctnico]

I like that you are positive about the PSOC but the last time I looked it seemed to me that you can't have all the peripherals but have to make a choice. From there it is hard for me to determine whether a PSOC device would fit or not without making a design first and the latter takes more time than I would want to spend on selecting a device. But maybe I'm completely wrong here...

[technix]

Should we revive the vacuum tube vs transistor debate ?

For folks that have a difficult time making decsions/evaluations, use a
weighted decision matrix, Excel, works like a charm when too many
variables are involved for our gerbil sized brain pans. Actually i should
not assume others have my limitations.

The real "smell" test of PSOC is try it before you buy it. If you cant figure
out in 30 minutes, watching a couple of their videos, move on, you are not
meant for PSOC. If you are a PCB manufacturer who makes money off area
of PCB, don't use a PSOC. If you like large boxes, lots of heat, don't use a
PSOC. If you have applications that have no analog, no need for digital filter
in signal chain, don't care about what pin carries what signal, don't need a
precision reference, don't like ARM cores, don't need a 20 bit A/D or a fast
SAR 12 bit, or both, don't like DMA, especially do not want to design your
own specialized on chip component, don't use a PSOC.

Lots and lots of reasons to NOT use a PSOC.

Regards, Dana.

* If you need high efficiency float point arithmetic, do not use a PSoC. Since your strong point is analog, where did the complimentary FPU go? Both ST and Microchip products can come with a FPU, be it Cortex-M4F, Cortex-M7F or MIPS FPU.
* If you need more than 80MHz clock speed, do not use a PSoC. ST, Microchip and NXP all have chips operating at more than 80MHz. ATSAM3X8E, as used on Arduino Due, sports a 84MHz clock. Heck even the Chinese-made less-than-well-known WCH CH563 can operate at 180MHz.
* If you need Ethernet, do not use a PSoC. ST, Microchip and NXP all have chips that comes with MII/RMII interfaces for your Ethernet PHY. You can argue PSoC can use things like W5500 or ENC28J60 but those always works less efficient with an internal MAC. Remember the WCH CH395? That chip even edges out the big players by having a built-in Ethernet PHY.
* If you need to build affordable products, do not use a PSoC. I will elaborate on this below.

The price is really, REALLY a sore point for PSoC. I am shooting for the highest end here with CY8C5888AXQ-LP096. It is a $15.52 chip, Cortex-M3 @80MHz, LQFP100 package, 256kB Flash, 64kB SRAM, and a bunch of analog peripherals. So what can I buy for $15.52 from other vendors? STMicroelectronics STM32F756BGT6, NXP MKV58F1M0VLL24, TI TM4C129EKCPDTI3, Microchip ATSAM4CMP8CC-AU. Try compare those. And the slightly more expensive Microchip PIC32MZ1025DAH176T-V2J (about $17.5) is the heatedly talked about PIC32MZ DA line with 32MB built-in DRAM - runs Linux if you slapped a $2 SPI NOR Flash on it. Here I still restricted myself to the big name brand territory.

If you start looking into the lesser-known world you start to see more competitors. I have been flirting with Allwinner V3s (being a MPU it lacked a lot on the I/O side of things, but for IoT it is cheap enough to be built into every single unit you are shipping while still powerful enough to handle things like TLS and reduced resolution OpenCV.) There is also the WCH CH395 I hinted about.

[nctnico]

I wouldn't dismiss a solution with the Wiznet W5500 because it also takes care of the TCP/IP stack and you only transfer the actual data between your microcontroller and the W5500. You don't have to deal with broadcast messages which don't concern you.

[Elf]

[...]
Lots and lots of reasons to NOT use a PSOC.

Sheesh. Apparently "there are other good products out there" somehow didn't make the list.

Maybe I am weird, but I actually enjoy sampling all the different things out there rather than trying to use the same chips for everything, every time. Mind you I am not in a professional environment and have no pressure for time to market, but they all seem to have something to like and dislike. Documentation, IDE, libraries, price, availability, peripherals, programming/debugging tool quality and cost, performance, power usage, etc.

[danadak]

From the 2016 annual report -

Excluding the impact of IoT revenues, MCD increased by $128.3 million for fiscal 2016, or 17.6%,
compared to the prior year, primarily due to increased revenue in the automotive segment.
Revenues from MCD in fiscal 2015 increased by $362.3 million or 98.2%, compared to fiscal 2014.
The increase in the 2015 MCD revenue was primarily attributable to the following factors:
• Contribution from products acquired as part of the Spansion acquisition
• Increase in sales of products related to automotive applications.
This increase was offset by decreases related to the following factors:
• Divestiture of TrueTouch business
• Weakness in demand in the mobile business and consumer end markets
The overall average selling price of our products for MCD for the year ended January 1, 2017 was
$1.02 which is unchanged from the prior-year. The overall average selling price of our products for
MCD for the year ended January 3, 2016 was $1.02 which increased by $0.24, compared to $0.78 in
fiscal 2014. The increase in ASP is due to Spansion acquisition.

The ASP was ~ 78 cents (prior to Spansion acquisition), thats so non
competitive they will never ship anything. Wait, they shipped from the Microcontroller division $994 million,
clearly into non competitive products. What are those designers thinking ?

And they continue to invest heavily into PSOC, 6 family dual core end of this year. 2 arm cores. Too
much computing power is not good for the planet.

Since your strong point is analog, where did the complimentary FPU go?

No FPU, but does have fixed point 24 x 24 MAC for the digital filter block, or as a GP control engine.
That seems to handle efficiently signal path processing. And the M3 core has a single cycle MUL
instruction, 32 bit.

PSOC clock speed definitely 80 Mhz or less. Not sure at this time what the PSOC 6 will come in at.
The FM family of ARM cores is good for 200 Mhz, but thats non analog or route ability or....not a PSOC.

For sure no Ethernet, would be nice to have an Eth MAC on board a part. There are designs out there
where Eth has been done though, does not seemed to have inhibited activity. Not sure of impact on
thruput though.


Regards, Dana.


PS : Being a tad facetious on some points

[danadak]

nctnico,

The PSOC does have limitations, not an infinite amount of logic. But, for example, another poster
needed a lot of PWMs, I was able to get 16 16 bit PWMs placed and routed along with a lot of other
stuff on a chip. In fact the resource result tab indicated I might have been able to get more PWMs.


https://www.eevblog.com/forum/microcontrollers/best-way-to-add-external-dacs/msg1207330/#msg1207330


For sure there is a learning curve. I found it fairly easy because of their video library and I
had been working with Freescale Codewarrior with Processor Expert so was used to leading
edge IDE (or I thought it was), so the transition to get something done was fairly quick.
In short order I was doing a design on both platforms, porting back and forth. But stopped
when I started to use the analog in PSOC.

Regards, Dana.

[NorthGuy]

But, for example, another poster
needed a lot of PWMs, I was able to get 16 16 bit PWMs placed and routed along with a lot of other
stuff on a chip. In fact the resource result tab indicated I might have been able to get more PWMs.

For comparison, an entry level Spartan-6 can give you over 100 16-bit PWMs for substantially lower price than CY8C5868AXI.

[nctnico]

But, for example, another poster
needed a lot of PWMs, I was able to get 16 16 bit PWMs placed and routed along with a lot of other
stuff on a chip. In fact the resource result tab indicated I might have been able to get more PWMs.

For comparison, an entry level Spartan-6 can give you over 100 16-bit PWMs for substantially lower price than CY8C5868AXI.

But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.

[NorthGuy]

But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.

All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero.

[danadak]

NorthGuy,

I am curious about price, I filtered the Digikey 1 off pricing for all Sparton 6
families and best I saw was $ 11.48.

I have a design that will use a FPGA and PSOC, and am new to FPGA side, so
curious about what "real" 1K pricing on low end looks like. All I need out of
part is 2 150 Mhz 32 bit counters, maybe a CPLD will be the solution. And
only 10 or so pins.

The example I gave on PWM was not about just PWM, it also included DSP, and
a bunch of other stuff. And took me about 20 minutes to do. And the example
left a lot of analog resources unused.



Regards, Dana.

[suicidaleggroll]

am new to FPGA side, so curious about what "real" 1K pricing on low end looks like. All I need out of part is 2 150 Mhz 32 bit counters, maybe a CPLD will be the solution. And only 10 or so pins.

It may be worth writing up the VHDL/Verilog, using the simulator to verify functionality, and then selecting different models to check usage.  You very well may be able to get away with a small Coolrunner II CPLD or similar, which has single-unit pricing down to $1.40 on Digikey.  CPLDs are much less capable then FPGAs, but they are also much less demanding when it comes to layout, decoupling, supporting electronics (IE: flash), etc.  For simple applications they make a lot of sense, but you need to write up the code to see if it'll fit first.  When you get up to the 256 macrocell range is when it starts to make more sense to switch to an FPGA.

[technix]

I wouldn't dismiss a solution with the Wiznet W5500 because it also takes care of the TCP/IP stack and you only transfer the actual data between your microcontroller and the W5500. You don't have to deal with broadcast messages which don't concern you.

Try move a few MiB in a short burst. Or try IPv6.

[technix]

It's weird how certain products pick up such ardent fanboys.. Cypress PSOC has some interesting features, but I wouldn't recommend it for newcomers.

PSoC software is REALLY easy to use. It's pretty much Arduino, you have good quality, MISRA certified libraries for many all hardware blocks, and for hardware block designing, it's like LEGO.

Yeah, so is nearly every other 32 bit MCU... frankly I am beginning to think all the boosting for PSOC smells of BS.

I have been using Eclipse CDT for a while now. It is easy to use, works everywhere (including Linux and macOS,) and programming and debugging is straightforward. Oh Eclipse CDT is non discriminatory between vendors so it works on one vendor’s produce line as brilliantly as the next, as long as it is supported. Oh forgot to mention that yes I am a UNIX person.

[NorthGuy]

I have a design that will use a FPGA and PSOC, and am new to FPGA side, so
curious about what "real" 1K pricing on low end looks like. All I need out of
part is 2 150 Mhz 32 bit counters, maybe a CPLD will be the solution. And
only 10 or so pins.

I don't know 1K pricing, I've never bought them in quantities. A 32-bit counter will only take 5-6 slices. They also have few DSP slices which can add and multiply very fast. You probably will still need a number of slices to interface the counters to the inputs/outputs. I think the smallest Spartan-6 has about 600 slices, so if only used for two counters it still be an overkill. But if you have complicated logic associated with the counters, the slice count may go up very quickly. The best way is to do the design and see.

[nctnico]

But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.

All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero.

I agree but that is not a reason to just dismiss NRE costs and only look at the costs of a single part.

[NorthGuy]

I agree but that is not a reason to just dismiss NRE costs and only look at the costs of a single part.

That's true too. It is meaningless to evaluate suitability of different MCUs without knowing the purpose, budget and many other factors. None of these can be dismissed. That is exactly the reason why we cannot perform a comprehensive analysis on the forum. However, it doesn't mean that isolated factors, such as unit price, cannot be discussed and/or compared.

[Siwastaja]

When I search for STM32 programing it all seems very confusing due to all the aproaches you have (Standard Peripheral Library, CubeMX, etc).

It's confusing, but luckily, there's an answer: you can just do all of it normally, like you did with AVR or PIC processor: by reading the reference manual and configuring the registers as you wish. The peripherals are a bit more complex (due to being more capable), but it doesn't make it too hard to learn. STM32 libraries make everything difficult since they don't abstract the implementation details out as they should, but only add an extra layer of burden and uncertainty.

Doing it without the library structs and functions produces much more readable code, quicker development, higher level of understanding and more robust implementations, compared to library code copypasting from Stackoverflow; this has nothing to do with the concept of using libraries in general, but everything to do with the STM32 libraries, which, unfortunately, are totally unusable and completely doomed. This is a trap for young players, who will find a lot of confusing examples on the web, while it's difficult to find simple examples that don't use the libraries.

If you require a good peripheral abstraction layer and usable libraries that allow you to work on the higher level, and you don't want to write this layer from scratch, then STM32 is definitely out of question. AFAIK, most others have it at least somewhat better, although it's seldom brilliant. For me, having good libraries and abstaction layers was not too important, since they tend to suck anyway, and I like to work on low level, so I work with STM32 chips quite a lot, and have a love-hate relationship with them. They do have documentation issues and undocumented silicon bugs (even though the errata sheets are quite long), and they ignore reports of non-documented silicon bugs, instead of being responsible and updating the errata sheet. But I guess most other complex 32-bit MCUs have similar issues as well.

Generally, the modern 32-bit MCUs have peripherals that are a lot more capable than something on an 8-bit AVR, so that even when you have more processing power available, you end up using less of it; more of your code ends up initializing the peripherals that can do surprising amount of the work so that you don't need to do timing-critical things in software as much.

[technix]

When I search for STM32 programing it all seems very confusing due to all the aproaches you have (Standard Peripheral Library, CubeMX, etc).

It's confusing, but luckily, there's an answer: you can just do all of it normally, like you did with AVR or PIC processor: by reading the reference manual and configuring the registers as you wish. The peripherals are a bit more complex (due to being more capable), but it doesn't make it too hard to learn. STM32 libraries make everything difficult since they don't abstract the implementation details out as they should, but only add an extra layer of burden and uncertainty.

Doing it without the library structs and functions produces much more readable code, quicker development, higher level of understanding and more robust implementations, compared to library code copypasting from Stackoverflow; this has nothing to do with the concept of using libraries in general, but everything to do with the STM32 libraries, which, unfortunately, are totally unusable and completely doomed. This is a trap for young players, who will find a lot of confusing examples on the web, while it's difficult to find simple examples that don't use the libraries.

If you require a good peripheral abstraction layer and usable libraries that allow you to work on the higher level, and you don't want to write this layer from scratch, then STM32 is definitely out of question. AFAIK, most others have it at least somewhat better, although it's seldom brilliant. For me, having good libraries and abstaction layers was not too important, since they tend to suck anyway, and I like to work on low level, so I work with STM32 chips quite a lot, and have a love-hate relationship with them. They do have documentation issues and undocumented silicon bugs (even though the errata sheets are quite long), and they ignore reports of non-documented silicon bugs, instead of being responsible and updating the errata sheet. But I guess most other complex 32-bit MCUs have similar issues as well.

Generally, the modern 32-bit MCUs have peripherals that are a lot more capable than something on an 8-bit AVR, so that even when you have more processing power available, you end up using less of it; more of your code ends up initializing the peripherals that can do surprising amount of the work so that you don't need to do timing-critical things in software as much.

Look here:
https://github.com/xcvista/STM32F407-Startup/blob/master/platform/src/stm32f4xx_it.c
https://github.com/xcvista/STM32F407-Startup/blob/master/platform/src/system_stm32f4xx.c

I decided to give the STM32F407 startup code a rewrite, and ended up getting this easily understandable code.

[Kjelt]

STM32 libraries make everything difficult since they don't abstract the implementation details out as they should, but only add an extra layer of burden and uncertainty.

Doing it without the library structs and functions produces much more readable code, quicker development, higher level of understanding and more robust implementations, compared to library code copypasting from Stackoverflow; this has nothing to do with the concept of using libraries in general, but everything to do with the STM32 libraries, which, unfortunately, are totally unusable and completely doomed. This is a trap for young players, who will find a lot of confusing examples on the web, while it's difficult to find simple examples that don't use the libraries.

You could easily as well argue the other way around.
CubeMX icw SW4STM32 works, it is definitely not great, as you say a lot of layers but it works and there is a forum with thousand people giving you support and as last resort a company that has people added to the forum to add support.
Compare that to your own bare metal implementation or that from anyone else, there is no support, it might work but easily as well fail at some time if the youngplayer wants to do something else, eg add a peripheral.
The 3rd baremetal engineer has its own way of thinking and working so created that code with his mind which is perfectly ok for him/her but another person needs to grasp that way of thinking, invest in understanding the code. Often there is no or minmimal documentation, minimal comments in the code, no support , that considered it is equally bad in my eyes.

Now I have started with CubeMX and SW4STM32 with a modern nucleo board with a decent processor (STM32L4xx or STM32F4xx are good for starters, don't use the F1 since it is old and has lots of quircks) and had it up and running in one day with a blinky. Another 1 hour for a UART that did not do what I wanted  So there I encountered my first issue, it only had interrupt functionality to receive a fixed number of bytes. Calling the function with 1 byte half the data was lost. So looking at those huge functions with extra code around it to make it pretty robust I hacked and slashed it back so the IRQ function would not call 3 layer deep other stuff but in case there was no error it stored the byte in my own queue module and be done with it. So total 1 day and I had a uart working, not bad.
A youngster might need a week or more with help from the forum to get things going but way better than starting from scratch.

Then another argument: code size, I know MX consumes code as we drink water but my project above took 12kB , I still have 988kB left, so what is the problem? For mass production yeah don't go that way, for hobbieist, amateurs One of a kind projects, come one , unless you are a student or unemployed your time costs more than the ROM on the chip.

IMO the CubeMX can be used as a start to get things going: I/O properly defined, clocks and peripherals defined and working. Then the hard stuff starts to tweak and adjust it to your own personal needs.
For youngplayers, stick to the HAL because then you have support.

[VEGETA]

What about Renesas?

Surely they don't support beginner-friendly boards and their prices is to the roof... but their quality is nice. I do hope I get to use them one day when I have the chance.

They have "gadgets" boards like Sakura and Peach boards with what they call MPU (mircoprocessor unit), because MCU is too mainstream.

I'd like to take your opinions on why such a very powerful MCU (or MPU) is not so popular on this forum or in general, despite being one of the best sellers and kinda the kind of automotive market as far as I know.

___

One little thing off the side: which one of these 32-bit MCUs offer protection from stealing firmware? I bet commercial product designers take this so serious, aren't they?

If you are going to design a commercial product, will you use code protection features?

I am saying this because I could get the AVR code of a washing machine board then burn it on another new chip then solder it instead of a faulty one... this makes repairing a whole board price without even doing a thing xD. Not everyone knows how to do it, despite being simple. I am going to try the same with Freescale and Renesas products. Renesas ones use protection but somehow people are confident that a USB-to-serial flash programming will get the code out of it... it is just a trial to see if the chip is protected or not.

[technix]

One little thing off the side: which one of these 32-bit MCUs offer protection from stealing firmware? I bet commercial product designers take this so serious, aren't they?

If you are going to design a commercial product, will you use code protection features?

I am saying this because I could get the AVR code of a washing machine board then burn it on another new chip then solder it instead of a faulty one... this makes repairing a whole board price without even doing a thing xD. Not everyone knows how to do it, despite being simple. I am going to try the same with Freescale and Renesas products. Renesas ones use protection but somehow people are confident that a USB-to-serial flash programming will get the code out of it... it is just a trial to see if the chip is protected or not.

I think most vendors offer a lockdown mode that either requires a mass erase or is impossible to remove. For what I know STM32 have a code protection level 2 that completely disables any programming and debugging interfaces, disables the internal bootloader entirely, and not even allow the application to switch it back.

[Elf]

What about Renesas?

Surely they don't support beginner-friendly boards and their prices is to the roof... but their quality is nice. I do hope I get to use them one day when I have the chance.

I agree that they aren't widely used in hobbyist circles. Probably just one of those momentum things. The (non-pink) evaluation boards are a little costly, in line with that 90s era pricing model; you might pay in the $50-200 range? The pink "Gadget Renesas" boards seem to be targeted to the hobbyist market in Japan only. However, after you spend a little more for the dev board I don't think they're unapproachable by hobbyists who are already familiar with microcontrollers. The YRDKRL78G14 evb is pretty neat.

They have a good series of entire books, published for free, that are very readable. They seem to have a sane architecture conducive to C compilers. Good documentation, a standard Eclipse based free IDE (e2 studio), and a free GCC toolchain available. The only unusual thing I have noticed is that some entire lines of a given microcontroller will not be available through distributors. It seems they are focused towards high volume automotive parts where you are expected to contact them directly and get a quote on large quantities.

The cost of the chips is about on par with their competitors:

• RL78 - Starting at $1.02 / qty 1
• RX - Starting at $2.82 / qty 1

I am increasingly using RL78 and like it enough that I will pay for their optimizing compiler. I want to try out their RL78/G1D with integrated Bluetooth Low Energy, when that becomes more available. Their E1 programmer is the only programming tool I've seen that has a self-check function; I wish everyone else did that, especially with what you pay for some of these things.

That all said, there is no secret magic feature of these microcontrollers just because they are Renesas and move in high volume. You can do most of the same things with an MSP430, STM32, etc.

[Kjelt]

Renesas: difficult to get and expensive for low quantities.

Goto Farnell type Renesas goto microcontrollers, 44 found only 13 available rest no longer available, look at price for 32 bit only 50MHz.
Then type STM goto microcontrollers >1000 ARM, >110 other
Repeat with Microchip/Atmel, NXP , TI you get the picture.

[Elf]

Renesas: difficult to get and expensive for low quantities.

Goto Farnell type Renesas goto microcontrollers, 44 found only 13 available rest no longer available, look at price for 32 bit only 50MHz.

Well, I can't speak for the situation outside the US, but:

• Digikey: 841 parts active and available
• Mouser: 172 parts in stock
• Arrow: 470 parts in stock
• 50MHz RX200: $6.38 to $3.31 depending on quantity
• 40MHz RX200: $3.72 to $1.70 depending on quantity

Maybe it is expensive and hard to get in some parts of the world, but not here.

[macboy]

But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.

All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero.

I completely disagree. For hobby projects or any other one-off, the NRE is the dominant cost. The cost of the parts is a pitance compared to the time to develop. You don't ammortize the NRE over thousands or millions of units, it is all for one unit. The cost of a single PSoC5 is equal to less than half an hour of time.  So even if it is way overkill and 80% of its resources go unused, if it makes the solution easy and quick then it's a good choice. If I was building a million of them, then I'd spend a lot of time to choose something that fits the application well without added cost for unused features.  My hobby time is neither free nor plentiful.

[technix]

But now compare the NRE (development costs), extra supply voltages, external rom for the configuration and programming solution. It is not the price of the chip which counts but the cost of the solution (development costs + hardware). Many seem to completely overlook that.

All true. But we have no way to evaluate these components, as they depends on so many factors which we don't know. For example, if this is a hobby project NRE is zero.

I completely disagree. For hobby projects or any other one-off, the NRE is the dominant cost. The cost of the parts is a pitance compared to the time to develop. You don't ammortize the NRE over thousands or millions of units, it is all for one unit. The cost of a single PSoC5 is equal to less than half an hour of time.  So even if it is way overkill and 80% of its resources go unused, if it makes the solution easy and quick then it's a good choice. If I was building a million of them, then I'd spend a lot of time to choose something that fits the application well without added cost for unused features.  My hobby time is neither free nor plentiful.

For that IDE that is mandated to use, either people will get straight up shut down by it if they have only Linux or macOS, or will fumble a lot due to the (fairly) steep learning curve of PSoC. It is often faster just cook up a small circuit on a breadboard and test if it works than go through the nitty gritty bits of PSoC Creator. I even have STM32F373CCT6 on DIP adapters just so I can prototype with even advanced processors like that quickly. Also where is your CMSIS hraders? A lot of code may not expect vendor library in place but do expect to find CMSIS.

[Sal Ammoniac]

Just a few of the good things in a PSOC.

To me, the biggest drawback of the PSoC is that no currently available part has hardware floating point. The PSoC 5 is based on Cortex-M3 (which doesn't have an FPU) rather than a Cortex-M4 (which does).

[technix]

Just a few of the good things in a PSOC.

To me, the biggest drawback of the PSoC is that no currently available part has hardware floating point. The PSoC 5 is based on Cortex-M3 (which doesn't have an FPU) rather than a Cortex-M4 (which does).

I have long raised this question of the missing FPU for an analog-centric chip. And they decided to dismiss it entirely.

[nctnico]

Renesas: difficult to get and expensive for low quantities.

Goto Farnell type Renesas goto microcontrollers, 44 found only 13 available rest no longer available, look at price for 32 bit only 50MHz.

Well, I can't speak for the situation outside the US, but:

• Digikey: 841 parts active and available
• Mouser: 172 parts in stock
• Arrow: 470 parts in stock
• 50MHz RX200: $6.38 to $3.31 depending on quantity
• 40MHz RX200: $3.72 to $1.70 depending on quantity

Maybe it is expensive and hard to get in some parts of the world, but not here.

Well Farnell usually is a good indicator of popularity and future availability. Until about 15 years ago Hitachi (now Renesas) microcontrollers where quite popular but nowadays they seem to have vanished. Maybe this has to do with lack of good low cost (free) tools. Back in the old days the distributors would hand out 'demo' versions of the compilers to keep sales going.

[Elf]

Maybe this has to do with lack of good low cost (free) tools. Back in the old days the distributors would hand out 'demo' versions of the compilers to keep sales going.

But they do have free dev tools, though? They have the same Eclipse / GCC combination that most other companies provide:

• e2 Studio (Eclipse)
• GCC for RL78, RX, etc.

No need to try and install and configure GCC separately either. e2 Studio will download, install, and integrate with it automatically at setup time.

With the above, there is better access to a free toolchain than for PIC.

I just want to buy CC-RL (their proprietary compiler) because I don't really like GCC, and I think the Renesas one makes better code. Personal preference.

Well Farnell usually is a good indicator of popularity and future availability. Until about 15 years ago Hitachi (now Renesas) microcontrollers where quite popular but nowadays they seem to have vanished.

I don't know, is distributor availability really a good measure of popularity? The company itself seems to be doing just fine:

Note that most of the growth of their competitors was purely due to acquisitions.

Given those numbers, if a distributor's stock was an indicator of overall popularity, why wouldn't Farnell stock Renesas? Surely as a business they would want to sell based on what is happening today, not how popular it will be five years from now. I mean, Farnell sells Raspberry Pis; does that mean they are a more popular product than Renesas chips? Maybe in certain circles.

I just do this on my own as a low volume purchaser, so I have no "industry perspective" on what is going on. Keep that in mind as I'm really unqualified to know what is going on here. However, if it is like most other B2B companies, my guess would be that Renesas is just picky about their sales channels. Since they cater to the automotive market, I'd guess they know the names of all of their potential customers and have or are trying to establish direct sales relationships with them. They are probably not the types of customers that order through distributors (a.k.a. middlemen). Like I was saying earlier, Renesas have entire lines of various microcontroller families (hundreds of parts) that I can't find at any distributors anywhere, but which are clearly being produced and supported. They probably expect you to call, strike a deal with with a sales droid, and put in your first order for a few pallet loads.

Likewise my only experience with Farnell is that they don't seem to be competitive on price or selection here in the US, but that they seem to be big in Europe. Even today, I think geography has a huge role in what we are exposed to. For example in the other thread over there was a lot of discussion about WCH and Allwinner chips. I know these move in high volume (Allwinner especially), but again they are not available at any distributors I buy from. Does that mean they are unpopular? Or does it just mean that you'd have to be in China to be exposed to that ecosystem?

[Elf]

They are supposed to be used in ultra cheap devices as MPU. If you factor in R&D cost (due to poor documentation and barely hacked up Linux kernel) and logistics cost (to send someone to China just to purchase and do local QA) as well as patent cost (to be legally imported to western world), they are not that cheaper compared with NXP/FS MPUs.

I assumed as much; documentation is one of my critical needs and I will pay a lot more for a well documented product. But if you are making tablets or coffee machines I expect the equation works the other way around.

[technix]

For example in the other thread over there was a lot of discussion about WCH and Allwinner chips. I know these move in high volume (Allwinner especially), but again they are not available at any distributors I buy from. Does that mean they are unpopular? Or does it just mean that you'd have to be in China to be exposed to that ecosystem?

They are supposed to be used in ultra cheap devices as MPU. If you factor in R&D cost (due to poor documentation and barely hacked up Linux kernel) and logistics cost (to send someone to China just to purchase and do local QA) as well as patent cost (to be legally imported to western world), they are not that cheaper compared with NXP/FS MPUs.

One Chinese chip made the exception, ESP32, but so far that's the only one I know, with good BSP (though not Linux), English document and no legal issues (no known patent infringements, no known copyright issues, and they officially offers FCC certified modules).

At least for Allwinner MPU the only folks that is actually interested in the documentation is the folks in linux-sunxi community trying to write and mainline the drivers. For us using the chip all we need is a simplified documentation produced by the community (in English anyway) that allows us to boot the chip up.

As of patents what technology you suspect is not useable without license? You can skip the video engine (contains MPEG license issue) but it does not have a community driver anyway. I know SD can be a common target here but keep in mind SD interface using SPI, 1-bit and 4-bit are not license encumbered as those are also covered in the MMC standard.

For WCH most of their products runs their own propertiary mask programmed core (hence can be treated as a black box.) The few chips that contained licensed IP they did it right way.

[technix]

At least for Allwinner MPU the only folks that is actually interested in the documentation is the folks in linux-sunxi community trying to write and mainline the drivers.

That's the problem. An IC company doesn't provide true GPLed kernel at all is quite questionable. A third party repo is appreciated, but don't you think it's supposed to be the job of the official who monetizes on their chips?

That is the problem but so does nVidia or Imagination (PowerVR) do this too. Allwinner do drop code but blobs are common.

[technix]

That is the problem but so does nVidia or Imagination (PowerVR) do this too. Allwinner do drop code but blobs are common.

And if I run a chip company, I don't want a global software leader to say F me.
I'm fine with binary blobs for FW, but for code running on the same CPU in the same memory space of kernel, I prefer not to have blobs.

At least it seem to me that Allwinner don’t mind a potential GPL violation suit or on the receiving end of the said leader’s F bomb or the proverbial bird.

[Kjelt]

Some mcu companies only target business to business sales in huge quantities.
Broadcom comes to mind with their socs that have m4 cortex in them, try find a datasheet, it is unobtanium unless you are working inside such a business deal company.
For an individual the smart move is to go with the mainstream companies that offer documentation, support and where forum members can help with experience.
.

[Elf]

For an individual the smart move is to go with the mainstream companies that offer documentation, support and where forum members can help with experience.

I agree, those are very important things. I like and use Renesas personally (along with many other platforms / manufacturers) and find the documentation enough for my purposes, but I won't say that everyone needs to drop what they are using and go pick up some Renesas chips. At the end of the day there are plenty of chips that do the same things. I think we're lucky to have so many choices today.