Every year, more and more smart speakers, smartphones, mobile devices, fitness trackers and other smart things are sold. No wonder! We are all fascinated by the many innovative features of these little voice-controlled assistants, digital wallets and health trackers that can make our lives more convenient.

I know people who never take off their smartwatch at all: In the morning, it gently wakes you up, you check your e-mails and news over a cup of coffee, you lock your apartment door with the watch when you leave, on the go you use it as contactless payment device to buy yourself a small breakfast, and then pay for your subway ticket with your watch. When you arrive at the office, the watch provides access to the office building, you pay your lunch in the canteen with it. Then it's off to the gym, where the watch tracks what sporting achievements have been made today. In between, telephone calls are made. And in the evening, the watch serves as a remote control for the TV before you go to bed and the watch checks the vital functions to ensure a restful sleep. And to think what could come next! I'm especially looking forward to when my smartwatch automatically turns on the espresso machine when I'm in a slump.

But what's behind this fascinating world of smart devices? How is it that my wristwatch can take my pulse, recommend great restaurants near me, and pay for my groceries? What makes my phone smart, and how is it that my smart speaker understands me so well?

Fact is: No IoT without Microelectronics.

• Versatile sensors like the XENSIV™ 60 GHz radar sensors, MEMS microphones, PAS CO2 sensors, XENSIV™ digital barometric pressure sensors or the CAPSENSE™ solutions make IoT devices smarter, enabling the “things” involved to “see”, “hear”, “feel”, “smell” and therefore understand their surroundings and bring elegant, reliable, and easy-to-use capacitive-touch sensing functionality to your design. They are like “the point of beginning” of each IoT system, as they capture environmental information and convert it into digital data.
  
  
• Microcontrollers for smart things like the PSoC™ 6 MCU, the XMC™ microcontroller family, the AURIX™ TriCore™ or the CAPSENSE™ controllers make products smart by collecting, processing, analyzing and communicating data. They bridge the gap between high performance and low power.
  
  
• Depending on “smart” decisions, power semiconductors convert the control signals into action such as motion, light, and heat. CoolGaN™ HEMTs, CoolSiC™ MOSFETs, CIPOS™ IPMs or iMOTION™ ICs are perfect examples for solutions for the IoT. Additionally, wireless power is becoming increasingly integral for the multifaceted world of smart things. Infineon offers safe and efficient wireless charging solutions for inductive and resonant topologies.
  
  
• Reliable connectivity is the IoT’s heartbeat. Today’s requirements for mobile-device and wireless applications are increasingly strict due to 4G/5G. Infineon’s AIROC™ portfolio of Wi-Fi® and Bluetooth® products as well as the OPTIGA™ Connect family for secured cellular connectivity based on eSIM stand for reliable and high performance connectivity. Infineon is also a market leader in USB and USB-C, with more than 1 billion units shipped since 2008.
  
  
• Security solutions like the OPTIGA™ Trust M, the OPTIGA™ Authenticate, the OPTIGA™ TPM or the PSOC™ 64 Security Line give “things” a trustworthy identity and enable the growth of new business models. They protect sensitive data, intellectual property and personal privacy, and can contribute significantly to public safety.

Learn more about this exciting world of smart devices that literally turns fiction into reality.

We make IoT work.
www.infineon.io

Hi, can the half-bridge output of the chip IRS2092S be connected to the high-frequency transformer? Why can the chip work normally before the connection of the transformer, but after the connection of the transformer, it can not vibrate under the condition of no load or with load?

Infineon Select Zephyr™ RTOS for their Next Generation of Products and Solutions

As you may have seen in the news, Infineon has joined the Zephyr™ Project. Take a look at the press release on the Zephyr™ Project page. This blog gives some additional context as to why we have joined the Project and to set out a manifest that Infineon aim to achieve.

Why We Have Joined Zephyr™

As someone who has been in the IoT industry for many years, first starting as a ZigBee developer, then building voice products and now as a Technical Marketing Manager for the Software Ecosystem at Infineon, it's been clear over all that time that complexity doesn't get simpler, but evolves into different complexities. There isn't one magic bullet that meets everyone's objectives and the content and infrastructure provided needs to be flexible and rich. This proves to be massively challenging, to meet all different innovative use cases, but also create a foundation of compatibility.

