Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Blogs - Page 22

icon

Blogs

thumbnail
Last time I blogged (is that really a word? what a strange world this is) I wrote about the ModusToolbox device configurator. We set up a pair of pins, one called "LED" and the other "SW" (because, it turns out that I am too lazy to write "Switch" or "Button"). Anyway, I mentioned that the configurator generates the setup code for the pins and that I would explain how that works. So here goes...At the top of main() there is a function call to "init_cycfg_all()" and that's where the pins get initialized. That function lives in a file called cycfg.c which you can find in the GeneratedSource folder.You can see here that this folder is actually a link (see the tiny arrow on the folder icon) to the configuration project. That project is the one that contains the design.modus file, which contains all the selections and information from the configurators, and the source files generated when I saved my configuration.Also in this folder are the configuration files for connectivity, which means the signals that are connected inside the PSoC, platform, which is the power, debug and clock setup code, and pins, which we are most interested in.First, here is the meat of cycfg.c, showing the init_cycfg_all() function.#include "cycfg.h"void init_cycfg_all(){ init_cycfg_pins(); init_cycfg_platform(); init_cycfg_connectivity();}I am sure you'll be flabbergasted to learn that init_cycfg_pins() is in cycfg_pins.c - this is pretty simple stuff (by design - so you can dig in and really understand what the tools are doing for you). What does that function look like? Well, this...void init_cycfg_pins(void){ Cy_GPIO_Pin_Init(SW_PORT, SW_PIN, &SW_config); Cy_GPIO_Pin_Init(LED_PORT, LED_PIN, &LED_config); Cy_GPIO_Pin_Init(SWO_PORT, SWO_PIN, &SWO_config); Cy_GPIO_Pin_Init(SWDIO_PORT, SWDIO_PIN, &SWDIO_config); Cy_GPIO_Pin_Init(SWCLK_PORT, SWCLK_PIN, &SWCLK_config);} The pins are set up with a call to a PDL function that accepts the port address, pin number within the port, and a pointer to a configuration struct. There are five calls - one for LED, one for SW, and three for debugging - SWCLK, SWDIO, and SWO. It's all simple enough, but where do those arguments come from? The ports and pins are defines and they come from cycfg_pins.h. Here is a snippet for SW, the input pin.#define SW_PORT GPIO_PRT0#define SW_PIN 4U#define SW_NUM 4U#define SW_DRIVEMODE CY_GPIO_DM_PULLUP#define SW_INIT_DRIVESTATE 1#ifndef ioss_0_port_0_pin_4_HSIOM#define ioss_0_port_0_pin_4_HSIOM HSIOM_SEL_GPIO#endif#define SW_HSIOM ioss_0_port_0_pin_4_HSIOM#define SW_IRQ ioss_interrupts_gpio_0_IRQnI'll go through all of those defines in order. SW_PORT is the crucial macro, it maps to a pointer to the port 0 hardware:#define GPIO_PRT0 ((GPIO_PRT_Type*) &GPIO->PRT[0])I am glad that's generated for me!Next there is SW_PIN, the pin number. SW_NUM is always the same as the PIN macro - the "NUM" style is used for lots of peripherals (which I'll show you next time) and so we generate two macros, in case you are lazy like me and always want to use one style. it's your choice.After that we have the drive mode - PULLUP creates an active low button. DRIVESTATE is the initial pin value (so pin reads get the right result before the button is pressed). Then there are some definitions of internal connections, which are unused for software-driven GPIOs. Lastly, there is the IRQ definition, which is useful when you trigger interrupts from the pin and REALLY useful when you trigger interrupts on multiple pins in the same port (another subject for another day).All that explains where the first two arguments come from. The last one is a C variable and it is back in the cycfg_pins.c file. Here is the configuration struct for SW.const cy_stc_gpio_pin_config_t SW_config = { .outVal = 1, .driveMode = CY_GPIO_DM_PULLUP, .hsiom = SW_HSIOM, .intEdge = CY_GPIO_INTR_DISABLE, .intMask = 0UL, .vtrip = CY_GPIO_VTRIP_CMOS, .slewRate = CY_GPIO_SLEW_FAST, .driveSel = CY_GPIO_DRIVE_FULL, .vregEn = 0UL, .ibufMode = 0UL, .vtripSel = 0UL, .vrefSel = 0UL, .vohSel = 0UL,};I will not bore you explaining all of that but a few things are intreesting. Firstly, the struct is const. That means it is stored in flash and not copied into RAM on startup. This saves memory but, if you want to change the struct at run-time, you can turn off the const from the device configurator, by un-checking "Store Config in Flash". Note that this option saves RAM, but not flash, because the INITDATA always has to be kept in non-volatile memory.Back in the C code you can see that the pin initialization, like the PULLUP and interrupt settings, is all contained in the struct. The end result of all this code is that device initialization is an automated function with PSoC in ModusToolbox but, if you need to over-ride these choices for any reason, it is really easy to make a copy of the generated code, edit it and simply call your new function and not the generated one!Next time, I'll take you a little deeper into the configurators and set up some more interesting peripherals, and then, if all goes well, I'll introduce you to the wonders of the CapSense configurator and its pal, the CapSense tuner!
thumbnail
I promised to tell you about the FreeRTOS templates and, now is the time, so, here we go... In the last post I used the PioneerKitApp template. This time I'll try PioneerKitAppFreeRTOS. It's a bit of a mouthful.When the project is created it looks identical to last week's project except this one includes the FreeRTOS code and has an example FreeRTOSConfig.h in your source folder.You will see that the code in main.c is quite different from the other template. First of all, in main(), it creates a task and starts the FreeRTOS scheduler. BaseType_t retval; retval = xTaskCreate( blinky, BLINKY_NAME, BLINKY_STACK_SIZE, NULL, BLINKY_PRIORITY, NULL ); if( pdPASS == retval ) { vTaskStartScheduler(); }Notice how the code checks the return code from the create call because that is the easiest way to avoid out of memory start-up problems in the OS. I had no problems because I configured ooooooodles of RAM for my tasks, and I only have one! The task itself is implemented in a function called blinky() and has the following parameters./* Defines for a simple task */ #define BLINKY_NAME ("Blinky") #define BLINKY_STACK_SIZE (1024) #define BLINKY_PRIORITY (5) #define BLINKY_DELAY_TICKS (500)The two NULL arguments are unused options you can use when creating tasks - the first is a pointer to to an argument that gets passed into blinky() and the second is a pointer for the OS to return the created task's ID. I'll go into more detail on that later.And here is the blinky() code. It's very complex (not) - toggle the pin and wait for a while!void blinky( void * arg ) { (void)arg; for(;;) { /* Toggle the user LED periodically */ Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ); vTaskDelay( BLINKY_DELAY_TICKS ); } }You can build and program the application to verify the OS running - the orange LED blinks at 1Hz (BLINKY_DELAY_TICKS is 500, and each tick is 1ms, so the LED is off for 500ms and on for 500ms). Let's extend that a little by blinking another LED. First, let's make a copy of blinky() and change the LED and frequency.void blinky2( void * arg ) { (void)arg; for(;;) { /* Toggle the user LED periodically */ Cy_GPIO_Inv( KIT_LED2_PORT, KIT_LED2_PIN ); vTaskDelay( BLINKY_DELAY_TICKS / 3 ); } } Then create the new task with a new name.#define BLINKY2_NAME ("Blinky2") retval = xTaskCreate( blinky, BLINKY_NAME, BLINKY_STACK_SIZE, NULL, BLINKY_PRIORITY, NULL ); if( pdPASS == retval ) retval = xTaskCreate( blinky2, BLINKY2_NAME, BLINKY_STACK_SIZE, NULL, BLINKY_PRIORITY, NULL );When I program the application the red LED blinks three times faster than the orange one.I do not know about you but that copied code in blinky() and blinky2() drives me a bit nutty. Its the same code! I want to reuse it - for all the LEDs. The functions only differ in the pin they toggle and the time they go to sleep. Let's use that argument pointer I talked about above. First I create a struct to contain the arguments and five variables for each of the LEDs on the kit (red, orange, and the RGB).struct led_t { GPIO_PRT_Type* port; unsigned int pin; int rate; }; const struct led_t LED1 = { KIT_LED1_PORT, KIT_LED1_PIN, 300 }; const struct led_t LED2 = { KIT_LED2_PORT, KIT_LED2_PIN, 600 }; const struct led_t LEDR = { KIT_RGB_R_PORT, KIT_RGB_R_PIN, 100 }; const struct led_t LEDG = { KIT_RGB_G_PORT, KIT_RGB_G_PIN, 150 }; const struct led_t LEDB = { KIT_RGB_B_PORT, KIT_RGB_B_PIN, 750 };Then create more tasks and give each call the argument pointer. retval = xTaskCreate( blinky, "LED 1", BLINKY_STACK_SIZE, (void *)&LED1, BLINKY_PRIORITY, NULL ); if( pdPASS == retval ) retval = xTaskCreate( blinky, "LED 2", BLINKY_STACK_SIZE, (void *)&LED2, BLINKY_PRIORITY, NULL ); if( pdPASS == retval ) retval = xTaskCreate( blinky, "LED R", BLINKY_STACK_SIZE, (void *)&LEDR, BLINKY_PRIORITY, NULL ); if( pdPASS == retval ) retval = xTaskCreate( blinky, "LED G", BLINKY_STACK_SIZE, (void *)&LEDG, BLINKY_PRIORITY, NULL ); if( pdPASS == retval ) retval = xTaskCreate( blinky, "LED B", BLINKY_STACK_SIZE, (void *)&LEDB, BLINKY_PRIORITY, NULL );Lastly, I deleted blinky2() and modified blinky() to use the argument.void blinky( void * arg ) { struct led_t *led = (struct led_t *)arg; for(;;) { /* Toggle the user LED periodically */ Cy_GPIO_Inv( led->port, led->pin ); vTaskDelay( led->rate ); } }Now, when I program the kit, it twinkles like the lights in my Christmas tree (that I already miss terribly) and I did not have to write 5 almost-identical tasks to make it work. I attached the source code to this article for you, in case you want to play with the LEDs (note: I had to change the file extension to "txt" because, apparently, "c" files are dangerous!!!).The point of all this is not really to create a Christmas tree replacement. Hopefully it's obvious that the template is a really nice way to get started on a multi-tasking application because it configures all the basic peripherals on the board, sets up the OS, and gives you a stub task (blinky) that you can modify and copy to make your own tasks (that do a little more than blink LEDs). Happy tasking!
thumbnail
I have recently shown you two of the most helpful starter templates in ModusToolbox - PioneerKitApp and PioneerKitAppFreeRTOS. Just as an FYI, if you have the PSoC 6 prototyping kit instead, there are equivalent templates for that kit called ProtoKitApp and ProtoKitAppFreeRTOS. All of these templates set up some kit basics for you so that you can jump straight into writing your application code. Essential peripherals like clocks, debugging, LED and button pins, CapSense, plus the I2C and UART bridge peripherals are all pre-configured in the design.modus file. If you do not like our configuration, you are very welcome to launch the configurators and modify the setup the way you need it. How should you go about that?Well, the short answer is to just double-click on the design.modus file and have a good time! But, since I am feeling a little more helpful that that today, a walk-through of how to set up peripherals from scratch might be good. I'll start with a new project and will use (yet) another project template - EmptyPSoC6App. This template sets up the barest of bare minima - just the clocks and debug.In the EmptyPSoC6App_config project, find and double-click on design-modus to open the device configurator. There are five panels in the GUI - Peripherals, Pins, Platform, Peripheral Clocks, and DMA. Switch to the Platform tab and you will see the very minimal setup from the template.In the Resource panel (left) you will see Debug, Power and System Clocks. If you just select each of them in turn you will see, in the Parameters panel (right), that SWD and SWO are enabled for debugging, the power supply is set to 3.3V, and the PLL is configured to generate a frequency of 144MHz. For your early projects there is probably no reason to change any of these values so I'll move on to configuring an LED and button.Switch over to the Pins tab and open the tree display to see the pins in Port 13. Click on the checkbox next to pin 7 to start setting up the pin. Conveniently, this pin is attached to an LED on both of our Pioneer kits and prototyping kit so this should work on whatever board you have. Start by giving the pin a name (or alias if you want to be fancy) - I am using "LED". Then set the Drive Mode of the pin to "Strong Drive. Iinput buffer off" using the drop-down menu in the parameters panel.Next repeat that basic sequence for Port 0. Pin 5 is connected to a push button (again, thanks to my pal Ronak who designs all these boards, it is the same pin on all kits) with I am calling "SW". To configure the input choose "Resistive Pull-Up. Input buffer on" drive mode so that my active-low button reads 1 when up and 0 when pressed. Save the edits and switch back to the IDE.In the EmptyPSoC6App_mainapp project, open the Source folder and double-click on main.c to open it in the editor and write the following code in the infinite loop.state = Cy_GPIO_Read( SW_PORT, SW_PIN );Cy_GPIO_Write( LED_PORT, LED_PIN, state );That is all we need to prove that our configuration works. In the IDE Quick Panel click on "EmptyPSoC6App Program (KitProg3)" and, if you did everything right, it will build the application and program the kit. When you press and hold the button, the LED will turn on...So, there are the basics for device configuration with ModusToolbox. Next time I'll show you the firmware that makes all this work and get a little more fancy with some PWM tricks and fun with the serial communication blocks.
thumbnail
I previously wrote about using the New Application wizard in ModusToolbox and showed you the BlinkyLED project. Now I want to show you another template that I believe will be more useful to you in the long run. It is called PioneerKitApp and it supports both the PSoC 6 Pioneer kits - CY8CKIT-062-BLE and CY8CKIT-062-WIFI-BT. When you highlight the template in the wizard it tells you the following about the project.Basic peripheral configuration for the PSoC 6 Pioneer kits (CY8CKIT-062-*). Debug is enabled and platform clocks are set for high performance (144MHz CLK_FAST for CM4 core and 72MHz CLK_SLOW for CM0+) but with a peripheral-friendly CLK_PERI frequency (72MHz). In addition the user LEDs and switch, KitProg3 UART and I2C bridges, and CapSense buttons and slider are configured.My job involves creating a lot of projects and almost every one of them blinks an LED or prints a message to the UART at some point. Depending upon how well my day is going the message might be "PSoC Rocks!" or, if things aren't going so well, something a little less repeatable! But I digress, the point is that I get really fed up of configuring pins and UARTs every day. So I created a template and my boss told I should share it with you.When you create the application ModusToolbox opens up the file setup_readme.txt automatically. This file describes all the settings I made in the configurator tools... clocks, pins, UART, I2C and CapSense. This means I can start programming without even opening the configurators. For example, here is a program to print a message and toggle an LED. I wrote this code immediately after creating the application without worrying about configuring peripherals, adding middleware (to support printf), picking libraries, choosing part numbers, setting include paths, or any of that nonsense.#include "cy_device_headers.h"#include "cycfg.h"#include "cycfg_capsense.h"#include "stdio.h" int main(void){ int count = 0; cy_stc_scb_uart_context_t uart_context; init_cycfg_all(); __enable_irq(); Cy_SCB_UART_Init( KIT_UART_HW, &KIT_UART_config, &uart_context ); Cy_SCB_UART_Enable( KIT_UART_HW ); for(;;) { Cy_GPIO_Inv( KIT_LED1_PORT, KIT_LED1_PIN ); printf( "Message #%d\r\n", ++count ); Cy_SysLib_Delay( 500 ); }}Let's dig in a little. First of all, notice that I am using printf(), which is defined in the usual C stdio.h header file. This is supported by the retarget_io middleware package that adds three files to the application - retarget_io.c, stdio_user.c and stdio_user.h - which you can see highlighted in the project here.The "user" files are placed into the Source folder because they are intended to be user-modifiable. In the template I already did that to choose the serial block for the KitProg3 serial-USB bridge (so I can see the output in a PC terminal emulator like teraterm). Here are the settings I made in stdio_user.h.#include "cycfg.h"/* Must remain uncommented to use this utility */#define IO_STDOUT_ENABLE#define IO_STDIN_ENABLE#define IO_STDOUT_UART KIT_UART_HW#define IO_STDIN_UART KIT_UART_HWWhere did that KIT_UART_HW macro come from? Or the KIT_LED_PORT macro for that matter? Well, they got set up in the device configurator. Here is a screenshot of the device configurator, where I have called the serial communication block #3 "KIT_UART" and given it the personality UART_v1.0 (I could have used I2C or SPI instead).The configurator generates the KIT_UART_HW macro and the KIT_UART_config variable automatically, so writing the code is easy and fast. I did a similar thing for the LEDs, giving the orange LED the alias "KIT_LED1" so that the tool generates the PORT and PIN macros for me.Next time, I'll show you a variation of this template that sets up FreeRTOS for you so you can get multi-tasking in no time at all.
thumbnail
A few weeks ago I announced that ModusToolbox 1.0 was released and available for download. I think it's time to start posting some pointers on how to use the product effectively. I think a good place to start that is to explain the options you have when creating new projects.First of all, I recommend you resist the temptation to use the "File->New" dialog to create a C or C++ project. We have created a shortcut for you, with the catchy name "ModusToolbox IDE Application" that is a lot easier to use than starting the project from scratch. You *can* create your own project but you'll have to figure out how to handle the PDL libraries, and code for the CM0+ core in the PSoC 6, and the generated configuration files and, all in all, it is just way easier to use the shortcut! Just click on the shortcut in the Quick Panel or the New Project dialog. Our wizard walks you through the selection of the target and a starter template for the application. You can either pick a board or choose a specific target part number. The "Custom Hardware" option is really intended for users going to market and using their own hardware. Given that ModusToolbox was released two weeks ago I am going to make the wild guess that most of you are just starting out and have one of our kits. The "Dev/Eval Kit" path is for us.Here is the list of supported kits - not too many today but we are busy working on new kits and shall be adding support for them in the future.I have a CY8CKIT-062-WIFI-BT kit, but I think many of you will have the 062-BLE version, because that has been on sale for a while longer. Either way, pick your board and follow along - the process is the same whichever board you have. You then get a list of applications for the kit.These are typically not full-blown reference products but rather examples of useful things to do and good places to just get started. I strongly recommend creating your own projects with a few of them - to get a feel for the tools and try out some cool stuff. The ones that are prefixed with CE are Code Examples from our Applications team so they are thoroughly tested and meticulously documented.Most of the others are a little less formal and just show off a feature or function as quickly as possible. Let's start with "BlinkyLED", as I have in the above image. Here is the generated application.The first thing you'll see is that there are actually 5 projects in an application - I'll try to be consistent in using "application" to refer to whole shooting match and "project" when I mean a specific Eclipse project. The 5 projects are as follows:BlinkyLED_mainapp - this contains the code that runs on the CM4 core (your project)BlinkLED_mainapp_psoc6pdl - this contains the driver code from the PDL which will be built for the CM4 coreBlinkyLED_config - this project contains the generated source code from the ModusToolbox configurator tools (more on this next time)BlinkLED_mainapp_cm0p - this contains the code that runs on the CM0+ cor​eBlinkLED_mainapp_cm0p_psoc6pdl - this contains the driver code from the PDL which will be built for the CM0+ coreOur application - and almost certainly all of your's too - is in the BlinkyLED_mainapp project. In the source folder, double-click the main.c file to see the code we are going to run. Connect you board to the USB port of your PC and, in the Quick Panel, press "BlinkyLED Program (KitProg3)" (or change the prefix for whatever you named your application).If all is well you will build the application, program it, and see the blinking LED. You are now ready to start modifying the code to get used to the IDE and also trying out a few more of the examples. In my next post I'll talk about some of these templates in more detail and show you everything they automate in the generated applications.
thumbnail
Hello embedded designers. Thanks for your interest in ModusToolbox. As this is a new release/platform, we would like to hear your feedback about your download/install experience. While we have a number of machine/OS configurations that we test, there's nothing like hearing from users in the field. Comments on the Installation Guide are also welcome.--Matt
thumbnail
WPA2-Personal is vulnerable to a standard dictionary attack using a captured successful “4-way handshake”. Recently, it was demonstrated that a similar dictionary style attack can be done with a captured Pairwise Master Key Identifier (PMKID) instead of a successful 4-way handshake (see: https://hashcat.net/forum/thread-7717.html). Public visibility of a PMKID is by design and is not considered a security risk/flaw in the protocol. The availability of the PMKID does not significantly affect the effort needed to perform the dictionary attack.
thumbnail
On July 23, 2018 the security vulnerability CVE-2018-5383 was released. This CVE states that Bluetooth implementations may not sufficiently validate elliptic curve parameters during Diffie-Hellman key exchange.Because these threats have dependencies on software configuration and usage, we have prepared this document to help Cypress Bluetooth customers understand how we patched our software to address the errata as well as to provide guidance on how to remove the vulnerability.
thumbnail
Excelon™, Cypress’ next-generation Ferroelectric RAM (F-RAM), delivers industry’s highest-performance mission-critical non-volatile memory by combining high-speed low-pin-count interfaces, low-power operation, unlimited read/write cycle endurance and instant non-volatility. This makes Excelon the highest-reliability data-logging memory for smart connected factories and the automobiles of tomorrow. Please find additional details here.The Excelon™ Ultra is a 4-Mbit, 108-MHz Quad SPI F-RAM that supports a rich command set making it compatible with the industry standard Quad SPI peripheral command set. With the industry moving towards low pin count interfaces, a wide variety of micro-controllers have started supporting Quad SPI interface natively. To enable the evaluation of our latest Quad SPI F-RAM in conjunction with industry standard platforms, we will be providing simple driver support for a few of these platforms through Cypress Community. These drivers can be used as-is or with minor modification by embedded systems engineers to get a headstart in adding a high-speed, low-power data-logging memory in the system.The attached files contain a user guide for the code, a sample test project in Keil µVision 5 and LPCExpresso. The sample project contains revision 1.0 of API library files which covers all the important device access features. Sample project files are also available in GitHub repository, click here.Follow this blog to get updates on release of support for more micro-controllers!
thumbnail
WICED-Studio 5.2.1 Installer (Windows)WICED-Studio-5.2.1 (OSX)WICED-Studio-5.2.1 (Linux 64-bit)WICED-Studio-5.2.1 (Linux 32-bit)Release Notes: WICED Studio 5.2.1New WLAN firmware (5.90.230.22) added for 43362 platform with KRACK WPA2 fixesNew WLAN firmware (7.45.98.38) added for 43364/43438/4343W platforms with KRACK WPA2 fixesNew WLAN firmware (7.15.168.101) added for 4390x/54907 platform with KRACK WPA2 fixesNew WLAN firmware (6.49.22) added for 43340 platform with KRACK WPA2 fixes
thumbnail
mifo​We have a product with the CYW43362 chipset based on SDK version 3.1.2. We would like to provide OTA patches for the KRACK vulnerabilities. Based on the previously released WPA2-KRACK-HACK-statement, we’re subject to the group 2 CVEs. Can you shed light on what is the best path to patch our product? Will there be updates for SDK 3.2.1? Or is it possible to OTA upgrade SDK 3.2.1 based field hardware with SDK 6.0. The latter is a less preferred method for us and I ask because in the past upgrading SDK 2.X with SDK 3.X based firmware was not possible over-the-air.My firmware version information is under:WLAN Firmware : wl0: Nov 7 2014 16:03:45 version 5.90.230.12 FWID 01-e36c94fdThanks
thumbnail
WICED Studio 4.1.3 IDE Installer (Windows) WICED Studio 4.1.3 (OSX) WICED Studio 4.1.3 (Linux 64-bit) WICED Studio 4.1.3 (Linux 32-bit) Release Notes: WICED Studio 4.1.3 New WLAN firmware (7.45.98.38) added for BCM43364/BCM43438/BCM4343W that includes KRACK WPA2 and Broadpwn fixes. New WLAN firmware (6.49.22) added for BCM943340 that includes KRACK WPA2 and Broadpwn fixes. New WLAN firmware (5.90.230.22) added for BCM943362 that includes KRACK WPA2 and Broadpwn fixes. New WLAN firmware (7.15.168.101) added for BCM94390x that includes KRACK WPA2 and Broadpwn fixes.