Skip navigation
Home > All Places > Topics > Cypress Community Blogs > ModusToolbox Blog > Blog > Authors NidhiH_76

ModusToolbox Blog

3 Posts authored by: NidhiH_76

ModustoolBox (MTB) 2.2 brings with it a new unified workflow for applications. In ModustoolBox 2.0 or ModustoolBox 2.1, BTSDK apps had a different workflow than PSoC6 SDK apps, but with ModustoolBox 2.2, apps using PSoC6/BTSDK/AnyCloud SDK follow the same workflow.

In addition to the unified flow, there are some improvements available in MTB 2.2 such as added flexibility in how libraries are managed.

It’s necessary to make some changes in MTB 2.0/2.1 BTSDK applications to start using the unified flow in MTB 2.2. This blog will give you migration steps for BTSDK apps from MTB 2.0/2.1 to MTB 2.2

 

Before we move on to the steps for migration, there are some points to note:

  1. An MTB 2.0/2.1 workspace containing BTSDK app and wiced_btsdk 2.7.1 can be used with MTB 2.2 to build/program. If you want to access the library manager features of MTB 2.2, then you must upgrade your application to work with the MTB 2.2 flow.
  2. If you are using wiced_btsdk 2.7 or below but have updated to MTB 2.2, applications might break for some BSPs while using MTB 2.2 tools. The solution is to update to wiced_btsdk 2.7.1, or even better, migrate the app to the MTB 2.2 flow.
  3. BTSDK MTB 2.1 CEs are not compatible with MTB 2.2.

 

What has changed in BTSDK app structure in MTB 2.2?

 

  1. The first change you will notice is the option to create required apps from the BLE, mesh or HAL group. With MTB 2.1, all apps were created from a given group with no choice. Figure 1 shows the difference in the list of apps for the BLE CE group.
    Fig1.png
    Figure 1.  MTB 2.0/2.1 CE list(left) and MTB 2.2 CE list(right) in Project Creator

  2. In MTB 2.0/2.1, the wiced_btsdk repo needed to be cloned into the workspace before creating the application. In MTB 2.2, there is no need to create wiced_btsdk prior to the creation of app. The BTSDK apps include .mtb files for the Board Support Package (BSP) and the required libraries for the BSP are automatically detected and cloned into the shared library folder (mtb_shared) or in the libs folder in the project. Figures 2.1 and 2.2 show the difference.
    fig2.1.png
      Figure 2.1. MTB 2.0/2.1 workspace vs MTB 2.2 BTSDK workspace

    fig2.2.png
    Figure 2.2. MTB 2.0/2.1 BTSDK CE folder vs MTB 2.2 BTSDK CE folder

  3. The BSP and libraries can be shared or can reside locally in the project. When we say shared, it means that, all the apps created in the same workspace will use the same copy of the common libraries from the mtb_shared folder. New copies of the same shared libraries are not created for every new app. Use library manager 1.2 to make a BSP/library local or shared as shown in Figure 3 by selecting/deselecting the shared checkbox.
    fig3.png
    Figure 3. Screenshot of library manager 1.2 to select a BSP/Library and make it shared or local

    If the BSP/library is shared, it will be created in the mtb_shared/wiced_btsdk folder. If the BSP/library is not shared, then it will be created in the libs folder in the project.