Within ModusToolbox™ , we believe we are achieving this with our constant evolution of our graphical tools for complex Software, Multi-IDE support, a build system that can be seamlessly integrated into OEM's build system and how DevOps can scale with nightly builds and testing frameworks. However, more and more engineering teams start to favor certain ecosystems for various reasons including:

• Open Source Driven though the Apache 2.0 license
• Long Term Support
• Multi Vendor Platform Support
• Repo Management with West
• Rich Industrial and Consumer Software Standards
• Configuration Tools through Kconfig and DeviceTree

There are many other reasons why developers choose Zephyr™ and we firmly believe that ModusToolbox™ Software and Tools provides these exact features, however, we also need to be able to provide that Safety net to Developers who haven't used Infineon Microcontrollers before and do want to use Open Source Bluetooth, Wi-Fi, Networking and Application Protocol stack and many more.

Lastly, our joining also allows us to drive new ideas based on our industry expertise that benefits developers utilization Infineon technology which leads us to what we hope to achieve as being a member of the Zephyr™ Project

Looking at High Performance, Not Just Constrained Devices

For a long time, many "RTOS" providers were focused on constrained devices and limited resourced devices. Now this was the case for many devices when Zephyr™ was first brought to the market, but rapidly, this has changed. Microcontrollers of today have increased in performance and have started to bridge the gap to Microprocessors exponentially. Yes, it's important to make sure Software is optimized for performance, however, not at the expensive of enriching the Software ecosystem of features and capability. Also, to refer to Zephyr™  as an "RTOS" really devalues the project itself, as Zephyr™ can also be referred to as an Ecosystem of Open Source Software that gives confidence in support and a range of middleware and application protocols to get products to market. We at Infineon aim to drive more content, Multi-Core use cases and rich Software to remove the myth of Microcontrollers being "Constraint".

Bridging the Gap from Linux Developers to Zephyr™ Developers

With the improved performance of Microcontrollers and the cost effective offering, a new breath of Embedded Developers are experiencing the Microcontroller universe. This is exciting because it brings new ideas and a new perspective on what's needed to build innovating products and technology. It also means, with more software needs there is an increased need for stability and ease of use. Comparing the Software Enablement available for Linux Developers and Software Enablement for RTOS Developers, Linux appears to have a richer experience. This means, Software content we all need to bring to Microcontrollers to keep up with the performance upgrades they are getting needs to improve. In a blog we have just released for the ModusToolbox™ Software Ecosystem, we are doing just that.

What we hope to achieve is to drive more Software middleware around video, audio and graphics, continuously abstracting and standardizing complex hardware while also having the option to customize for innovative use cases. We also look to drive better Machine Learning enablement through pre-build models, training flows and easier deployment, similar to what we have with ModusToolbox™  for Machine Learning and finally, improving the Audio and Voice experience through standardized tooling and Software encoders and decoders.

Next Steps

Our current focus is to get the first Zephyr™ enablement on the PSoC 6™ family into the Zephyr™ Project. We are actively working on this and will announce the availability of that very soon.

Danny Watson is a Senior Manager responsible for a Technical Product Marketing team who specialize in IoT, Machine Learning, Security and Developer Experience. The team is responsible for all Software content associated with Infineon's PSoC™ 4, PSoC™ 6 and PSoC™ 64 products. In collaboration with the Software and Applications Engineers within Infineon, they strive to delivery highly innovative and relevant Software that is directly used in end products to drive increased speed to market and reduced complexity.

I am not able to download CY8CKIT-062 design files or any files.  I get a message:

The requested URL was rejected. Please consult with your administrator.
Your support ID is: 15752085814832961338

For example, this applies to the following URL's:

https://itools.infineon.com/archive/CY8CKIT062BLESetup_RevSE.exe
https://itools.infineon.com/archive/CY8CKIT-062-BLE%20PSoC%206%20BLE%20Pioneer%20Kit%20Firmware.zip
https://itools.infineon.com/archive/CY8CKIT062BLESetupOnlyPackage_RevSE.exe _

