This post is part of my Roadtest Review of Cypress PSoC 62S2 Wi-Fi & BT5.0 Pioneer Dev Kit - Review. My review is splitted into multiple reviews and tutorials. Main page of review contains brief description of every chapter. Some projects are implemented in multiple variants. Main page of review contains brief description about every chapter, project and variants and contains some reccomendations for reading.

 

Table of contents

 

Review of Microcontroller

In this chapter I describe design on MCU, his properties, my thoughts about some concepts used in it. I will sometimes compare to STM32s in this review.

 

Classification of MCU

At the beginning I will mention about which MCU do I speak.  Official name of MCU is CY8C624ABZI-S2D44. Most important part of name is CY8C624A. Most important number is 6 – it means it is PSoC 6. Second number is 2. It means third subfamily (because subfamilies are numbered with starting at 0). Sometimes is this family referred as PSoC 62. Remaining two numbers and letters specify CPU speed and memory sizes. Important is memory size (A letter) because all documentation is grouped by that value and there are some other differences between MCUs with different 4th letter.

 

PSoC

When I saw PSoC first time I thought that it is just yet another ARM microcontroller on the market. But very early I have seen some concept showing that it is not just a normal MCU. Rather It is set of generic blocks (peripherals) interconnected in a very interesting way. Usually when there is some interconnection between peripherals, it is interconnection realized using DMA. But PSoC offers more interesting connections between peripherals. There is system of routing output signals of peripherals to input signals of other peripherals. For example, you can route trigger from serial communication block (block responsible for serial buses like UART, SPI and I2C) notifying that byte was received over UART to start timer. You are not limited to forwarding triggers to DMA peripheral only. That is probably the concept from which the name came up. There is concept also interesting concept for routing analog signals. You can choose pins which you connect to integrated analog parts like comparators or ADCs.

 

My first impression was that PSoC is very versatile. There are lot of generic blocks and you can interconnect or program them independently. I will describe some of them later, but for example look at timers and counters. For example STM32F4 contains 8 timers of 4 different types. There are 2 advanced timers, another two timers are general purpose. General purpose timers have different interface, and you must control them little bit differently than advanced timer. Next, there are another two different general-purpose timers and finally there are two (also different) basic timers. Cypress chosen different strategy. PSoC 62 has 32 generic timers. All are same. You can choose whatever you want. Single difference is that 8 of them is 32bit while 24 of them are 16bit. Otherwise, they are totally the same. Similarly there are generic Serial Communication Blocks (SCB) used for serial buses like I2C, UART and SPI. There 12 pieces of that block. Single restriction is that some of them do not support SPI, otherwise the blocks are same. 13th SCB has same interface but remain running in deep sleep mode.

 

Clock subsystem

One of the best parts of the PSoC I consider his clock system. Other ARM microcontrollers (like STM32) usually have simple clock system with (usually one) PLL with ability to select one of input from the choice of internal inaccurate oscillator, external accurate crystal, or external clock and sometimes something else. Output of PLL is usually used as source for ARM Core and then it is used as clock for peripherals after basic configurable division. Cypress implemented much more advanced and flexible system in PSoC 6. Clock system is visualized in datasheet by following image.

Important parts are strong blue lines. They separate parts of clock system to three parts. First part is clock inputs, that is same as usual on other MCUs. IMO is Internal (inaccurate; 2% accuracy, some documentation mention 1% accuracy) oscillator. EXTCLK is external clock. ECO is External crystal oscillator. ILO is integrated low speed (32khz) oscillator. WCO is external oscillator (usually 32.768 kHz) for watchdog and some other low speed peripherals. This part of clock subsystem is quite common and there is nothing extra or missing.

 