Steps to migrate an MTB 2.0/2.1 BTSDK application to the MTB 2.2 workflow

 

  1. Makefile Changes
    The makefile has changed significantly for BTSDK applications. Download the makefile and make changes to the following makefile variables according to your app:
        a. TARGET – the default target
        b. APPNAME – name of your project
        c. Copy any other app specific makefile variable from your MTB 2.0/2.1 CE makefile
        d. Save the makefile with the changes
        e. Copy this makefile and replace with the existing one in your app folder

  2. Adding deps folder and BSP/libraries to the application
    Library manager 1.2 must be used to add or update any BSP or libraries. Launch the library manager 1.2 tool from the start menu or go to the MTB installation folder and navigate to this path: ModusToolbox\tools_2.2\library-manager. From here launch the library manager 1.2 tool.
    a. Select the directory of your application using the browse option as shown in Figure 4.
    fig4.png
    Figure 4. Screenshot of Library Manager 1.2 highlighting the ‘browse’ option

    Alternately, from the command line (modus-shell on Windows or from a command window on MacOS or Linux), navigate to the project directory and enter “make modlibs”. This will launch the library manager and will provide the correct directory.

    b. Next, select the required BSP from the ‘BSP’ tab. The dependency libraries are selected automatically. Select any other required libraries (ex: mesh, HID etc…) from the ‘Libraries’ tab.
    c. Click on the update button at the bottom right corner of the library manager. Wait for it to successfully update the BSP and libraries.

    d. Close the library manager. Now you can observe that in your project folder two new folders called deps and libs are added. Deps and libs contain the .mtb files of the BSP/libraries you selected in previous step and the dependency libraries, respectively.
    e. In the project directory, you can see that a new folder called ‘mtb_shared’ is created. If you navigate inside the folder into wiced_btsdk, you can see the BSP/library folders downloaded. This is the shared library that we talked about earlier in the blog.

  3. Update the Readme file of your project if required.
  4. Update the .gitignore file in your app if present. You can refer to the example .gitignore file. This is useful if you are maintaining your project on github.
  5. Open the .cybt  file present in your app with bt-configurator 2.20.0 tool (can be launched from the start menu or found in the MTB installation folder: ModusToolbox\tools_2.2\bt-configurator). Check the notice list in the bt-configurator for any changes required. If required, do the necessary changes and save the file.
    Alternately, from the command line (modus-shell on Windows or from a command window on MacOS or Linux), navigate to the project directory and enter “make config_bt”. This will launch the Bluetooth configurator and will open the .cybt file.
  6. All required changes have now been done for your app to work with the MTB 2.2 unified workflow. If desired, you can import your project into the Eclipse IDE for MTB 2.2 using the Eclipse IDE for MTB 2.2 menu item File > Import > ModusToolbox > ModusToolbox Application Import.
  7. Now you can build/clean/program/debug your application from the IDE and use any MTB 2.2 tool. You can use library manager 1.2 to update your app to use local/shared library or add/remove any BSP/library.

 

IMPORTANT NOTE

With wiced_btsdk 2.8, if you add more than one BSP to a project, the build will result in an error. Refer to the Bluetooth SDK 2.8 Release Notes.

To work with a different BSP, use library manager and remove (deselect) the older BSP, select the new BSP and update. Note that in a single project you can have only the BSP/BSPs of the same chip, but in a workspace if you have two or more projects, each one can use a different BSP.

This blog has the details of benchmark test performed for BLE GATT Throughput between Cypress BT SoC CYW20820/CYW20721 and different Android and iPhones.

The firmware used to perform the measurement is available on GitHub as a Code Example. Go through the Readme file associated with the code example to get a quick understanding of BLE throughput and the parameters used to tune it. Using this code example, you can easily perform the throughput measurement on your own with just a BT SoC based Cypress kit and your phone!

 

Let’s get started by checking out how the benchmarking is done.

 

Test Setup

To conduct this activity, CYW920820EVB-02/CYW920721EVB-02 were used as BLE GAP Peripheral and GATT Server with custom throughput measurement service. The iPhones and the Android Phones listed below were used as a BLE GAP Central and GATT Client:

  • Google Pixel 3
  • Google Pixel 3A                                
  • Samsung Galaxy S8
  • Samsung Galaxy S10 Plus
  • iPhone X
  • iPhone 11

The measurements were done for both 1M and 2M PHY. An MTU size of 515 was exchanged between both the devices and DLE(Data Length Extension) was enabled. The BT SoC is programmed to send a request for connection interval of 26.25 ms, but the interval chosen depends on the Central device. Ellisys Bluetooth Sniffer was used to collect BLE air logs for all measurements.

The data traffic is only one way, i.e., GATT notifications from the BT SoC (Tx) to the smartphone (Rx). But the code example can operate for two more modes of data traffic; First mode is where, the data traffic from smartphone (Tx) to BT SoC (Rx) and the second mode mode is where, the both the Tx and Rx operation of data happen simultaneously on both the devices. For these two modes, we need a custom feature in Android/iOS CySmart app which can send frequent, automated GATT write/notifications. The android/iOS apps currently available on Playstore/Appstore do not have this feature. So, the values presented here are for GATT notifications from BT SoC to smartphone.

 