Infineon-CY8CKIT062BLESetup_RevSE.exe-DevelopmentTools-v01_00-EN.htm
Infineon-CY8CKIT-062-BLE_PSoC_6_BLE_Pioneer_Kit_Firmware.zip-DevelopmentTools-v01_00-EN.htm
Infineon-AIROC_CySmart_Bluetooth_LE_Test_Debug_Tool-DevelopmentTools-v01_00-EN.htm

Dear Community members, 

Happy New Year! While we step in to 2022, let's take a moment to cherish the key achievements and memories from last year, which was only possible by all your support and help. Thank you everyone for being part of this journey. 

A year of growth

Last year in October, we went through a major transformation where legacy Cypress Developer Community and Infineon Forums merged together to form the Infineon Developer Community. We are currently 34K+ members strong, and out of 60K discussions, more than half have an accepted solution. This is just a beginning, and in the coming months and years you will see more exciting upgrades coming your way.

2021 in numbers

Celebrating our members

Every member of this community is key to our growth, and there were many champions who stood out with their expertise and engagement in 2021.

✔️  Most number of accepted solutions:

 @Len_CONSULTRON     @MotooTanaka     @BiBi_1928986     @odissey1     @KyTr_1955226 

🌏 Most number of community translations: 

@keni_4440091     @Kenshow     @MaMi_1205306     @YuMa_1534086     @MaKi_350451 

🖥 Most number of code examples:

@MotooTanaka    @YoIs_1298666     @Kenshow    @Len_CONSULTRON 

👍 Most likes received: 

@Len_CONSULTRON    @MotooTanaka     @odissey1    @BiBi_1928986    @Kenshow 

Congratulations to these champions and every member who participated.  Any member can help the community by answering some of fellow engineers' queries, or by submitting code examples or translations. Please feel free to send a private message to me (@vishnu) if you would like to know more. 

What’s in store for 2022

We are constantly working to make your community experience better, and this year you will see a better reward and recognition program to celebrate your valuable contributions to the community. The team will also ensure that our community offers you easy ways to navigate, and leverage all the features to get what you need, as quickly as possible with UI/UX improvements.

A unified search experience which allows you to find relevant resources not just from community, but also from our key digital channels, and a better translation solution are added to this year's community roadmap.

This community is for you, and hence we are going to improve it together! We will soon start implementing a robust feedback mechanism to share your thoughts on what’s good, and what needs to be improved in our community.

These are only some of the improvements planned for this year, and you will be notified when these programs are rolled out. So keep watching this space, and subscribe (Community Manager Blog home page -> Options->Subscribe) to be in the loop.

Do you have any stories to share where our community and it's members helped you succeed? Don't forget to share them in the comments below! 🙂

It is time to take the final step in our week-long BLE adverture. Hopefully you have a working peripheral already. You should be able to send messages from your phone and have it send messages to you. OK, it's just a find me application and battery monitor right now, but those two things tell you a lot of what you need to know to make bigger, more interesting peripherals. Our last task is to make sure your device only talks to the right people. That process is called pairing and we shall control that with a passkey.

We shall start this job in familiar territory - the BLE Configurator. Switch the view to the GAP Settings and look at "Security configuration 0". Note that more complex peripherals can implement multiple configurations but we are only making one.

Change the Security level to "Authenticated pairing with encryption". The authentication means that the pairing requires a passkey. The IO Capability should be "Display" which means the peripheral has a way for presenting a passkey to the user. In our case that is the terminal and we will write a little code to print the key. Some peripherals do not have a display and so the authentication process has to done differently - for example, the passkey can be sent to, and displayed on, the phone instead and the a simple button can be used to accept the number on the peripheral. The last edit is for Binding, which should be set to "No Bond". In real-world applications you alnmost always bond, to the point that pairing and bonding are often considered to be synonyms. Strictly, bonding is just the storage of pairing information in non-volatile memory which enables bonded phones and devices to automatically recognize each other and connect without a passkey. We are not going to bond because it's a lot easy to learn about piring without the need to force your phone and peripheral to forget each other all the time. Let's get good at pairing first!

