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
- Intruction, Table of Contents, Overview of Table of Contets
- Review of Development Board
- Review of Microcontroller
- Review of Wi-FI and BT Module (this article)
- Review of Onboard Peripherals
- Review of Onboard Programmer and Debugger
- Review of Development Software
- Review of Documentation
- Project 1 - Serial Interfaces
- Project 3 - FRAM
- Project 4 - CapSense and Bluetooth
- Project 5 - Dual Core Application
- Project 6 - Profiler
- Summary and Score
Review of Wi-Fi and BT module
As part of main module there are Wi-Fi + BT chip Murata Type 1LV. This chip contains CYW43012 chipset. Chipset is originally designed by Broadcom, but Cypress acquired division responsible for that chipset.
Review of Wi-Fi and BT is only brief. It is very complex system, and it is usually used at very high level of abstraction. I have done multiple test projects that uses this module. I have no tools to test properties resulting from analog and antenna design. There are two of my test projects published. First shows IoT application using cloud services, and second project shows Bluetooth Low Energy (BLE).
In the datasheet you can find following block diagram.
From that diagram we can see that BT and Wi-Fi parts are independent. Each part has own ARM Cortex-M core. Wi-Fi part is controlled by CM3 running at 80 MHz and BT part is controlled by CM4 running at 48 MHz (diagram specifies 96 MHz, but later in text there are note that It runs only at 48 MHz because Cypress did not test anything else and their SDK do not use higher frequency. Do not confuse cores with cores presented in main MCU. These cores are used only for running internal firmware for controlling antennas transmitters and receiver and controlling other parts of that chip.
Second important part of that block diagrams are external interfaces to communicate with chip. Bluetooth side supports some wakeup signals, UART, SPI, PCM, I2S and some GPIOs. That are interfaces supported by chipset. Not all signals are connected from the chipset outside module to the board or main MCU. One wakeup signal is connected to MCU, second is unconnected. UART (and probably also SPI, but it is not mentioned in documentation explicitly) is connected to MCU and is exported from the module to unsoldered connector also. I2S is not routed to MCU directly. It is routed to unsoldered connector If you want to use it. I think you can use it If you want do audio related Bluetooth application. But if you want to process audio using main MCU you must manually wire it from unsoldered connector to expansion port because it is not internally connected to MCU. PCM is not available at all. And GPIOs are available thru unsoldered connector and they are not routed to MCU. So, only UART is routed to MCU and other buses (except PDM) are available thru extension port If you want to use them.
Communication with Wi-Fi side is mainly done using SDIO, UART and GPIOs. SDIO is connected to MCU and not exposed on board. It makes sense because it is high speed bus and signal integrity is important. In opposition UART is exposed on board but it is not connected to MCU. There is also JTAG which is not designed to be used by anyone. It is exported on unsoldered SMT connector available at bottom side of board.
I was thinking about it. I think that It make sense. For BT there are UART which you can drive from the main MCU or If you want evaluate module by another external platform you can access it by soldering missing connector. Similarly, Wi-Fi is accessible by SDIO from main MCU and If you want to evaluate it by another external platform, you can do that using UART exposed on the same normally unsoldered connector.
I used Wi-Fi only with high-level libraries. It is very easy to use it within Modus Toolbox environment. There is good documentation with examples. Also, there are lot of example projects available in project creation dialog.
Modus Toolbox contains ported lwIP library so If you have used it in some app (no matter if Ethernet or Wi-Fi) you can easily port your code.
I briefly tested Wi-Fi performance. I have done simple project, that connects to the Wi-Fi, creates TCP socket with my local computer and using simple GET HTTP request downloads 10 MiB file from server (my computer). Data are just downloaded to buffer and not processed in any way. I measured how long does it takes to download file. Nota that downloaded file is 10 MiB while MCU has only 1MiB of RAM. Consider it as synthetic test rather than real world example.
I have created similar project also for ESP8266 using ESP8266 RTOS SDK and for ESP32 using ESP-IDF. All codes were totally unoptimized. I tested just performance what you can get when you create app in hurry and do not worry about performance much. I use sockets on both platforms even If their SDKs offers better tools for working with HTTP.
Please note that it is not fully correct comparison. ESPs have different architecture. In ESPs design I run code as part of module and there was no transfer to another MCU outside chip. In design using Cypress board there were such transfers between chip and MCU. In opposition Cypress solution do not share resources between 802.11 related code and user application.
On Cypress platform I tested how speed of main MCU affects performance. I tested three variants which different speeds of main CM4 core and speeds of peripheral bus. Following table described test that I have done.
Cypress Test 1
Cypress Test 2
Cypress Test 3
Tests ran 10 times on each platform and configuration. Main speed is calculated in unit KiB/s but because in networking there are more common speeds in bits rather than bytes, I recalculated speed also to Kib/s. Because speed in bit reaches range to Mib/s I also recalculated speeds to Mib/s instead of Kib/s.
All testing source codes for all 3 platforms are available to download at the end of article.
Results are following
Number of tests
Min time to download (sec)
Max time to download (sec)
Avg time to download (sec)
Avg byte speed (KiB/s)
Avg bit speed (Kib/s)
Avg bit speed (Mib/s)
As you can see speed of PERI clock domain has no impact (I realized that SDIO bus between MCU and Wi-FI chip is probably clocked from other clocks later after test …). Speed of main MCU has also minimal impact. But as you see module was much faster than Chinese concurrency in that very unoptimized synthetics test. CYW43012 is about 1.73x faster than ESP8266 and about 1.45x faster than more modern ESP32 concurrency.
I think the results are good for CYW43012. You cannot expect performance of network card of your notebook. It is still just embedded system with very reduced performance. I think that performance is enough for almost any nowadays embedded system and there usually are other limits like CPU processing speed rather than bandwidth of wi-fi chip.
Bluetooth is also very easy to use. Cypress provides good library for that and ModusToolbox contains utility to generate lot of structures needed to successfully communicate over Bluetooth. You can see my project 4, which shows how to use Bluetooth in LE (low energy) variant. Module supports also normal Bluetooth If you want to use it instead of limited LE variant.
To summarize: I am satisfied with both Wi-Fi and BT. It is easy to use and performance is good.