Second part of clock subsystem is more interesting. There are two independent PLLs and one FLL. The multiplexers before the blocks enables you select the whatever input you want to that blocks. If you do not want modify input, you can bypass that block. This design enables you to generate multiple base high speed (or even low speed) clocks independently. You can configure one PLL to generate beautifully rounded 150 MHz clock derived from IMO and second PLL to generate accurate clock from ECO for audio peripherals. Second interesting thing is FLL. I have never seen FLL in MCU before. FLL does similar things like PLL but have some restrictions and some benefits. Main benefit is that it consumes less power than PLL. This is very good for low power designs. There are some restrictions to input and ratio of input and output clock frequency. Another advantage is that FLL starts faster than PLL. If you need for some reason to have MCU ready and running at high speeds very early after power-up FLL could be good choice.

 

Third part of clock subsystem is even better. There are 6 sections. There are 5 special peripherals requiring accurate and specific or high-speed clock. You can route any of clock created in second stage to source clock to that special peripheral. You can also use some division. The more interesting is first row. It shows routing of clock for both ARM Cores and peripherals. Clock to ARM Cores you can divided by any integer between 1 to 256 (there are no restrictions to power of 2). Especially dividing clock for CM0 should be useful in low power design.

 

Clock distributed to peripherals is also interesting. In STM32 there is APB bus (or multiple APB buses) and you have to choose one divider of main clock for all peripherals connected to that bus. This means that if timer and I2C block shares the same APB they must be clocked from the same clock. In PSoC it is designed differently (and much better). There are 29 clock dividers of 4 types. Except distinguishing 4 divider types the blocks are generic, and you can use them fully independently. There are 8bit dividers which can divide input frequency by any 8-bit integer number (divider is value + 1, because dividing by 0 does not make sense). For example, if you have input clk_peri set to 100MHz and you set divider to 42 (value 41 in register) you get clock of frequency about 2.38 MHz. Similarly, there are 16bit dividers to generate even slower clocks. Next two types of divider are fractional. There are 16bit and 24bit fractional dividers. They can divide frequency by value described by formula A + (B/32), where A is 16 or 24bit number and B is number in range 0 to 31. You have 29 blocks, so you can generate 29 different clocks for peripherals. You can attach any of generated clock to any peripherals or more peripherals. There are no restrictions about that. You can for example configure one 2.5 MHz clock and assign it to SCB running as SPI and Timer at once. At the same time, you can configure another divider to get 921.6 KHz and use it for another SCB running as UART with oversampling 8 (you get baudrate exactly 115200).

 

In my project 1 in low level variant, you can see how I configured clock subsystem in low-level using registry accesses. While system is complex It is not so hard. For normal use there is GUI utility that you can use to easily configure all clocks with interactive preview and automatic calculation of parameters for PLLs, FLL and dividers.

 

Clock system is great. I think that it is very useful when you develop low power application. Power consumption is typically expressed as µA/MHz so if you run some component at lower frequency then it consumes less. It is fine to configure every component of system to consume as low as possible and not be fixed for running multiple peripherals on very high frequency because another peripheral on the same bus requires it.

 

Address layout

Understanding address space layout is quite complicated on PSoC 62. Usually, MCU vendors choose addresses to make easy determining to which memory address belongs by interpreting first letter of address. For example, on STM32F4 flash addresses begins with 0x20000000, peripherals with 0x40000000 and 0x50000000, ARM peripherals addresses begin at 0xE0000000 and RAM addresses are short because begins with 0. Every time when you look at first letter of address you know where it is. On PSoC all addreses begins with 0, 1, 4 and E. Let’s look at the following screenshot from Modus Toolbox IDE.

 

It shows address of some variable and it is at address beginning with 8. But, wait. How It should start with 8 when I stated that all addresses start with 0, 1, 4 or E? Reason is that this address does not starts with 8 at first letter but it starts with omitted 0. If you look carefully it does not have 8 hexadecimal digits but only 7. So, the address does not start with 0x8 as presumed but it starts with 0x08. And finally, that address correctly maps to RAM according to following table from datasheet.

On PSoC memory ranges are little bit complicated and documentation is not clear. Datasheets mention some partitioning, but it contains only misleading and mostly useless information. In datasheet there are following two tables:

 