Saving the configurator edits, we need to add four events to our stack_handler() function.

• CY_BLE_EVT_GAP_AUTH_REQ occurs when the phone asks to initiate pairing. The peripheral responds by sending back the authentication method(s) that it can support (in our case this means "display").
• CY_BLE_EVT_GAP_PASSKEY_DISPLAY_REQUEST means the central wants the peripheral to display the passkey. The phone asks the user to enter the value (6-digit code with leading zeros).
• CY_BLE_EVT_GAP_AUTH_COMPLETE means that the phone has sent the user's passkey and it matched the displayed value.
• CY_BLE_EVT_GAP_AUTH_FAILED means the value entered was wrong, or the user waited too long, or some other reason for not allowing pairing.

Here is the code to handle those events. Just add it into the switch statement in stack_handler().

/* Include stdio.h at the top of main.c */

#include "stdio.h"

...

char passkey_str[50]; /* Put the string declaration at the top of stack_handler() */

...

case CY_BLE_EVT_GAP_AUTH_REQ:
    Cy_SCB_UART_PutString( KIT_UART_HW, "Authenticating\r\n" );
    /* Send the authentication settings set by the BLE Configurator - GAP Settings */
    Cy_BLE_GAPP_AuthReqReply( &cy_ble_config.authInfo[CY_BLE_SECURITY_CONFIGURATION_0_INDEX] );
break;

case CY_BLE_EVT_GAP_PASSKEY_DISPLAY_REQUEST:
    sprintf( passkey_str, "Passkey requested\tKey = %06ld\r\n", ( (cy_stc_ble_gap_auth_pk_info_t*)eventParam )->passkey );
    Cy_SCB_UART_PutString( KIT_UART_HW, passkey_str );
break;

case CY_BLE_EVT_GAP_AUTH_COMPLETE:
    Cy_SCB_UART_PutString( KIT_UART_HW, "Authentication complete\r\n" );
break;

case CY_BLE_EVT_GAP_AUTH_FAILED:
    Cy_SCB_UART_PutString( KIT_UART_HW, "Authentication fail\r\n" );
break;

As you can see, there is not a lot to it. The stack does the hard part of communicating with the phone and deciding whether to pair. The call to Cy_BLE_GAPP_AuthReqReply() takes an argument that is in the generated code from the BLE Configurator. The variable cy_ble_config is a big struct containing all the user selections from that tool. The authInfo member contains the information we just provided in an array of one element (CY_BLE_SECURITY_CONFIGURATION_0_INDEX is the only element in that array because we only have one configuration). So, sending that information up to the phone is all that is required to tell it to pop up a passkey request dialog.

Of course, we have to print the passkey to give the user a chance to guess right! That happens in the CY_BLE_EVT_GAP_PASSKEY_DISPLAY_REQUEST event. The stack generates a random number and passes it into the event handler in the eventParam argument.

When you build and program the application, you should connect to it as normal. When you try to open the Battery service the CySmart app should automatically pop up the passkey request, as above. Note that the Android version of the app does this as soon as you connect but the iPhone version waits for you to do something that requires the peripheral to respond. On the iPhone, then, you can send an Immediate Alert before pairing and, while the phone says it was sent (it was) the peripheral ignores the message (and the LED does not light). Everything is working correctly in both cases, because you need to have completed pairing before either service will be honored by the peripheral.

Here is the terminal output for a session where I got the password wrong. There is no code to enable a re-try so you need to disconnect and reconnect on order to try again. When I got it right I could send and receive messages with the usual wild abandon! When you play with this, remember to include any leading zeros when entering the passkey - you must enter all 6 digits.

So that's the full set of BLE exercises. I hope you followed along and had some fun with it. We have a large array of examples of how to take this further and I have attached a template for you to recreate exactly what I have done here. To use the template download and unzip it, then open the New Application dialog, select the prototyping kit, then use the "Import..." button to open the modus.mk file in the BLE_proj folder.

Happy Blootoothing!!!