Throughput rates for 2M PHY

The below table summarizes the results obtained for 2M PHY:

 

Test ID

BT SoC -> Phone

MTU

Connection Interval

BLE GATT Throughput

1.

CYW20721 -> iPhone 11

515

26.25 ms

311 kbps

2.

CYW20721 -> iPhone 11 Pro

515

26.25 ms

365 kbps

3.

CYW20820 -> iPhone X

515

26.25 ms

340 kbps

4.

CYW20721 -> Google Pixel 3

515

45.00 ms

1236 kbps

5.

CYW20721 -> Samsung Galaxy S10 Plus

515

26.25 ms

1222 kbps

6.

CYW20820 -> iPhone X

247

26.25 ms

362 kbps

7.

CYW20820 -> Google Pixel 3A

247

45.00 ms

1303 kbps

8.

CYW20820 -> Samsung Galaxy S8

247

26.25 ms

1320 kbps

Note: The throughput values are averaged for 15 readings.

 

By now, you might have observed that with the iPhone, we get a lesser throughput (with the same parameters exchanged) compared to Android. This is because, iPhone which is the LL master in the connection, is terminating the connection event length in a connection interval. Let us compare one connection interval captured by the sniffer for both Android and iPhone to understand this:

 

  One connection interval (26.25 ms) for Android: Samsung Galaxy S10 Plus

Screenshot (391).png

   

   One connection interval (26.25 ms) for iPhone: iPhone 11

Screenshot (390).png

 

Notice that, in case of Android, most of the interval (25 ms) is utilized for data transfer, whereas, in case of iPhone, the connection event is terminated by Central after 7 ms from start of the interval. 

This means, the remaining air time is wasted and not utilized for data transfer. This is the reason, for lesser throughput in case of iPhone for the negotiated parameters.

 

Throughput rates for 1M PHY

The below table summarizes the results obtained for 1M PHY:

 

Test ID

BT SoC -> Phone

MTU

Connection Interval

BLE GATT Throughput

1.

CYW20721 -> iPhone 11

515

26.25 ms

130 kbps

2.

CYW20721 -> iPhone 11 Pro

515

26.25 ms

82 kbps

3.

CYW20820 -> iPhone X

515

30.00 ms

160 kbps

4.

CYW20721 -> Google Pixel 3

515

45.00 ms

527 kbps

5.

CYW20721 -> Samsung Galaxy S10 Plus

515

26.25 ms

222 kbps

Note: The throughput values are averaged for 15 readings.

 

Ellisys Sniffer Logs

A look into the Instant Throughput graph of entire data traffic captured by Ellisys Sniffer:

                                                         

                                                             CYW20721 -> Google Pixel 3

Screenshot (387).png

 

Three Ellisys log files are attached with this blog for reference:

  1. Ellisys Sniffer logs for CYW20721 -> iPhone 11 (1M)
  2. Ellisys Sniffer logs for CYW20721 -> Google Pixel 3 (2M) and Samsung Galaxy S10 Plus (2M)

This blog captures the BLE GATT throughput rates obtained with CYW208xx device in two scenarios, first scenario is where we have only BLE traffic in the 2.4 GHz frequency band and second scenario is where we have both WLAN and BLE sharing the medium. Before diving into the performance rates obtained, let us understand more about BLE GATT Throughput which is the performance criteria considered for the measurements.

CYW208xx Cypress device is qualified for the Bluetooth 5.0 standard. Bluetooth 5.0 claims a maximum BLE throughput of 2 Mbps. But in a practical case, in a BLE data packet, if we consider only the payload (the application data which we wish to send to the other device) and remove the header bytes which get added from lower layers of the BLE stack in the packet, the maximum throughput we get is less than 2 Mbps. We can understand it like this:

 

GATT throughput is a reflection of application data that can be sent or received per second using BLE.

 