As you can see, first table states that SRAM is located at 0x20000000 address but second table states that SRAM is located at 0x08000000 address. If you look carefully to first table, you will see note that region 0x20000000 is not used in PSoC 6. In fact, term SRAM means something different in both tables. SRAM mentioned in second table overlaps with Code region in first table and it is correct but make less sense at the first look. If you read carefully note in first table, it contains information that Code range is memory which can be used for storing data and for executing code, so it matches description of SRAM (and some other memories). Finally, the second table which is more useful is incomplete because it does not contain address spaces between 0x18000000 – 1FFFFFFF which is used for mapping external serial memories (like FLASH and FRAM) to ARM address space. It also misses peripherals region at 0x40000000 and ARM peripherals region at 0xE0000000, but it is still more useful if you search for memories ranges.

 

Both previous tables come from Datasheet. TRM contains similar tables but little bit less confusing.

 

 

Look that there are completely different and correct description for region of 0x60000000 in first table. Second attempt to produce second table from Cypress is much better than attempt in datasheet but it is still wrong. Except typographical error in first row (missing space after dash) there is wrong end address of external memory. Range 0x18000000 – 0x08000000 does not make sense. Correct end address is 0x20000000.

 

Modes of operation

PSoC 62 supports two modes of operation – low power (LP) and ultra-low power (ULP). In low power mode core is powered by 1.1V and in ULP mode it is powered by 0.9V. In ULP mode chip consumes less energy but there are some restrictions about maximum frequency for ARM cores and some peripherals should not be fully used.

For power saving operations there are multiple sleep modes.

 

Performance

MCU has two cores. Main core is Cortex-M4 (CM4) which can run up to 150 MHz and additional CM0 which can runs up to 100 MHz. This is enough power to almost any embedded application. CM4 has floating point unit to hardware accelerate float operations. CM4 do not offer some more advanced instructions which are available in higher cores like Cortex-M7 but for most application performance is good enough.

 

Peripherals overview

MCU has lot of common peripherals. Most of them are commonly implemented in almost any ARM MCU on market. Some of them are unique. There are some system peripherals like mentioned watchdogs, memory protection units and cryptography engine. There are some digital commonly known peripherals like mentioned SCBs or Timers. There is also SDHC controller, block for driving serial memories (SMIF) and USB supporting Host and Device Mode. While Cypress offers dedicated USB controller they did not reused knowhow in this MCU. USB is only FS (12 Mb/s). There are also peripherals for digital audio. There are I2S and PDM to PCM decoder. PDM is bus usually used by modern digital MEMS microphones. And finally, there are analog peripherals. There are SAR ADC, comparator, analog reference, and integrated temperature sensor for monitoring chip temperature (note that normally chip itself do not produce any significant heat, event when running at highest frequencies. It produces less heat than STM32F429 with single core running at 180 MHz.

 

Now I will describe some unique peripherals of PSoC 62 and later I will describe peripherals which I am missing.

 

Unique peripherals

MCU has some unique peripherals which are very rarely seen on other platforms. First described is CapSense peripheral. It is used to bring touch control to application. It works very well, and I have shown it in one of my projects published as part of this review. This peripheral is not totally unique. There are multiple competing MCUs with similar peripheral. Similar quality capacity sensing like Cypress provide is available in MSP430 for example. But MSP430 is not a 32bit and it is not an ARM MCU. Other vendors usually do not provide support for any capacitive sensing or even they support it very briefly.

 

Second unique peripheral is profiler. It enables you count events from the core of MCU to troubleshoot some performance issues. It has nothing in common with debug tools part of ARM Cores like DAP or ETM. It should be useful when troubleshooting some rare performance issues. Reason for that is that PSoC is very complex system and there are many units using some shared AHB bus. To this bus there are connected ARM cores, peripherals, DMA, and memories. If this bus is blocked it should be used by another block only partially. Profiler enables you to determine how many times peripherals utilized this bus. It supports multiple profiling metrics. For example, you can track count of internal bus transfers caused by USB and SCB block. You can also track how frequently your application access flash memory. There is cache for flash memory, and you may be interested in optimizing application usage of that cache. For this task Profiler will also help you. I have never seen similar profiler on any other ARM MCU, but I think they will come early on other platforms. Complexity of ARM MCUs significantly grown over last years. As a result, new significant issues and challenges in applications are emerging. Profiler in PSoC enables you to resolve some of that issues easily.

 

Lastly there are LCD driver. It is not driver for any modern RGB LCD. It is driver for legacy segmented LCD displays. That displays were usually two colors (white and black, but background was usually backlighted to green or blue color). I consider it as unique because you can see it often in 8bit MCUs and not an ARMs. When competitor MCUs contains any display driver, It is usually driver do modern displays, not that legacy segment display. Driver for driving modern RGB TFT LCD displays I assigned to the section of missing peripherals. But PSoC should be used if you have some old design with that old LCD display used and you need to upgrade MCU. Note that this is driver for controlling raw segments. Some displays are shipped with driver chip that exports some parallel or I2C interface. This displays you can control with almost any display, even if they do not support any LCD. LCD driver is required because LCD technology requires pulse signal to work correctly. Otherwise, the display may be damaged by improper signal.

 

Missing peripherals

There are also some peripherals which We can see at competing platforms, but they are completely missing on PSoC platform.

 

The first described is Ethernet. Cypress targets the Wi-Fi IoT connection but if you need for some reason Ethernet, you probably rather choose another platform. Many other ARM MCU vendors like ST, NXP and Microchip offers integrated ethernet MAC for 100 Mb/s ethernet. You need to just add small external Ethernet PHY and then you can use Ethernet. If you want use Ethernet on PSoC 62, you should do that using some external solution like W5100 known from Arduino or ENC28J60 and similar. You can use Arduino ethernet shields for getting ethernet but you will need to port whole driver. You also will not get performance as good as performance of integrated MAC.

 

As mentioned in previous section there are no driver for any modern display. Other vendors usually have some display driver for transferring image buffer to the display and some more advanced MCUs have also some basic hardware accelerator (internally implemented as smart DMA) that can do some graphics operations against that buffer in memory. Cypress PSoC 62 (and I have not seen that in any other PSoC family) do not support that at all. Similarly, there are no interface for cameras as expected.

 

Currently we are seeing new generation of microcontrollers with DAC (digital to analog converter). DAC does not exists in PSoC 6 platform. DAC is available in PSoC 5LP but it is a little different family and do not share some concepts described above.

 

If you target automotive applications, you should also miss CAN controller. Interesting is that CAN controller is available in some other PSoCs. If you need CAN look for PSoCs matching name CY8C61x4, CY8C61x5 (these are PSoC 61 subfamily; they are one family lower than roadtested unit) or CY8C62x4 and CY8C62x5 (these are in the same family, have CAN controller, but have less RAM and FLASH).

 

Security features

Cypress consider lot of security threats in IoT applications and target focus on it. PSoC 62 supports cryptographic accelerator. Cryptographic accelerator can do symmetric (AES for example) and asymmetric (RSA for example) cryptography, calculate hashes (SHA for example) or can be reused to accelerate calculations of CRCs. Chip do not contain any secure storage of private keys. You must provide them carefully manually. PSoC 64 has more security features than lower PSoCs. It additionally contains secure boot features (checking firmware validity before booting) and contains some features like unique identifiers and keys generated at factory.

 

Crypto module is good but should be better if it supports secure storage for RSA/ECC private keys which cannot be exported outside that module. Requirement of providing key manually means that there are options to leak the key outside to chip. Because key is stored in RAM at least part time this means that any security vulnerability in your own firmware like buffer overflow can silently compromise you. Concept of secure chip that generate and store key in chip and do not allow export private key outside is much better, because even vulnerability in your firmware do not cause any leak of private key. Even when attacker gain access over your system, key is inaccessible for him and he is still unable decrypt previously sent messages. This concept is used in smart card and TPM chips. In ARM MCUs this concept is used very rarely. For example, Microsoft Pluton available in Azure Sphere follows that secure concept, but I have not seen any other ARM MCUs (in fact Azure Sphere also is not an MCU…) providing that security option for PKI usage.

 

PSoC 6 families

Now I will compare PSoC 62 presented on roadtested board with other PSoCs withing PSoC 6 family. Later I will compare with PSoCs across families. Even later I will compare with MCUs from different vendors. Differences between PSoC6 subfamilies are visualized in one of PSoC 6 brochure.

 

PSoC 62 is in the center of image. Image contains some reference to PSoC 60 but I never seen any PSoC 60 products and did not found any datasheet or other documents related to it. Maybe PSoC 60 value line chips will be released later but they are not mentioned in roadmap which I randomly found on Cypress website (https://www.cypress.com/product-roadmaps/cypress-psoc-and-microcontroller-mcu-portfolio-roadmap). You can downscale to PSoC 61. PSoC 61 lack Cortex-M0 core and lacks some powering modes. Except that It is very similar with roadtested PSoC 62.

 

Similarly, you can upgrade. In PSoC 63 you will get integrated BLE. Roadtested unit contains BT and BLE but it is provided by external module (CYW43012). PSoC 63 has BLE driver. I never read any note about support for standard (not low energy) Bluetooth. I think that integrated module does not support that BT mode, but double check that If you are interested in it.

 

PSoC 64 subfamily adds additional security features which I mentioned in previous section.

 

Comparison with other Cypress MCUs

Cypress provides 5 PSoC families. PSoC 1 and PSoc 3 are 8bit MCUs. PSoC 1 is based on Cypress proprietary core. PSoC 3 is based on 8051. Interesting is that PSoC 3 can run at very high speeds than I have never seen on 8051 before. It can run up to 67 MHz so you can consider this family as good upgrade of older 8051. I won’t compare to this families much because it does not make a lot sense to compare complex ARM MCU with 8051 MCU.

 

Additionally, there are three ARM PSoC families. PSoC 4 (Cortex-M0), PSoC 5LP (Cortex-M3) and PSoC 6 (Cortex M4 + optional M0).

 

After researching on PSoC 4 ad PSoC 5LP I made opinion that PSoC 4 and PSoC 6 are designed by the same team and PSoC 5LP is designed by completely different team independently. PSoC 4 and 6 shares some concepts, documentation is similar, and some peripherals are reused. Clock system has similar structure to PSoC 6 but has lower features. In opposition PSoC 5LP use different peripherals. For example, there are no concept of generic serial communication blocks described in previous section of this article. It has also peripherals that are not available in both PSoC 4 and PSoC 6. For example, it contains DAC, Sigma delta ADC and It has native EEPROM (PSoC 4 and 6 enables EEPROM emulation using FLASH). Clock system of PSoC 5LP is also completely different. Last difference of PSoC 5LP to 4 and 6 you have probably noticed – It follows different naming convention.

 

At the beginning of roadtesting ModusToolbox supported only PSoC 6. Later Cypress bring support for PSoC 4 also. PSoC 4 got early prereleases of PDL and HAL library known from PSoC 6. While libraries are very similar there will not be any official compatibility. I asked about it on GitHub (https://github.com/cypresssemiconductorco/mtb-example-psoc4-empty-app/issues/1). PSoC 5LP is not supported for now and there are no indices that this should change early. Cypress also do not publish anything related to PSoC 5LP on GitHub. If you search “psoc6” you will receive 99 repositories (number is valid at 2020-12-25). If you search psoc5 or psoc5lp you will receive 0 results as mentioned (number is also valid at 2020-12-25) and finally, If you search “psoc4” you will receive 34 repositories (number is valid also at 2020-12-25). I found some examples for PSoC 5LP at Cypress website. They probably come from PSoC Creator and they use completely different library. So, I think there are no possibility to migrate code between PSoC 6 and 5LP.

 

Comparison with PSoC 4

PSoC 4 is very similar to PSoC 6 as mentioned before but has less features. It for example miss FLL and PLL in clock system but system of clock dividers for peripheral remains. It has no high-speed memory buses for SDHC and SMIF. Generic TCPWMs (Timers) and SCBs remains. There are different count of that modules and it probably differs per MCU model. CapSense, SAR ADC and legacy LCD driver remains. PSoC 4 has more flexible powering options. While PSoC 6 is restricted to VDD supply between 1.71V to 3.6V (which is common for ARM MCUs), PSoC 4 has extended power supply range to 5.5V. If you have something what needs run at 5V you can do that with PSoC 4 (and not 6). PSoC 4 also do not support switching between LP and ULP mode. Powering of PSoC 4 is probably implemented totally differently than it is implemented in PSoC 6. It is probably because PSoC 6 requires more power. At the last PSoC 4 can run at much lower frequency than PSoC 6. PSoC 6 can run his M4 core at 150 MHz and M0 core at 100MHz. PSoC 4 can run his single CM0 at maximum of 48 MHz.

 

To summarize: Consider PSoC 4 as little brother of PSoC 6.

 

Comparison with PSoC 5LP

PSoC 5LP is quite different than PSoC 6 as mentioned before. PSoC 5LP have different clock system. Clock sources are like PSoC 6 but for example IMO (integrated inaccurate oscillator) is not fixed to 8 MHz, but It is configurable. There are PLL but no FLL. Concept of peripheral dividers partially remains but fractional dividers are not available (note that they are available in lower number PSoC 4). There are no generic SCB. Instead of SCB there are dedicated peripheral for I2C and other buses should be done using Universal digital block. Universal digital block is concept that I have seen also in PSoC 4 but not in roadtested PSoC 6. PSoC 5LP can be powered in range 1.71V to 5.5V like PSoC 4. I have not seen any power modes like LP/ULP mode in PSoC in documentation. PSoC LP has Cortex-M3 core which can be clocked up to 80 Mhz which is about half of maximum clock frequency of PSoC 6. Also note that Cortex-M3 has no floating-point instructions so If your application work frequently with floats PSoC 6 should be much faster than just twice (twice because of 2x higher frequency).

 

Migration opportunities within PSoC 62 subfamily

As mentioned in previous sections code migration between PSoC 62 is possible because software is developed using same PDL and HAL library. But there are some restrictions. Even PSoC 62 is split into even smaller subfamilies. You can determine that smaller subfamilies by 4th number/letter in name. They are following three subfamilies within PSoC 62 subfamily:

 

  • CY8C62x6 and CY8C62x7 (4th letter is 6 or 7)
  • CY8C62x8 and CY8C62xA (4th letter is 8 or A)
  • CY8C62x5 (4th letter is 5)

 

For example, family with names ending with 6 a 7 contains Universal digital blocks mentioned in one of the previous sections while higher subfamily with 8 and A does not contain it (or it is not described in datasheet).

 

Another example is that MCU ending with 5 in name supports only one PLL in clock system. If you design application using roadtested board and rely on two PLLs, you cannot downgrade to MCUs with name ending by 5. In opposition subfamily with 5 at the end of name is the single PSoC 62 subfamily featuring CAN as mentioned before.

Also note there are no footprint compatibility. 8 and A variants are mostly available in different packages than 5, 6 or 7 MCUs are.

 

To summarize: You can basically migrate within PSoC62 subfamily but rather check datasheet carefully if you migrate for example from A to 7 MCU.

 

Migration opportunities within PSoC 6 family

Migrations between subfamilies (for example from 62 to 64) is very similar to migration withing PSoC62 subfamily as described in previous section. I consider it as mostly possible but not a fully seamless.

 

Migration opportunities between other PSoCs

Migration between PSoC 4 I consider partially possible because of support for very similar PDL and HAL library. Migration to/from PSoC 1, 3 and 5LP I consider totally impossible without starting writing code from scratch.

 

Migration between 3rd vendor MCU

If you use MBED environment and do not use platform specific things much, you can partially migrate with low number of changes needed. But If you for example use STM32 HAL driver within STM32CubeIDE you cannot easily migrate to any PSoC.

 

Comparison with other ARM Cortex-M MCUs

Now I will compare roadtested PSoC 62 to similar ARM MCUs. Note that PSoC 62 you usually select not just by MCU properties but by platform itself. For example, If you develop IoT system and time to market is critical for you, PSoC 62 is always better choice than any other MCU family mentioned below. It is because of great IoT ecosystem provided by Cypress. I will usually describe only properties that defeats PSoC 62, because that are reasons to select that family over PSoC 62.

 

For comparison I choose only MCUs in similar category. I usually choose random model from the family when researching. Requirements was:

 

  • Dual core
  • Maximum clock frequency of main core between 100 – 250 MHz.
  • It is not a MPU and it have no Cortex-A core

 

I did not apply any other restrictions. I did not research for all MCUs from all vendors at the workd (because there are probably thousands of that) but I selected only MCUs from big vendors. I selected chips in following families which meets (STMs only partially) rules mentioned above.

 

  • LPC4300
  • Atmel/Microchip SAM4C
  • STM32 WB and H7

 

Comparison with LPC4300

As the first competing family I chose LPC4300 because it matches the PSoC 62 in lot of parameters. LPC4300 similarly to PSoC 62 contains two cores. One is Cortex-M4 and secondary core is Cortex-M0. Both can run at 204 MHz which is about 25% faster than PSoC 62. LPC4300 contains all peripherals mentioned in Missing peripherals section of this article. It contains integrated Ethernet MAC, driver for modern TFT LCD displays and contains DAC. But it misses some Cypress exclusive features like CapSense. It is also designed in a more common way for microcontrollers. There are very few generic blocks. There are also less timers (5 timers in opposition to 32 in PSoC 62) and there are also no generic serial communication blocks. There are very few dedicated blocks in comparison with PSoC. You cannot use more than 2 independent I2C buses (PSoC 62 supports 13), more than 1 SPI (PSoC 62 supports 9) or more than 4 UARTS (PSoC 62 supports 12).

 

To summarize: if you need CapSense use PSoC 62. If you need ethernet or TFT LCD display driver use LPC4300. Otherwise, it depends on other circumstances and peripheral requirements.

 

Comparison with SAM4C

Atmel (now Microchip) SAM4C contains two Crotex-M4 cores. Both can runs at 120 MHz and one of them has floating point unit. Expect similar performance to PSoC 62. SAM4C will not bring you missing peripherals mentioned above. It has similar peripherals to PSoC 62 but as expected there are no Capsense and there are no generic peripherals. There are few timers and serial bus drivers. There is no external memory controller for accessing serial FLASHs and FRAMs. But SAM4C is much cheaper. Official listed price is a half a price of roadtested PSoC 62 price. I did not find any significant benefit of SAM4C over PSoC 62 except price and availability. This family is not listed at Microchip MCU navigation. Datasheet has no update since acquisition of Atmel and there are no successors for that chip.

 

Comparison with STM32 WB and H7

STM32WB and STM32H7 are also dual core ARM MCUs. Both do not match my criteria (WB is so slow and H7 is so fast) but I assigned them there also.

STM32WB competes much more with PSoC 63 rather than 62 because of integrated BLE. Secondary core of STM32WB was designed to offload wireless stack. It contains less features than other STM32 families and it also does not bring you any peripheral which I miss in PSoC 62. It has less timers and less serial bus controllers. Of course, it does not have any touch control controller. At last, it can run much slower. Both cores of WB can run at 64 MHz only.

 

In opposition STM32H7 is much more performant and supports much more peripherals. Its main core is not Cortex-M4 but it is Cortex-M7 and Cortex-M4 is secondary core there. CM7 runs at 480 MHz and CM4 runs at 240 MHz. Because that I think comparison is not fully correct. H7 is different category of MCUs, I think. STM32H7 brings you all mentioned missing peripherals. It has Ethernet MAC, controller for modern displays, hardware accelerator for 2D operations on display buffer and it has also hardware accelerated JPEG codec. It has also camera interface. None of that you can easily get on any PSoC. H7 Supports 22 timers of different features. Serial interfaces are provided by specific blocks. It is not so flexible but totally it makes similar number of serial interfaces that you can use on PSoC 62. It does not support any touch controller (very few STM32s support that) like CapSense. ST also have no support for Wi-Fi IoT applications in their environment. You will have to implement lot of things manually If you need Wi-Fi. There are some community ports of some Wi-Fi platforms, but they are not as seamless as Cypress’s solution is.

 

To summarize: Both STM32WB and STM32H7 are incomparable with PSoC 62. Decision depends on your needs.

 

Availability and price

As last part of this chapter I will have some notices about availability and prices of PSoC 62.

 

As briefly described in migration chapter, each subfamily of PSoC is available in quite different packages. Roadtested unit PSoC 624A (A at end) is available in 3 different packages. It is 124 pin BGA, 128 pin TQFP and 100 pin WLCSP. BGA variant is used on roadtested board. Chip with the same features is also available in both TQFP and WLCSP packages. Most models are in BGA packages. Sometimes there are no non-BGA alternative. Because I am hobbyist, I like TQFP packages because I can solder them in hand. Cypress offers them and resellers sells them, but most chips are BGA.

 

Roadtested unit with full name CY8C624ABZI-S2D44 has no price listed on official Cypress website and is available only at Mouser (Newark/farnel do not lists it, at least at the time of writing that review). Price is $21.72 for one piece and $13.13 if you buy batch of 1000pcs. You will wait about 15 weeks for that. You can buy this model in quantity of 1pcs. Similar variant with the same features but in TQFP package (CY8C624AAZI-S2D14) has listed price on Cypress website as $9.60 is you buy one piece and $7.31 if you buy 1000pcs. Newark/Farnell also do not offer it. Mouser offers it for $15.03 if you buy 1 piece and $9.08 if you buy 1000pcs. I think that difference $6.69 between the same chip in different package is so high. I think that $9 listed at Cypress website is good price for that chip but $21 for which is chip offered in real is so high. It is about 1/5 of the price for whole development board! And really, the MCU is not the most expensive component at the board. Also note that there is no stock availability at the time of writing this review. This may significantly limit you when choosing PSoC 62. I think it is because PSoC 62 is quite new and the stock availability appear over time when capacity of Cypress factory allows making some CY8C624ABZI-S2D44 models.

 

When I researched for other PSoC I multiple times look for some other PSoCs, especially PSoC 4. Their price is also much overpriced at resellers. Stock capacities are better, but I have also seen lot of models with 0 pcs in stock. I have seen multiple times restriction to buy at least 250 pcs. Because I am hobbyist, I do not like it. I usually buy MCUs at quantities less than 10pcs (usually only 1 piece) and that requirement makes me unable from buying that. Sometimes I also felt that resellers offer very few of Cypress’s MCUs in opposition to STM32s for example.

 

Lastly because I am student, I researched for some opportunity to get free samples of chips. Samples are efficiently unavailable to students. Cypress have website designed for universities, but it does not bring any opportunity to get free samples for student projects.  For example, Microchip sends me any chip I request (it is limited by quantity) for student projects.

 

To summarize: PSoC 624A is good MCU. It has great design, features powerful clock system and good generic universal peripherals in big quantities. You will probably face to unintuitive naming of chips, families, and subfamilies (in fact, name of the development board itself is also crazy as mentioned in chapter “Review of development board”). It is hard to buy, very few resellers offer it and price is high at the time of writing. But technically it is good, and I like that MCU.