There are certain BLE parameters which we must tune to get maximum BLE data throughput. For example, if both the communicating devices support 2M PHY, we can get double the data rate compared to 1M PHY. Connection Interval, Data Length Extension, ATT MTU are some other major factors which decide the throughput we obtain. To understand more about GATT throughput, the BLE parameters and how they control the throughput, refer BLE Throughput Measurement Code example and the associated README document from Cypress.

Now that we have a picture of performance criteria, let us move on and see the Throughput rates obtained with CYW208xx.

 

Scenario 1: BLE traffic in the medium, between two CYW208xx devices 

In this scenario, we measure BLE throughput between two CYW208xx devices. One is configured as GAP Peripheral/GATT Server, another is configured as GAP Central/GATT Client. The below measurements are carried out in a typical office environment. Throughput is measured for three cases:

 

Case 1: GATT Server TX – GATT Client RX

GATT Server continuously sends GATT notifications to GATT Client device. A GATT Throughput of 1335 Kbps is obtained in this case.

Case1_tput.PNG

 

Case 2: GATT Server RX – GATT Client TX

GATT Client continuously writes data into GATT Server data base. A GATT Throughput of 1335 Kbps is obtained in this case.

Case2_tput.PNG

 

Case 3: GATT Server TX/RX – GATT Client RX/TX

This case is a mixture of case 1 and 2. GATT Server continuously sends notifications and GATT Client continuously writes into GATT Server’s data base. In this case, each device simultaneously sends and receives data. A GATT Throughput of 745 Kbps is obtained in this case.

Case3_tput.PNG

 

Scenario 2: WLAN and BLE using Cypress Serial Enhanced Coexistence Interface (SECI)

This scenario is an example to show the rates in a Wi-Fi/BT co-existence environment. The setup consists of a Cypress wireless SoC CYW54907 with CYW20819. The two chips use SECI to communicate and utilize the air medium optimally. To get decent WLAN rates, while using BLE Throughput measurement application, BLE throughput is set to around 20 Kbps by changing PHY and MTU. Note that, according to user application, both the WLAN and BLE rates can be tuned according to requirement. Effective usage of bandwidth is important in co-ex cases rather than obtaining maximum throughput.  

 

seci.PNG

Case 1:  Wi-Fi TCP data download and upload

WLAN TCP data throughput obtained with both BLE GATT Server and GATT Client throughput measurement application tuned at 18 – 20 Kbps.

The following table shows the rates obtained:

 

Use Case

Data Traffic

WLAN Throughput in Mbps

BLE Throughput in Kbps

1

Wi-Fi TCP data download + BLE GATT Server TX

30

18

2

Wi-Fi TCP data upload      + BLE GATT Server TX

40

18

3

Wi-Fi TCP data download + BLE GATT Server RX

29

19

4

Wi-Fi TCP data upload      + BLE GATT Server RX

38

19

5

Wi-Fi TCP data download + BLE GATT Client TX

29

20

6

Wi-Fi TCP data upload      + BLE GATT Client TX

35

20

7

Wi-Fi TCP data download + BLE GATT Client RX

30

18

8

Wi-Fi TCP data upload      + BLE GATT Client RX

37

18

 

 

Case 2: Wi-Fi UDP data download and upload

WLAN UDP data throughput obtained with both BLE GATT Server and GATT Client throughput measurement application tuned at 18 – 20 Kbps.

The following table shows the rates obtained:

 

Use case

Data Traffic

WLAN Throughput in Mbps

BLE Throughput in Kbps

1

Wi-Fi UDP data download + BLE GATT Server TX

43

18

2

Wi-Fi UDP data upload      + BLE GATT Server TX

51

18

3

Wi-Fi UDP data download + BLE GATT Server RX

42

19

4

Wi-Fi UDP data upload      + BLE GATT Server RX

49

19

5

Wi-Fi UDP data download + BLE GATT Client TX

47

17

6

Wi-Fi UDP data upload      + BLE GATT Client TX

49

18

7

Wi-Fi UDP data download + BLE GATT Client RX

43

17

8

Wi-Fi UDP data upload      + BLE GATT Client RX

49

18

 

Filter Blog

By date:
By tag: