Lesson 6 – WICED Bluetooth: The Peripheral Comes Alive

WICED Bluetooth Using the CYW20719

# Title Comment
0 A Two Hour WICED Bluetooth Class WICED Bluetooth Using the CYW20719 in all its glory
1 Resources Links to all of the Cypress WICED information including videos, application notes etc.
2 Your First Project Making Hello World & the Blinky LED
3 The Super Mux Tool Learning about platforms and the Super Mux Tool
4 Snips Using the example projects to learn Bluetooth
5 Bluetooth Designer Using the tool to customize a project and get going fast
6 The CCCD & Notification Writing back to the Central
7 Advertising  Beacon Building a beacon project to advertise your custom information 
8 Scanner Viewing the world around you
9 Bluetooth Classic SPP Using the Serial Port Profile to Transmit Lots of Data

Source code: 

  • git@github.com:iotexpert/wiced_bt_intro.git
  • https://github.com/iotexpert/wiced_bt_intro

 

Summary

In the last lesson we built our first Bluetooth design using BT Designer.  In that lesson I showed you how to

  1. Build a project using BT Designer
  2. Start Advertising
  3. Get connected Central –> Peripheral
  4. Read & Write the data from the Central to the  Peripheral

In this lesson we are going to answer the question how does the Peripheral write data back to the Central by adding a button to our last project.  When the button is pressed it will send the state of the button (0 or 1) back to Central.

The important concepts in this lesson are

  1. BLE Notifications
  2. BLE Client Configuration Characteristic Descriptor
  3. How to manually modify the Gatt DB

I will follow these steps:

  1. Copy the project L5_BluetoothLED into L6_BluetoothLEDButton
  2. Rename all of the files to be L6_BluetoothLEDButton….
  3. Fix the makefile
  4. Create a make target and make sure that it still works
  5. Modify L6_BluetoothLEDButton_db.h to add UUID and Handles for the new Button characteristic
  6. Modify L6_BluetoothLEDButton_db.c to add the Button characteristic to the GATT Database
  7. Add initial value arrays for the Button characteristic, CCCD and User Description
  8. Add the Button values to the GATT lookup table
  9. Add connection id uint16_t connection_id
  10. Modify the connection handler l5_bluetoothled_connect_callback
  11. Create a button callback function
  12. Register the button callback

BLE Concepts

A Bluetooth Peripheral is allowed to send Notifications to a Central that a value in the GATT Database has changed.  However, it is only allowed to do this when the Client Characteristic Configuration Descriptor (CCCD) is set.  In other words a Central can register with a Peripheral that it is interested in seeing changes of Characteristics by writing a 0x01 into the CCCD.  The CCCD is just another value in the attribute database.

To setup a Characteristic for Notifications you need to modify the GATT Database by

  1. Adding the notification property to the Characteristic in the GATT Database
  2. Adding the CCCD to the GATT database

In the your program, when a value is changed, you should check to see if the CCCD is set, then send a notification if it is set.

Implement the Project

I am going to build this project on top of the code from L5_BluetoothLED.  So, start this project by copying the project L5_BluetoothLED into L6_BluetoothLEDButton by doing copy/paste

Rename all of the files to be L6_BluetoothLEDButton…. your project should look like this.

Fix the makefile.mk (because the file names have changed)

#
# This file has been automatically generated by the WICED 20719-B1 Designer.
#

APP_SRC = L6_BluetoothLEDButton.c
APP_SRC += L6_BluetoothLEDButton_db.c
APP_SRC += wiced_bt_cfg.c

C_FLAGS += -DWICED_BT_TRACE_ENABLE

# If defined, HCI traces are sent over transport/WICED HCI interface
C_FLAGS += -DHCI_TRACE_OVER_TRANSPORT

Create a make target and make sure that it still works

Modify L6_BluetoothLEDButton_db.h to create a UUID for the new Button characteristic

#define __UUID_L5SERVICE_BUTTON               0x2A, 0xbf, 0x86, 0xa6, 0xc8, 0x6c, 0x4e, 0xa5, 0xaa, 0x56, 0xbd, 0xac, 0x72, 0x80, 0x93, 0xa9

Modify L6_BluetoothLEDButton_db.h to add Handles for the  new Button characteristic

#define HDLC_L5SERVICE_BUTTON                      0x0030
#define HDLC_L5SERVICE_BUTTON_VALUE                0x0031
#define HDLD_L5SERVICE_BUTTON_USER_DESCRIPTION     0x0032
#define HDLD_L5SERVICE_BUTTON_CLIENT_CONFIGURATION 0x0033

Modify L6_BluetoothLEDButton_db.c to add the Button characteristic to the GATT Database

               /* Characteristic 'BUTTON' */

                CHARACTERISTIC_UUID128(HDLC_L5SERVICE_BUTTON, HDLC_L5SERVICE_BUTTON_VALUE,
                        __UUID_L5SERVICE_BUTTON, LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY,
                    LEGATTDB_PERM_READABLE ),

                    /* Descriptor 'Characteristic User Description' */
                    CHAR_DESCRIPTOR_UUID16 (HDLD_L5SERVICE_BUTTON_USER_DESCRIPTION,
                        UUID_DESCRIPTOR_CHARACTERISTIC_USER_DESCRIPTION, LEGATTDB_PERM_READABLE),


                /* Descriptor CCCD */
                CHAR_DESCRIPTOR_UUID16_WRITABLE(HDLD_L5SERVICE_BUTTON_CLIENT_CONFIGURATION,
                        UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,
                        LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ ),

Add initial value arrays for the Button characteristic, CCCD and User Description into L6_ButtonLED.c

uint8_t l5_bluetoothled_l5service_button[]                  = {0x01};
uint8_t l5_bluetoothled_l5service_button_user_description[] = "Button Value";
uint8_t l5_bluetoothled_l5service_button_cccd[]      = {0x00,0x00};

Add the Button values to the GATT lookup table

    {HDLC_L5SERVICE_BUTTON_VALUE,              1,                                                      1,                                                      l5_bluetoothled_l5service_button},
    {HDLD_L5SERVICE_BUTTON_USER_DESCRIPTION,   sizeof(l5_bluetoothled_l5service_button_user_description)-1, sizeof(l5_bluetoothled_l5service_button_user_description)-1, l5_bluetoothled_l5service_button_user_description},
    {HDLD_L5SERVICE_BUTTON_CLIENT_CONFIGURATION, 2,      2,      l5_bluetoothled_l5service_button_cccd},

Add connection id uint16_t connection_id

uint16_t connection_id=0;

Modify the connection handler l5_bluetoothled_connect_callback.  When you get a connection save it.

            connection_id = p_conn_status->conn_id;

and when you get a disconnect put it back to 0

          connection_id = 0;

Here is what the whole handler looks like now

/* GATT Connection Status Callback */
wiced_bt_gatt_status_t l5_bluetoothled_connect_callback( wiced_bt_gatt_connection_status_t *p_conn_status )
{
    wiced_bt_gatt_status_t status = WICED_BT_GATT_ERROR;

    if ( NULL != p_conn_status )
    {
        if ( p_conn_status->connected )
        {
            // Device has connected
            WICED_BT_TRACE("Connected : BDA '%B', Connection ID '%d'\n", p_conn_status->bd_addr, p_conn_status->conn_id );

            /* TODO: Handle the connection */
            connection_id = p_conn_status->conn_id;

        }
        else
        {
            // Device has disconnected
            WICED_BT_TRACE("Disconnected : BDA '%B', Connection ID '%d', Reason '%d'\n", p_conn_status->bd_addr, p_conn_status->conn_id, p_conn_status->reason );

            /* TODO: Handle the disconnection */
            connection_id = 0;

            /* restart the advertisements */
            wiced_bt_start_advertisements(BTM_BLE_ADVERT_UNDIRECTED_HIGH, 0, NULL);
        }
        status = WICED_BT_GATT_SUCCESS;
    }

    return status;
}

Create a button callback function

void buttonISR(void *data, uint8_t port_pin )
{

    l5_bluetoothled_l5service_button[0] = wiced_hal_gpio_get_pin_input_status(WICED_PLATFORM_BUTTON_1);

    if(l5_bluetoothled_l5service_button_cccd[0] & GATT_CLIENT_CONFIG_NOTIFICATION)
              {
                  wiced_bt_gatt_send_notification(connection_id, HDLC_L5SERVICE_BUTTON_VALUE, sizeof(l5_bluetoothled_l5service_button), l5_bluetoothled_l5service_button );

                  WICED_BT_TRACE( "Sent Button %d\n",l5_bluetoothled_l5service_button[0]);
   }
}

In the function l5_bluetoothled_app_init you need to register the button callback to trigger when the button is pressed

    wiced_hal_gpio_register_pin_for_interrupt( WICED_GPIO_PIN_BUTTON_1, buttonISR, NULL );
    wiced_hal_gpio_configure_pin( WICED_GPIO_PIN_BUTTON_1, ( GPIO_INPUT_ENABLE | GPIO_PULL_UP | GPIO_EN_INT_BOTH_EDGE ), GPIO_PIN_OUTPUT_HIGH );

Test using CySmart

 

Click on the “Unknown Service”

Click on the second characteristic.  (we know that is the one because it is Read and Notify)

Now you can press “Read”

 

After clicking the read button and you can see that the value is 0x01 (because you are not pressing the button).  If you were pressing it you would see 0x00

Now press Notify and you should see the value change each time you press the button

 

Lesson 5 – WICED Bluetooth: Bluetooth Designer – Turn up the Radio!

WICED Bluetooth Using the CYW20719

# Title Comment
0 A Two Hour WICED Bluetooth Class WICED Bluetooth Using the CYW20719 in all its glory
1 Resources Links to all of the Cypress WICED information including videos, application notes etc.
2 Your First Project Making Hello World & the Blinky LED
3 The Super Mux Tool Learning about platforms and the Super Mux Tool
4 Snips Using the example projects to learn Bluetooth
5 Bluetooth Designer Using the tool to customize a project and get going fast
6 The CCCD & Notification Writing back to the Central
7 Advertising  Beacon Building a beacon project to advertise your custom information 
8 Scanner Viewing the world around you
9 Bluetooth Classic SPP Using the Serial Port Profile to Transmit Lots of Data

Source code: 

  • git@github.com:iotexpert/wiced_bt_intro.git
  • https://github.com/iotexpert/wiced_bt_intro

 

Summary

In this lesson we are going to build the simplest project that I could think of… turning an LED on/off with Bluetooth Low Energy.

The important BLE concepts are

  1. What is a Central / Peripheral
  2. What is Advertising
  3. What is a GATT Database

The important WICED Bluetooth Concepts are:

  1. How do you run WICED Bluetooth Designer
  2. What is the structure of a WICED Bluetooth Project
  3. What is a Callback
  4. How is the GATT Database Implemented
  5. How to run CySmart

The steps that we will follow are:

  1. Run BT Designer
  2. Create a project called L5_BluetoothLED
  3. Go to the characteristics page
  4. Add a vendor specific service
  5. Name the Service L5Service
  6. Add an optional characteristic that is vendor specific
  7. Name it RED
  8. Make it 1 byte with an initial value of 01
  9. Set it up for host write
  10. Add a user description to the characteristic
  11. Generate the code
  12. Move the folder to the wiced_bt_class folder
  13. Fix the three include problems
  14. Reset the debug UART to PUART
  15. When there is a write, change the value of the WICED_LED_1 GPIO
  16. Test

BLE Concepts

In the world of BLE there are two sides of every connection

  • The Central – typically a cellphone
  • The Peripheral – your WICED device

Centrals listen for Peripherals that are Advertising.  Advertising is a periodic packet of up to 31 bytes of information that a Peripheral will send out to make it presence known.  When a Central hears the Advertising packets of a Peripheral that is “interesting” it can initiate a connection.

Once a connection is made, how do you exchange information?  The answer is that a Peripheral has a database running inside of it.  The database is called a “GATT database”.   A Central can perform “Service Discovery” to find all of the legal stuff in the database.  The GATT database is organized into one or more “Services” that have one or more “Characteristics”.  For instance a Heart Rate Monitor might have a “Heart Rate Service” with two characteristics, one for heart rate and one for battery level.

There are two types of Services.  Ones that are specified by the Bluetooth SIG, like heartrate.  And vendor specific custom services.

Run Bluetooth Designer

The Bluetooth Designer is a GUI tool that we built into Eclipse.  It allows you to configure some of the fundamental Bluetooth feature (like the GATT Database) and then automatically generate the code.  Start Bluetooth Designer by running File->New->WICED Bluetooth Designer.

Since this is Lesson 5 and we are going to write and LED… call the project “L5_BluetoothLED”

Once you start BT Designer, you screen should look like this.  The project is going to be a BLE only project.

The Characteristics button lets you setup the GATT database.

Add a service by selecting vendor specific service and then hitting the “+”

I’ll call the service “L5Service”

Next add a characteristic by selecting “vendor specific characteristic” and pressing “+”

Change the name to “RED”, Make the device role “Host write to or reads from service”.  Make the size 1 byte and set the initial value to 01 (it must be 01 not 1 or 001)

When we are looking at this remotely you would like to be able to see the user description.  So click that tab and give it a description.

Press Generate Code button.  You will end up with a folder in the top level apps directory.  I don’t like this, so lets move it into our class projects folder.  You can do this by dragging the folder to the wiced_bt_class folder.  Now it should look like this:

Unfortunately, there are three little issues that this creates which need to be fixed.  First, you need to fix L5_BluetoothLED.c as this include is wrong.

#include "../wiced_bt_class/L5_BluetoothLED/L5_BluetoothLED_db.h"

And change it to:

#include "L5_BluetoothLED_db.h"

Next edit L5_BluetoothLED_db.h and add the #include “wiced.h”

#include "wiced.h"

Finally edit the L5_BluetoothLED_db.c to fix the same include problem.

#include "../wiced_bt_class/L5_BluetoothLED/L5_BluetoothLED_db.h"

It should be like this.

#include "L5_BluetoothLED_db.h"

Now edit the make target that was created by the BT Designer and change it to:

Remember in the earlier lesson I showed you about the WICED HCI UART and the WICED PUART.  Well by default the WICED_BT_TRACE is setup to go to the HCI UART.  So, lets fix the output of BT_TRACE to go to the PUART by changing the file “L5_BluetoothLED.c”

#if ((defined WICED_BT_TRACE_ENABLE) || (defined HCI_TRACE_OVER_TRANSPORT))
    /* Set the Debug UART as WICED_ROUTE_DEBUG_NONE to get rid of prints */
    //  wiced_set_debug_uart( WICED_ROUTE_DEBUG_NONE );

    /* Set Debug UART as WICED_ROUTE_DEBUG_TO_PUART to see debug traces on Peripheral UART (PUART) */
      wiced_set_debug_uart( WICED_ROUTE_DEBUG_TO_PUART );

    /* Set the Debug UART as WICED_ROUTE_DEBUG_TO_WICED_UART to send debug strings over the WICED debug interface */
    //wiced_set_debug_uart( WICED_ROUTE_DEBUG_TO_WICED_UART );
#endif

The last thing that we want to do is fix it so that when the Central writes a new value into the RED LED characteristic we should write the GPIO to the new value.  In L5_BluetoothLED.c make this change.

     case HDLC_L5SERVICE_RED_VALUE:
                       WICED_BT_TRACE("LED = %d\n",l5_bluetoothled_l5service_red[0]);
                       wiced_hal_gpio_set_pin_output(WICED_GPIO_PIN_LED_2,l5_bluetoothled_l5service_red[0]);
                       break;

Now build the project and see what happens.  The first testing step will be to open CySmart.  You can see that a device called “L5_BluetoothLED” is advertising.

When I click it, you can see that there is a GattDB.

When I click on the database, I can see that there is only one service (which makes sense as we setup only one)

Click on the Service and you can see that there is only one characteristic in the service… and its value is 01.

When you click the descriptor button you can see that there is a Characteristic User Description

 

And finally the value is “Red LED Value”.  That is what we setup.

When you click back … then click on the write it will bring up this window where I can send a new value.

Now the value is 0x00 and the RED LED is on (remember from earlier that it is active low so that makes sense)

 

And when I look at the terminal I can see two writes (I wrote again before I took this screen shot)

A Tour of the Source Code

The GATT Database is in the file L5_BluetoothLED_db.c

const uint8_t gatt_database[] = // Define GATT database
{
    /* Primary Service 'Generic Attribute' */
    PRIMARY_SERVICE_UUID16 (HDLS_GENERIC_ATTRIBUTE, UUID_SERVICE_GATT),

    /* Primary Service 'Generic Access' */
    PRIMARY_SERVICE_UUID16 (HDLS_GENERIC_ACCESS, UUID_SERVICE_GAP),

        /* Characteristic 'Device Name' */
        CHARACTERISTIC_UUID16 (HDLC_GENERIC_ACCESS_DEVICE_NAME, HDLC_GENERIC_ACCESS_DEVICE_NAME_VALUE,
            UUID_CHARACTERISTIC_DEVICE_NAME, LEGATTDB_CHAR_PROP_READ,
            LEGATTDB_PERM_READABLE),

        /* Characteristic 'Appearance' */
        CHARACTERISTIC_UUID16 (HDLC_GENERIC_ACCESS_APPEARANCE, HDLC_GENERIC_ACCESS_APPEARANCE_VALUE,
            UUID_CHARACTERISTIC_APPEARANCE, LEGATTDB_CHAR_PROP_READ,
            LEGATTDB_PERM_READABLE),

    /* Primary Service 'L5Service' */
    PRIMARY_SERVICE_UUID128 (HDLS_L5SERVICE, __UUID_L5SERVICE),

        /* Characteristic 'RED' */
        CHARACTERISTIC_UUID128_WRITABLE (HDLC_L5SERVICE_RED, HDLC_L5SERVICE_RED_VALUE,
            __UUID_L5SERVICE_RED, LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE,
            LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ),

            /* Descriptor 'Characteristic User Description' */
            CHAR_DESCRIPTOR_UUID16 (HDLD_L5SERVICE_RED_USER_DESCRIPTION,
                UUID_DESCRIPTOR_CHARACTERISTIC_USER_DESCRIPTION, LEGATTDB_PERM_READABLE),

};

Each row in the Database table has a unique “Handle” that is defined in the L5_BluetoothLED_db.h

#define __UUID_L5SERVICE                      0x30, 0x9d, 0x7f, 0x29, 0x73, 0xca, 0x4f, 0xfd, 0xa5, 0x68, 0x17, 0xd8, 0x90, 0x67, 0x7f, 0x35
#define __UUID_L5SERVICE_RED                  0x29, 0xbf, 0x86, 0xa6, 0xc8, 0x6c, 0x4e, 0xa5, 0xaa, 0x56, 0xbd, 0xac, 0x72, 0x80, 0x93, 0xa9

// ***** Primary Service 'Generic Attribute'
#define HDLS_GENERIC_ATTRIBUTE                0x0001

// ***** Primary Service 'Generic Access'
#define HDLS_GENERIC_ACCESS                   0x0014
// ----- Characteristic 'Device Name'
#define HDLC_GENERIC_ACCESS_DEVICE_NAME       0x0015
#define HDLC_GENERIC_ACCESS_DEVICE_NAME_VALUE 0x0016
// ----- Characteristic 'Appearance'
#define HDLC_GENERIC_ACCESS_APPEARANCE        0x0017
#define HDLC_GENERIC_ACCESS_APPEARANCE_VALUE  0x0018

// ***** Primary Service 'L5Service'
#define HDLS_L5SERVICE                        0x0028
// ----- Characteristic 'RED'
#define HDLC_L5SERVICE_RED                    0x0029
#define HDLC_L5SERVICE_RED_VALUE              0x002A
// ===== Descriptor 'User Description'
#define HDLD_L5SERVICE_RED_USER_DESCRIPTION   0x002B

Each characteristic value is held in one of the uint8_t arrays found in “L5_BluetoothLED.c”

/*******************************************************************
 * GATT Initial Value Arrays
 ******************************************************************/
uint8_t l5_bluetoothled_generic_access_device_name[]     = {'L','5','_','B','l','u','e','t','o','o','t','h','L','E','D'};
uint8_t l5_bluetoothled_generic_access_appearance[]      = {0x00,0x00};
uint8_t l5_bluetoothled_l5service_red[]                  = {0x01};
uint8_t l5_bluetoothled_l5service_red_user_description[] = {'R','E','D',' ','L','e','d',' ','V','a','l','u','e'};

/*******************************************************************
 * GATT Lookup Table
 ******************************************************************/

/* GATT attribute lookup table                                */
/* (attributes externally referenced by GATT server database) */
gatt_db_lookup_table l5_bluetoothled_gatt_db_ext_attr_tbl[] =
{
    /* { attribute handle,                  maxlen,                                                 curlen,                                                 attribute data } */
    {HDLC_GENERIC_ACCESS_DEVICE_NAME_VALUE, 15,                                                     15,                                                     l5_bluetoothled_generic_access_device_name},
    {HDLC_GENERIC_ACCESS_APPEARANCE_VALUE,  2,                                                      2,                                                      l5_bluetoothled_generic_access_appearance},
    {HDLC_L5SERVICE_RED_VALUE,              1,                                                      1,                                                      l5_bluetoothled_l5service_red},
    {HDLD_L5SERVICE_RED_USER_DESCRIPTION,   sizeof(l5_bluetoothled_l5service_red_user_description), sizeof(l5_bluetoothled_l5service_red_user_description), l5_bluetoothled_l5service_red_user_description},
};

 

 

Lesson 4 – WICED Bluetooth: Using Snips

WICED Bluetooth Using the CYW20719

# Title Comment
0 A Two Hour WICED Bluetooth Class WICED Bluetooth Using the CYW20719 in all its glory
1 Resources Links to all of the Cypress WICED information including videos, application notes etc.
2 Your First Project Making Hello World & the Blinky LED
3 The Super Mux Tool Learning about platforms and the Super Mux Tool
4 Snips Using the example projects to learn Bluetooth
5 Bluetooth Designer Using the tool to customize a project and get going fast
6 The CCCD & Notification Writing back to the Central
7 Advertising  Beacon Building a beacon project to advertise your custom information 
8 Scanner Viewing the world around you
9 Bluetooth Classic SPP Using the Serial Port Profile to Transmit Lots of Data

Source code: 

  • git@github.com:iotexpert/wiced_bt_intro.git
  • https://github.com/iotexpert/wiced_bt_intro

 

Summary

In this lesson I am going to show you how to NOT write all of your own code and still get the job done.  In this lesson we are going to do three things.

  1. Examine & Run the hal_gpio snip
  2. Examine & Run the hal_i2c_master snip
  3. Copy the hal_i2c_master snip and make it “more better”

To modify the hal_i2c_master snip I will

  1. Make a new folder called L4_Accelerometer
  2. Copy the makefile.mk and hal_i2c_master.c into the L4_Accelerometer folder
  3. Create a new make target and make sure that things still work
  4. Look at the LSM9DS1 datasheet
  5. Update the function initialize_app to startup the Accelerometer and speed up the polling
  6. Update the function comboread_cb to read the Acceleration registers and print out the values

Run hal_gpio

If you dont already have a make target for snip.hal.hal_gpio create one and then program the board.

Notice that the light blinking will change speeds if you press the button.  Let’s look at the code that does this:

At the beginning it sets up a timer

        // Initialize timer to control the pin toggle frequency
        if (wiced_init_timer(&hal_gpio_app_timer, &hal_gpio_app_timer_cb, 0, WICED_SECONDS_PERIODIC_TIMER) == WICED_SUCCESS)
        {
            if (wiced_start_timer(&hal_gpio_app_timer, LED_BLINK_FREQ_A_IN_SECONDS) != WICED_SUCCESS)
            {
                WICED_BT_TRACE("Seconds Timer Error\n");
            }
        }

The timer calls this function each time the timer expires.

/*
 * The function invoked on timeout of app. seconds timer.
 */
void hal_gpio_app_timer_cb(uint32_t arg)
{
    static uint32_t wiced_seconds = 0; /* number of seconds elapsed */
    uint8_t index = 0;

    wiced_seconds++;

    if (wiced_seconds & 1)
    {
        for (index = 0; index < sizeof(output_pin_list); index++)
        {
            wiced_hal_gpio_set_pin_output(output_pin_list[index], GPIO_PIN_OUTPUT_LOW);
        }
    }
    else
    {
        for (index = 0; index < sizeof(output_pin_list); index++)
        {
            wiced_hal_gpio_set_pin_output(output_pin_list[index], GPIO_PIN_OUTPUT_HIGH);
        }
    }
}

And when the button is pressed all it does is switch back and forth between two different intervals for the timer.  And after the switch it restarts the timer.

/*
 * Handle interrupt generated due to change in the GPIO state
 */
void hal_gpio_app_interrrupt_handler(void *data, uint8_t pin)
{
    static uint32_t blink_freq = LED_BLINK_FREQ_A_IN_SECONDS;

    // toggle LED blink rate upon each button press
    if (blink_freq == LED_BLINK_FREQ_A_IN_SECONDS)
    {
        blink_freq = LED_BLINK_FREQ_B_IN_SECONDS;
    }
    else
    {
        blink_freq = LED_BLINK_FREQ_A_IN_SECONDS;
    }

    if (wiced_stop_timer(&hal_gpio_app_timer) == WICED_SUCCESS)
    {
        wiced_start_timer(&hal_gpio_app_timer, blink_freq);
    }

    // clear the interrupt status
    wiced_hal_gpio_clear_pin_interrupt_status(pin);
}

Run hal_i2c_master

This CYW920719Q40EVB_01 development kit has an I2C LSM9DS1 accelerometer on it.  And I noticed that when looking around in the snips that the Snip called “hal_i2c_master.c” appears to talk to the chip.  Here is a little section of the comments from the top of the snip

 *
 * WICED sample application for I2C Master usage
 *
 * This application demonstrates how to use I2C driver interface
 * to send and receive bytes or a stream of bytes over the I2C hardware as a master.
 * The on-board LSM9DS1 motion sensor acts as the I2C slave

So, lets run the snip and see what happens.  If you don’t have a make target… well then make one.

Then make the make target.

It turns out that “0” is a bug in the example project.  And printing out the WHO_AM_I register isnt really very interesting.

Modify the hal_i2c_master.c Create a Better Project

I don’t like making changes inside of the WICED SDK files.  But, I want to fix the bug and printout something more interesting.  So start by creating a new folder in the wiced_bt_class folder

Type in the directory name L4_Accelerometer (notice in the screenshot below I mistyped it)

Select the makefile.mk and the hal_i2c_master.c then right click copy the files.

Then select the L4_Accelerometer folder and pick paste.

Create a make target for the L4_Accelerometer

Build it to make sure it still works.

Now that we have a base to stand-on.  Let’s have a look at the data sheet.  I have used these before and I know that you need to turn on the Accelerometer to give you anything interesting.  Turns out CTRL_REG_6_XL is the control register we need.

The other interesting registers are the actual output of the accelerometer.  That is 0x28 –> 0x2D

Start by modifying the function initialize_app to turn on the accelerometer by writing 0x40 to register 0x20

uint8_t status;
    // Turn on Accelerometer - Register 0x20... 2g accelerometer on @ 50hz
    uint8_t data[] = {0x20, 0x40};
    status = wiced_hal_i2c_write(data,sizeof(data),LSM9DS1_ACC_GYRO_I2C_ADDRESS);

I dont really like printing the values every two seconds so I will modify the timer:

  • Make it a milisecond timer
  • Set it to print every 500ms
if ( WICED_SUCCESS == wiced_init_timer( &seconds_timer, &comboread_cb, 0, WICED_MILLI_SECONDS_PERIODIC_TIMER )) {
        if ( WICED_SUCCESS != wiced_start_timer( &seconds_timer, 500 )) {
            WICED_BT_TRACE( "Seconds Timer Error\n\r" );
        }
    }

Here is the whole function initialize_app together

void initialize_app( void )
{
    wiced_hal_i2c_init();
    uint8_t status;

    // Turn on Accelerometer - Register 0x20... 2g accelerometer on @ 50hz
    uint8_t data[] = {0x20, 0x40};
    status = wiced_hal_i2c_write(data,sizeof(data),LSM9DS1_ACC_GYRO_I2C_ADDRESS);


    /* register callback for button available on the platform */
    wiced_platform_register_button_callback( WICED_PLATFORM_BUTTON_1, button_cb, NULL, WICED_PLATFORM_BUTTON_RISING_EDGE);

    current_speed = wiced_hal_i2c_get_speed();

    WICED_BT_TRACE("Default I2C speed: %d KHz\n", (CLK_FREQ/current_speed));

    /*Start a timer for POLL_TIMER seconds*/

    if ( WICED_SUCCESS == wiced_init_timer( &seconds_timer, &comboread_cb, 0, WICED_MILLI_SECONDS_PERIODIC_TIMER )) {
        if ( WICED_SUCCESS != wiced_start_timer( &seconds_timer, 500 )) {
            WICED_BT_TRACE( "Seconds Timer Error\n\r" );
        }
    }

}

Next I need to modify the comboread_cb callback.  It will

  • Setup a structure to hold the three acceleration values (Line 145)
  • Then it will read from the LSM9DS1 (Line 152)
  • Then print them (Line 156)
/******************************************************************************
 * This function reads the value from I2C slave and prints it
 *****************************************************************************/

void comboread_cb (uint32_t arg)
{
    UINT8  status = 0xFF;
    UINT8 reg_add = 0x28; // Acceleromter register

    typedef struct {
        int16_t ax;
        int16_t ay;
        int16_t az;
    } __attribute__((packed)) accel_val_t;

    accel_val_t data;
    status = wiced_hal_i2c_combined_read((UINT8 *)&reg_add, sizeof(UINT8), (uint8_t *)&data, sizeof(data), LSM9DS1_ACC_GYRO_I2C_ADDRESS);

    if(I2CM_SUCCESS == status) {

        WICED_BT_TRACE("Ax=%d Ay=%d Az=%d\n",data.ax,data.ay,data.az);
    }else if(I2CM_OP_FAILED == status) {
        WICED_BT_TRACE("I2C comboread operation failed\r\n");
    }else if(I2CM_BUSY == status) {
        WICED_BT_TRACE("I2C busy\r\n");
    }else{
        WICED_BT_TRACE("Unknown status from I2C\r\n");
    }

}

Now double click the make target and make sure that everything is working.

Lesson 3 – WICED Bluetooth: The Super Mux Tool

WICED Bluetooth Using the CYW20719

# Title Comment
0 A Two Hour WICED Bluetooth Class WICED Bluetooth Using the CYW20719 in all its glory
1 Resources Links to all of the Cypress WICED information including videos, application notes etc.
2 Your First Project Making Hello World & the Blinky LED
3 The Super Mux Tool Learning about platforms and the Super Mux Tool
4 Snips Using the example projects to learn Bluetooth
5 Bluetooth Designer Using the tool to customize a project and get going fast
6 The CCCD & Notification Writing back to the Central
7 Advertising  Beacon Building a beacon project to advertise your custom information 
8 Scanner Viewing the world around you
9 Bluetooth Classic SPP Using the Serial Port Profile to Transmit Lots of Data

Source code: 

  • git@github.com:iotexpert/wiced_bt_intro.git
  • https://github.com/iotexpert/wiced_bt_intro

 

Summary

You probably noticed and wondered “Why did he use WICED_LED_2 instead of WICED_LED_1”?  The answer to that question is that by default the CYW920719Q40EVB_01 is setup with WICED_LED_2 enabled as a GPIO and WICED_LED_1 used for another purpose.  But to what purpose?  In this lesson we will answer the questions:

  1. What are the default pins?
  2. How do you use the SuperMux tool?
  3. How do you use a PWM?

To do this we are going to copy the L2_HelloWorld project and add a PWM to drive the Green LED also known as WICED_LED_1.

The steps we are going to follow are

  1. Copy the L2_HelloWorld to start a new project called L3_SuperMux
  2. Rename L2_HelloWorld.c
  3. Fix the makefile.mk for the updated source file
  4. Create a new make target
  5. Program to make sure everything is still working
  6. Look at the platform files for CYW920719Q40EVB_01
  7. Run  the SuperMux Tool
  8. Delete the SPI Slave_1 From the SuperMux
  9. Add an LED to the SuperMux
  10. Configure the LED to P28
  11. Apply the SuperMux configuration
  12. Look at the new files added to the project
  13. Look a the makefile.mk
  14. Look L3_SuperMux_pin_config.c
  15. Update L3_SuperMux.c to have correct includes
  16. Update L3_SuperMux.c to start the clock, pin and PWM
  17. Program the project
  18. Look at the Hardware Abstraction Layer Documentation

Copy L2_HelloWorld –> L3_SuperMux

Instead of starting from a blank project.  Lets make a copy of the L2_HelloWorld project.  If you right click on the L2_HelloWorld folder and select copy

Then click on the “wiced_bt_class” folder and select paste.

WICED Studio will then complain that you already have a directory called “L2_HelloWord” and give you the opportunity to rename it.  Call the new project “L3_SuperMux”

Now you need to rename the L2_HelloWorld.c to be L3_SuperMux.c.  Right click on the L2_HelloWorld.c and select rename

Then give it a new file name… like L3_SuperMux.c

Double click makefile.mk and edit it.  You need to change the comment, and the name of the APP_SRC source file.

#
# Lesson 3 - SuperMux
#
APP_SRC +=  L3_SuperMux.c

C_FLAGS += -DWICED_BT_TRACE_ENABLE

Create a make target for this project by right clicking the L2_HelloWorld Make Target, then selecting “New”

That will make a new target… and it will bring up this dialog box.  Notice that it named the target “Copy of …”

Fix it to be “L3_SuperMux” like this:

You should now have an exact copy of L2_HelloWorld, in the project L3_SuperMux.  Double click the make target and make sure that things are still working.  When you build you should get this.  Don’t forget to “Start the Bootloader” if the programming doesn’t work.

Platform Files

If you look on the back of your CYW920719Q40EVB-01 development kit you will find the exact pin map of this board.  On this picture you can see that LED1 is connected to P28

In WICED Studio, the world “Platform” is just another word for Board Support Package.  Basically all of the configuration required to build the firmware for a specific board.  If you click on platforms you will find a directory for the CYW920719Q40EVB.  All of the default configuration for the pins are located in the file “wiced_platform_pin_config.c”

If you look at this file closely, you will see on line 47 that pin P28 is setup as the MOSI of WICED_SPI_1.  That isnt a GPIO!!!.  And you will see a whole block of code on line 74 that is commented out that COULD   configure P28 as a GPIO.  But that would require modifying our default platform files, which I dont want to do.  Now what?  Simple use the SuperMux tool.

/* all the pins available on this platform and their chosen functionality */
const wiced_platform_gpio_t platform_gpio_pins[] =
    {
        [PLATFORM_GPIO_0 ] = {WICED_P00, WICED_GPIO              },      //Button
        [PLATFORM_GPIO_1 ] = {WICED_P01, WICED_SPI_1_MISO        },
        [PLATFORM_GPIO_2 ] = {WICED_P02, WICED_PCM_OUT_I2S_DO    },
        [PLATFORM_GPIO_3 ] = {WICED_P04, WICED_PCM_IN_I2S_DI     },
        [PLATFORM_GPIO_4 ] = {WICED_P06, WICED_GCI_SECI_IN       },
        [PLATFORM_GPIO_5 ] = {WICED_P07, WICED_SPI_1_CS          },
        [PLATFORM_GPIO_6 ] = {WICED_P10, WICED_GCI_SECI_OUT      },
        [PLATFORM_GPIO_7 ] = {WICED_P16, WICED_PCM_CLK_I2S_CLK   },
        [PLATFORM_GPIO_8 ] = {WICED_P17, WICED_PCM_SYNC_I2S_WS   },
        [PLATFORM_GPIO_9 ] = {WICED_P26, WICED_GPIO              },      //Default LED 2
        [PLATFORM_GPIO_10] = {WICED_P25, WICED_I2C_1_SCL         },
        [PLATFORM_GPIO_11] = {WICED_P28, WICED_SPI_1_MOSI        },      //Optional LED 1
        [PLATFORM_GPIO_12] = {WICED_P29, WICED_I2C_1_SDA         },
        [PLATFORM_GPIO_13] = {WICED_P33, WICED_UART_2_TXD        },
        [PLATFORM_GPIO_14] = {WICED_P34, WICED_UART_2_RXD        },
        [PLATFORM_GPIO_15] = {WICED_P38, WICED_SPI_1_CLK         },
    };

/* LED configuration */
const wiced_platform_led_config_t platform_led[] =
    {
        [WICED_PLATFORM_LED_2] =
            {
                .gpio          = (wiced_bt_gpio_numbers_t*)&platform_gpio_pins[PLATFORM_GPIO_9].gpio_pin,
                .config        = ( GPIO_OUTPUT_ENABLE | GPIO_PULL_UP ),
                .default_state = GPIO_PIN_OUTPUT_HIGH,
            },

// We can use either LED1 or SPI1 MOSI, by default we are using WICED_P28 for SPI1 MOSI,
// uncomment the following initialization if WICED_P28 is to be used as an LED and set PIN
// functionality in platform_gpio_pins as WICED_GPIO

//        [WICED_PLATFORM_LED_1] =
//            {
//                .gpio          = (wiced_bt_gpio_numbers_t*)&platform_gpio_pins[PLATFORM_GPIO_11].gpio_pin,
//                .config        = ( GPIO_OUTPUT_ENABLE | GPIO_PULL_UP ),
//                .default_state = GPIO_PIN_OUTPUT_HIGH,
//            }
    };

SuperMux Tool

The SuperMux tool is a GUI for setting the default configurations of the Pins on the chip.  Like all capable MCUs, this chip has PWMs, SPIs, UARTs, GPIOs, I2C, ADCs etc.  Each pin on the chip can do a bunch of different functions, but only one at a time.  Each pin has a multiplexor in front of it that selects the function of that pin.  The SuperMux tool helps you setup the multiplexors for each pin on the chip.

To run the SuperMux tool, first click on your project directory (remember L3_SuperMux).  The select File–>New–>WICED SuperMux GPIO Pin Configuration

It will ask you which “App Name” you want it to work on.  Since we clicked on the L3_SuperMux app, it uses that name by default.  Press Next

The SuperMux Wizard will give you the opportunity to select which pins you want to configure.  It also shows you the default configuration of each of the pins.  In this case just press “Next” because we want to configure them all.

Now you will see the functions of the chip and which pins they are assigned to.  Notice that WICED_P28 is assigned as the MOSI of SPI(Slave)_1.  We don’t want that.

Remove the SPI(Slave)_1 by selecting it and then pressing the “Remove” button

Now your screen will look like this.  In order to add a new pin configuration you can press the little “+” at the bottom of the function column.

Next press the little “+” button and select LED.

The select which Pin you want assigned to the LED.  In this case we want WICED_P28

After you press finish you will notice that it adds a several files to your project.  And you notice that it creates a file called “makefile.mk.bak” (which is the backup of the original makefile)

First look at the makefile and notice that it added the “L3_SuperMux_pin_config.c” to the sources and added a CFLAG

#
# Lesson 3 - SuperMux
#
APP_SRC +=  L3_SuperMux.c

C_FLAGS += -DWICED_BT_TRACE_ENABLE
C_FLAGS += -DSMUX_CHIP=$(CHIP)
APP_SRC += L3_SuperMux_pin_config.c

So, what is up with the  L3_SuperMux_pin_config.c.  OH!!! I See, this is just a replacement for the default platform configuration.  Notice that P28 is now a WICED_GPIO and that it is now defined in the LED list.

wiced_platform_gpio_t platform_gpio_pins[]=
	{
		[PLATFORM_GPIO_0]	= {WICED_P00, WICED_GPIO},
		[PLATFORM_GPIO_1]	= {WICED_P02, WICED_PCM_OUT_I2S_DO},
		[PLATFORM_GPIO_2]	= {WICED_P04, WICED_PCM_IN_I2S_DI},
		[PLATFORM_GPIO_3]	= {WICED_P06, WICED_GCI_SECI_IN},
		[PLATFORM_GPIO_4]	= {WICED_P10, WICED_GCI_SECI_OUT},
		[PLATFORM_GPIO_5]	= {WICED_P16, WICED_PCM_CLK_I2S_CLK},
		[PLATFORM_GPIO_6]	= {WICED_P17, WICED_PCM_SYNC_I2S_WS},
		[PLATFORM_GPIO_7]	= {WICED_P25, WICED_I2C_1_SCL},
		[PLATFORM_GPIO_8]	= {WICED_P26, WICED_GPIO},
		[PLATFORM_GPIO_9]	= {WICED_P28, WICED_GPIO},
		[PLATFORM_GPIO_10]	= {WICED_P29, WICED_I2C_1_SDA},
		[PLATFORM_GPIO_11]	= {WICED_P33, WICED_UART_2_TXD},
		[PLATFORM_GPIO_12]	= {WICED_P34, WICED_UART_2_RXD},
	};

const wiced_platform_button_config_t platform_button[WICED_PLATFORM_BUTTON_MAX]=
	{
		[WICED_PLATFORM_BUTTON_1] =
			{
				.gpio			= &platform_gpio_pins[PLATFORM_GPIO_0].gpio_pin,
				.config			= (GPIO_INPUT_ENABLE | GPIO_PULL_UP),
				.default_state	= GPIO_PIN_OUTPUT_LOW,
				.button_pressed_value	= GPIO_PIN_OUTPUT_LOW,
			},
	};

const size_t button_count =  (sizeof(platform_button) / sizeof(wiced_platform_button_config_t));


const wiced_platform_led_config_t platform_led[WICED_PLATFORM_LED_MAX]=
	{
		[WICED_PLATFORM_LED_1] =
			{
				.gpio			= &platform_gpio_pins[PLATFORM_GPIO_9].gpio_pin,
				.config			= (GPIO_OUTPUT_ENABLE | GPIO_PULL_UP),
				.default_state	= GPIO_PIN_OUTPUT_HIGH,
			},
		[WICED_PLATFORM_LED_2] =
			{
				.gpio			= &platform_gpio_pins[PLATFORM_GPIO_8].gpio_pin,
				.config			= (GPIO_OUTPUT_ENABLE | GPIO_PULL_UP),
				.default_state	= GPIO_PIN_OUTPUT_HIGH,
			},
	};

Now that the pins are configured.  We need to setup the PWM.

Configure the Clock and the PWM

Now I will add a little bit of code to the top of  our L3_SuperMux.c to configure the PWM, Clock and Pin.

First add includes for the ACLK and PWM driver.

#include "wiced_hal_aclk.h"
#include "wiced_hal_pwm.h"

Then startup the Clock, Pin and PWM.

    wiced_hal_aclk_enable(2000, ACLK1, ACLK_FREQ_1_MHZ );
    wiced_hal_pwm_configure_pin (WICED_GPIO_PIN_LED_1, PWM1 );
    wiced_hal_pwm_start(PWM1, PMU_CLK, 0xFFFF-500, 0xFFFF-999,0);

If you want to turn on the PWM you need to do three things

  1. Turn on a clock to drive it (line 17) sets the clock frequency to 2000hz
  2. Attach the PWM to a Pin (line 18) attaches PWM 1 to the pin
  3. Turn on the PWM which is a 16-bit up-counting PWM.  When the PWM is reset it will go to 0xFFFF-999 (the period)… then it will switch at 0xFFFF-500 (the compare value)

When you program this your Green LED aka WICED_LED_1 is being driven by the PWM.  And your RED LED is being driven by your firmware.

Documentation

All of the hardware blocks on the chip have a set of API functions to help you interface with them.  You can find all of that in the Documentation

Lesson 2 – WICED Bluetooth: Your First Project(s)

WICED Bluetooth Using the CYW20719

# Title Comment
0 A Two Hour WICED Bluetooth Class WICED Bluetooth Using the CYW20719 in all its glory
1 Resources Links to all of the Cypress WICED information including videos, application notes etc.
2 Your First Project Making Hello World & the Blinky LED
3 The Super Mux Tool Learning about platforms and the Super Mux Tool
4 Snips Using the example projects to learn Bluetooth
5 Bluetooth Designer Using the tool to customize a project and get going fast
6 The CCCD & Notification Writing back to the Central
7 Advertising  Beacon Building a beacon project to advertise your custom information 
8 Scanner Viewing the world around you
9 Bluetooth Classic SPP Using the Serial Port Profile to Transmit Lots of Data

Source code: 

  • git@github.com:iotexpert/wiced_bt_intro.git
  • https://github.com/iotexpert/wiced_bt_intro

 

Summary

For our first project, I am going to stand on the shoulder of giants.  In 1978, Brian Kernighan and Dennis Ritchie published “The C Programming Language”.  Here are pictures of my copy.

Kernighan & Ritchie

The reason you do “Hello, World” is that you want to make sure that your compiler chain, programmer etc are all working correctly with something that is super simple.  The only change that I will make to their classic program is to add the “Blinking LED” which is the embedded developers version of “Hello, World”.

The concepts that I want to show in this lesson are.

  1. How to make a new project – makefile.mk, <appname>.c
  2. How NOT to make a new project
  3. How to create a “Make Target”
  4. CYW920719Q40EVB01 Development Kit
  5. WICED PUART and WICED HCI UART
  6. How to start the bootloader
  7. Where the documentation resides for the WICED 20719 hardware abstraction layer
  8. WICED uses ThreadX RTOS

To make this first project the steps are:

  1. Make a new folder called wiced_bt_class  in the Apps Folder
  2. Make a new folder called L2_HelloWorld in the wiced_bt_intro Folder
  3. Create a new file called L2_HelloWorld.c
  4. Create a new file called makefile.mk
  5. Add the code to print HelloWorld & blink the LED to L2_HelloWorld.c
  6. Add the secret incantation to makefile.mk to build the project
  7. Create a “Make Target”
  8. Connect the development kit to your computer
  9. Attach a serial terminal to the PUART
  10. Run the Make Target to Build and Program

Lets do this!

DO NOT DO File->New Project

I always hate to start with a negative statement… but DO NOT make a file project by doing File->New Project.  This is used for creating a new Eclipse project, not a new WICED Studio project.  In WICED Studio we use the make external build system.  If you do File->New Project all hell is going to break loose.  So don’t do any of the things on this menu:

Hello World & Blinking LED

Now lets get on with making a WICED Studio Project.  First create a new folder to hold the projects for the Class in the “Apps” folder by right-clicking and selecting New->Folder

Give it the name “wiced_bt_class”

Create a folder to hold the first project called L2_HelloWorld

Call the folder L2_HelloWorld

Make a new file called L2_HelloWorld.c by right clicking on the L2_HelloWorld folder and selecting New–>File

Give it the name L2_HelloWorld.c

Make a new file called makefile.mk by right clicking on the L2_HelloWorld directory and selecting New->File

and giving it the name makefile.mk

Add some code to the L2_HelloWorld.c

#include "wiced.h"
#include "sparcommon.h"
#include "wiced_platform.h"
#include "wiced_rtos.h"
#include "wiced_hal_gpio.h"
#include "wiced_bt_trace.h"

APPLICATION_START()
{
    wiced_set_debug_uart(WICED_ROUTE_DEBUG_TO_PUART);

    WICED_BT_TRACE("Hello, World\n");
    while(1)
    {

        WICED_BT_TRACE("Setting 0\n");
        wiced_hal_gpio_set_pin_output(WICED_GPIO_PIN_LED_2,0);
        wiced_rtos_delay_milliseconds(500,KEEP_THREAD_ACTIVE );
        WICED_BT_TRACE("Setting 1\n");
        wiced_hal_gpio_set_pin_output(WICED_GPIO_PIN_LED_2,1);
        wiced_rtos_delay_milliseconds(500,KEEP_THREAD_ACTIVE );
    }
}

Add the secret incantation to the makefile.mk

#
# Lesson 2 - Hello, World
#
APP_SRC +=  L2_HelloWorld.c

C_FLAGS += -DWICED_BT_TRACE_ENABLE

Create a make target

The make target has a VERY specific format.  It is:

directory.directory.appname-platform download

In our case we have all of our projects in a directory called “wiced_bt_class”.  Then we have a directory called “L2_HelloWorld” which holds the exact project.  And our platform name is “CYW920719Q40EVB_01”

Connect the Development Kit To Your Computer

When you plug in your development kit, it will USB enumerate a TWO serial ports.  One of the serial ports (the first one) is called the “WICED HCI UART”.  The second serial port is called the “WICED Peripheral UART” (this is often abbreviated “PUART”)

One of the key things that the WICED HCI UART is used as is a UART to download new code to the bootloader.

The PUART is used as a general purpose serial port.  When we call this function it causes all of our “WICED_BT_TRACE” outputs to go to the the PUART.

    wiced_set_debug_uart(WICED_ROUTE_DEBUG_TO_PUART);

You can see these two UARTs on a PC by running the device manager.

You can see COM17 is the “WICED HCI UART” and COM18 is the “WICED Peripheral UART”

On my Mac I use the program “Serial” which I downloaded from the App Store.

When I run Serial and then to open a Port

You can see the two UARTs.

In order to see the output I will connect to the port with the settings

  • 115200 Baud
  • 8-n-1 (Data bits, Parity, Stop Bits)

With my PC I typically use Putty (remember it was COM18 from the screen above)

On the Mac program serial you can configure it with Terminal->Settings

Program your Development Kit

In the Make Target window you should see a bunch of “targets”.  You probably have a bunch more targets, which came in your installation of WICED Studio by default, but I deleted a bunch of them so I could just see the ones that I created.

To build and program your project, double click the make target we made before.

When you look in the console you should see something like this:

And when you look at your serial terminal you will see this:

And you should also see the blinking LED!!!

Start the Bootloader

If you get this message there are three posibilites

  1. The kit isn’t plugged in
  2. The driver didn’t install properly
  3. The bootloader wont start

Check the first two… and if that doesnt work then what this means is that the bootloader is not listening on the WICED HCI UART.  In order to fix this you need to press reset and hold down the button called “Recover”.  Then release the reset, then release the recover button.  What does this do?  Simple, when the chip comes out of reset, if the recover button is pressed, the chip starts the bootloader instead of the main application.

Here is a picture of the bottom corner of the board.  The button circled in Green is the “Recover”.  The button in Red is “Reset” and the Blue surrounds the LED circuit.

The two LEDs are labeled LED1 and LED2.  LED2 is the Red one, LED1 is the Green one.  The dip switches circled in Blue connect or disconnect the LEDs from the CYW20719.  In my case you can see (barely) that the switch is set to On.  Both of these LEDs are active LOW (0 turns them on)

WICED HTTP Client

WICED HTTP & 943907 & CY3280 CapSense

Summary

In the previous articles I talked about the GE Hackathon, using WICED and CapSense, and finally creating a Particle Photon configuration.  In this article I will show you the WICED HTTP Client firmware which will read the button state and send it via WICED HTTP to the Particle Cloud.  To build this project I will start from the I2C Read firmware that I talked about in this article.

There are two parts of this application

  • The “main” application which reads the buttons and sends a message
  • The “sendMessage” function which builds a WICED HTTP message and sends it to the Particle cloud.

Main Application

I took the code from the previous example (CY3280 –> I2C –> WICED) and only made a few modifications (though I rearranged things a bit to make it easier to look at)

  • I joined the network (line 126)
  • I look up the IP address of the Particle Cloud (line 128)
  • Then I send a HIGH or LOW via the sendMessage function based on the state of the buttons (all the buttons do the same thing)
#include "wiced.h" 
#include <stdlib.h> 

#define I2C_ADDRESS (0x37) 
#define BUTTON_REG (0xAA) 
wiced_semaphore_t buttonPress; // used to signal in ISR to signal main
void application_start( )
{
    wiced_init();                                 // Initialize the WICED device
    wiced_rtos_init_semaphore(&requestSemaphore); // Initialize
    wiced_result_t result;

    wiced_network_up(WICED_STA_INTERFACE, WICED_USE_EXTERNAL_DHCP_SERVER, NULL);

    wiced_hostname_lookup( SERVER_HOST, &ip_address, DNS_TIMEOUT_MS, WICED_STA_INTERFACE );
    wiced_rtos_init_semaphore(&buttonPress);

    // WICED_GPIO_9 is the MBR3 Interrupt Pin
    wiced_gpio_init(WICED_GPIO_9,INPUT_PULL_UP);
    wiced_gpio_input_irq_enable(WICED_GPIO_9, IRQ_TRIGGER_FALLING_EDGE, button_isr, NULL); /* Setup interrupt */

    /* Setup I2C master */
    const wiced_i2c_device_t i2cDevice = {
            .port = WICED_I2C_2,
            .address = I2C_ADDRESS,
            .address_width = I2C_ADDRESS_WIDTH_7BIT,
            .speed_mode = I2C_STANDARD_SPEED_MODE
    };

    wiced_i2c_init(&i2cDevice);

    /* Tx buffer is used to set the offset */
    uint8_t tx_buffer[] = {BUTTON_REG};
    uint8_t buttonStatus;
    while ( 1 )
    {
        wiced_rtos_get_semaphore(&buttonPress,WICED_WAIT_FOREVER);

        // Do this until the MBR3 is alive.  It goes into deep sleep and wakes when you
        // send the first command.
        do {
            result = wiced_i2c_write(&i2cDevice, WICED_I2C_START_FLAG | WICED_I2C_STOP_FLAG, tx_buffer, sizeof(tx_buffer));
        }
        while(result != WICED_SUCCESS);

        result=wiced_i2c_read(&i2cDevice, WICED_I2C_START_FLAG | WICED_I2C_STOP_FLAG, &buttonStatus, sizeof(buttonStatus));
        if(buttonStatus > 0)
        {
            WPRINT_APP_INFO(("Sending On\n"));
            sendMessage("HIGH");
        }
        else
        {
            WPRINT_APP_INFO(("Sending Off\n"));
            sendMessage("LOW");
        }

    }
}

Send Message via WICED HTTP

The WICED HTTP sendMessage function simply

  • Creates a http_client (which is just a mechanism to keep track of an HTTP connection
  • Sets up a connection (lines 77-80)
  • Makes the connection (line 82)
  • Creates the message (line 88) in “application/x-www-form-urlencoded” format
  • Builds the HTTP headers for a HTTP “POST” (lines 90-105)
  • Write the Request (lines 108 –> 112)
  • Waits for the response using semaphore (line 114)
  • Destroys the connection (line 115 –> 116)
#include "wiced_tls.h" 
#include "http_client.h" 
#define SERVER_PORT ( 443 ) 
#define SERVER_HOST "api.particle.io" 
#define SERVER_RESOURCE "/v1/devices/2a001b000347353137323334/digitalwrite" 
#define PARTICLE_ACCESS_TOKEN "1311f9217a60" 
#define DNS_TIMEOUT_MS ( 10000 ) 
#define CONNECT_TIMEOUT_MS ( 3000 ) 
wiced_semaphore_t requestSemaphore; // used to signal request is done static http_client_t client; 
static http_request_t request; 
static http_client_configuration_info_t client_configuration; 
static wiced_ip_address_t ip_address; 
/* void sendMessage - Send HTTP request to turn on or off the LED
*/
void sendMessage( char *state )
{
http_client_init( &client, WICED_STA_INTERFACE, event_handler, NULL );
/* configure HTTP client parameters */
client_configuration.flag = (http_client_configuration_flags_t)(HTTP_CLIENT_CONFIG_FLAG_SERVER_NAME | HTTP_CLIENT_CONFIG_FLAG_MAX_FRAGMENT_LEN);
client_configuration.server_name = (uint8_t*)SERVER_HOST;
client_configuration.max_fragment_length = TLS_FRAGMENT_LENGTH_1024;
http_client_configure(&client, &client_configuration);
http_client_connect( &client, (const wiced_ip_address_t*)&ip_address, SERVER_PORT, HTTP_USE_TLS, CONNECT_TIMEOUT_MS );
http_header_field_t header[3]; // Three headers
char messageBody[128];        // Enough to hold the message body
char messageLengthBuffer[10]; // Enough to hold the characters for the Content-Length: header
sprintf(messageBody,"access_token=%s&params=D7%%2C%s",PARTICLE_ACCESS_TOKEN,state);
header[0].field        = HTTP_HEADER_HOST;
header[0].field_length = sizeof( HTTP_HEADER_HOST ) - 1;
header[0].value        = SERVER_HOST;
header[0].value_length = sizeof( SERVER_HOST ) - 1;
#define MIME_FORM_URL "application/x-www-form-urlencoded"
header[1].field        = HTTP_HEADER_CONTENT_TYPE;
header[1].field_length = sizeof( HTTP_HEADER_CONTENT_TYPE ) - 1;
header[1].value        =  MIME_FORM_URL;
header[1].value_length = sizeof(  MIME_FORM_URL ) - 1;
sprintf(messageLengthBuffer," %d",strlen(messageBody)); // Put the message body into the buffer so that you can strlen it
header[2].field        = HTTP_HEADER_CONTENT_LENGTH;
header[2].field_length = sizeof( HTTP_HEADER_CONTENT_LENGTH ) - 1;
header[2].value        =  messageLengthBuffer;
header[2].value_length = strlen(messageLengthBuffer);
// Build the HTTP Message
http_request_init( &request, &client, HTTP_POST, SERVER_RESOURCE, HTTP_1_1 );
http_request_write_header( &request, &header[0], 3 ); // 3 headers
http_request_write_end_header( &request );
http_request_write(&request,(uint8_t*)messageBody,strlen(messageBody));
http_request_flush( &request );
wiced_rtos_get_semaphore(&requestSemaphore,10000); // wait up to 10 seconds to close the request and the client
http_request_deinit(&request);
http_client_deinit(&client);
}

WICED HTTP Event Handler

The way that the WICED HTTP  executes is that it has a worker thread waiting on the TCP socket.  When it gets a response it runs your callback function and tells you what happened.  In this case I just tell my thread to close the connection and move on.

/*
* void event_handler() is called by the http_client function when
*  Data is received from the server
*  a connection is made
*  a disconnect occurs
*
*  When data is received I assume that the response is good and I reset the semaphore so that another request can happen
*/
static void event_handler( http_client_t* client, http_event_t event, http_response_t* response )
{
switch( event )
{
case HTTP_CONNECTED: // Dont do anything
break;
case HTTP_DISCONNECTED: // Disconnect if you get this event
wiced_rtos_set_semaphore(&requestSemaphore);
break;
case HTTP_DATA_RECEIVED: // Disconnect if you get this event
wiced_rtos_set_semaphore(&requestSemaphore);
break;
default:
break;
}
}

 

CY3280 MBR3 & WICED CYW943907

Summary

In the last Article I talked about the GE Megahackathon.  One of the groups at the event got interested in using a CY3280 MBR3 to send signals via a WICED CYW943907 to the Particle IO server which was connected to a Particle Photon.  I helped them with the implementation and thought that it would be useful to show here.

CYW3280 & WICED CYW943907

Cypress CY3280 MBR3

The CY3280 MBR development kit is a CapSense demonstration kit that shows the Mechanical Button Replacement 3 chip.  It features 4 CapSense buttons with LEDs, a proximity sensor, and a buzzer.  It is connected to another MCU via the Arduino pins. of the WICED CYW943907.  The device sits on the I2C bus and acts as an I2C Slave.  You configure it using EZ Click.

When you run EZ Click you can setup the configure the internal registers of the MBR3 to make the board act like a bunch of different things.  In this case I turned on

  • The MBR buttons 1-4 (you can see them in the picture above)
  • The Flanking Sensor rejection which makes it so that you can only press one button at a time.
  • All of the automatic tuning features.

EZ-Click CY3280

Once the main CapSense is configured, I moved to the other part of the configuration where I setup

  • The 4 LEDs to toggle and be full brightness when on
  • The buzzer to buzz for 100ms at 4kHz when something happens
  • The host interrupt pin as CS15/SH/HI.  This made the Arduino pin D2 be an interrupt when something happened so that WICED would poll the MBR3

EZ-Click CY3280

Once these settings were all done, I downloaded the firmware configuration via the KitProg USB connector.  Then I tested it using the bridge control panel which I have shown you a bunch of different times in the past.  The MBR3 acts as an I2C slave.  To find out what the state of the buttons are you need to read register 0xAA.  The only little trick is that the chip goes to sleep to save power.  In order to wake it up you need to send an I2C transaction, which ends up getting NAK’d.  But the next transaction you send will be ACKd.  In the screenshot below you can see that I tried two of the buttons (0x08 and 0x20)

Bridge Control Panel

One problem that I had is that the power system of this board is setup to take 5V from the Arduino base board but the WICED development kit gives only 3.3v.  Here is a picture of the power system from the MBR3 schematic.

CY3280 Power Supply

The MBR3 can run on 3.3Vs.  In fact it can run all the way down to 1.7v and up to 5.5v, but for some reason (which I can’t remember) we made the board only work with 5.0v.  To fix this problem I removed J12 and then wired a wire from the 3.3V Arduino pin.  The wire is soldered onto the 3.3v pin, but has a female connector on the other side so that it can be plugged into J12.  Here is a picture:

CY3280

The last thing that I needed to do was move the jumpers to position “A” which made the host interrupt pin be connected to D2, and move the I2C jumpers so that the MBR3 was connected to the Arduino instead of the P5LP kitprog.  You can see that in the J3_scl and J3_sda in the picture above.

WICED CYW943907

The CYW934907AEVAL1F is an development kit for the Cypress 43907 MCU+WiFi module.  The WICED CYW943907 board can do dual band (2.4 and 5Ghz), 802.11 a/b/g/n,  Ethernet and a whole bunch of other stuff.

WICED CYW943907

The first firmware that I wrote in WICED Studio:

  • Sets up an ISR to unlock a semaphore when the interrupt occurs
  • Initialized WICED_GPIO_9 to be an input and connected to an ISR … this is also known as Arduino D2
  • Setup the I2C Master Hardware in the 43907
  • Wait for a semaphore (from the ISR)
  • Read the I2C register 0xAA from the MBR

The only trick in the firmware is that I read the I2C with a “do” loop until I get a valid result, meaning that the MBR3 has woken up.

#include "wiced.h"
#define I2C_ADDRESS (0x37)
#define BUTTON_REG (0xAA)
wiced_semaphore_t buttonPress;
/* Interrupt service routine for the button */
void button_isr(void* arg)
{
wiced_rtos_set_semaphore(&buttonPress);
}
/* Main application */
void application_start( )
{
wiced_init();	/* Initialize the WICED device */
WPRINT_APP_INFO(("Started\n"));
wiced_result_t result;
wiced_rtos_init_semaphore(&buttonPress);
// WICED_GPIO_9 is the MBR3 Interrupt Pin
wiced_gpio_init(WICED_GPIO_9,INPUT_PULL_UP);
wiced_gpio_input_irq_enable(WICED_GPIO_9, IRQ_TRIGGER_FALLING_EDGE, button_isr, NULL); /* Setup interrupt */
/* Setup I2C master */
const wiced_i2c_device_t i2cDevice = {
.port = WICED_I2C_2,
.address = I2C_ADDRESS,
.address_width = I2C_ADDRESS_WIDTH_7BIT,
.speed_mode = I2C_STANDARD_SPEED_MODE
};
wiced_i2c_init(&i2cDevice);
/* Tx buffer is used to set the offset */
uint8_t tx_buffer[] = {BUTTON_REG};
uint8_t buttonStatus;
while ( 1 )
{
wiced_rtos_get_semaphore(&buttonPress,WICED_WAIT_FOREVER);
// Do this until the MBR3 is alive.  It goes into deep sleep and wakes when you
// send the first command.
do {
result = wiced_i2c_write(&i2cDevice, WICED_I2C_START_FLAG | WICED_I2C_STOP_FLAG, tx_buffer, sizeof(tx_buffer));
}
while(result != WICED_SUCCESS);
result=wiced_i2c_read(&i2cDevice, WICED_I2C_START_FLAG | WICED_I2C_STOP_FLAG, &buttonStatus, sizeof(buttonStatus));
WPRINT_APP_INFO(("Button State = %X\n", buttonStatus)); /* Print data to terminal */
}
}

Once that is programmed I program and test the firmware.

Testing WICED CYW943907

In the next article I will modify all of this firmware and make the WICED CYW943907 send data via HTTP to the Cloud.

Leviton HomeKit D15S Light Switch – WICED WiFi

Summary

A couple of week ago I was in San Jose teaching a WICED WiFi programming class.  One of the bad-ass WICED Applications Engineers told me that Leviton was shipping a new Leviton HomeKit Light Switch that used WICED WiFi and Bluetooth called the Leviton DS15.  What was even cooler was the he had done a decent amount of the design with them.  So, I ordered a few of them from amazon.com to try out.  This started my normal spectacle of house-wiring that is a spiral of me shocking myself, bleeding, cussing and worst of all spilling my beer.  You would think that a guy with a degree from Georgia Tech and 25 years as a practicing engineer would know better… but props to those electricians out there as they have mad wiring skills.

The Panel

I know that it should be obvious.  Really, I do know.  But every time I start working on wiring in my house I think… “Oh I just have 1 or 2 things to do I don’t need to turn off the breaker.”  And literally every damn time, I shock the piss out of myself.  So, today I decided to turn over a new leaf and turn off the breaker.  What was interesting this time was I also decided to use my meter to make sure that the breaker was off… and today I discovered that the label on the panel in my barn is wrong.  Damn that electrician… I take back everything nice I said about electricians.  (That ugly handwriting is mine fixing the label)

electric panel

Installing the Leviton HomeKit Light Switch

I bought a bunch of the the Leviton HomeKit Decora switches from Amazon.com.  They are a normal looking paddle light switches, but they come with WiFi and Bluetooth and are compatible with Apple HomeKit.  This means you don’t need a special app on your phone to use them, and hopefully that means that the wife-factor is low enough.  (A hint for all you guys out there… if the lights don’t come on when your wife clicks them… you had better have a good couch).   Originally I had installed ZWave Light Switches in the barn as my son always leaves the stupid lights on, but I wanted to try a product that had chips in it that I work on.  Here we go:

Leviton HomeKit Light Switch

When you open the box you get the normal book worth of instructions, in 5 languages (or something).  You also get a cream colored faceplate.  The paper on the upper left of the picture shows the serial number that you scan in with the camera in the Leviton app to attach to your device to HomeKit.

Leviton HomeKit inside the box

Here is a zoom in on just the light switch.

Leviton HomeKit Light Switch

Here is a picture of the light switches in the box.  One of the things that I always struggle with is getting all of the wires to fit neatly in the box.  This box was originally done old school (only switching the hot)… which doesn’t work with these light switches.

Leviton HomeKit Light Switch Installed

Once you have the switches installed, you turn the breaker back on and run the Leviton App. The App will let you add the switch to HomeKit by scanning the numbers with your camera.

Leviton HomeKit Decora App

Once paired you can control them with the Leviton App.

Leviton HomeKit Decora App

Or with the HomeKit App.

Apple Homekit App

I did notice that there is now two generations of light switches 6 inches from where they were originally installed.   I suppose I should have cleaned that up.

Installation Aftermath

Finally… dont cry over spilled beer (actually do.. as it is a really good West 6th IPA)

West 6th IPA

 

Embedded World 2017: WICED WiFi, MQTT and the Amazon IoT Cloud (Part 2)

Summary

As I explained in yesterday’s article, I was unhappy about not connecting to Amazon AWS IoT cloud for my presentation at Electronica 2016.  In the last post I showed you how to build an Amazon AWS IoT MQTT Client in the WICED WiFi SDK that can Publish to the Amazon Message Broker.  Now I need to build a WICED App that can Subscribe to the ROBOT_POSITION topic and receive messages from the MQTT broker.  This series of articles is broken up like this:

  1. Amazon IoT & MQTT (Part 1)
  2. Modify & Test the WICED Publisher App (Part 1)
  3. Modify & Test the WICED Subscriber App (Part 2)
  4. Modify the Application to talk I2C to the PSoCs (Part 3)

Modify the WICED Subscriber App

As with the previous article, start by copying the App from the apps–>demo–>aws_iot–>pub_sub–>subscriber into your directory.  In my case that will be apps–>emb2017–>subscriber.  Then update the application “Name:” and “VALID_PLATFORMS” in the Makefile.  Remember that the App name must be unique.

WICED WiFi SDK

Then modify the DCT to have your networking information.  Don’t forget that the DCT is the device configuration table for WICED WiFi and is used to store the mostly static information (like network, passwords etc).

WICED WiFi Subscriber DCT

The next step is to make a few modifications to the actual firmware.  Specifically,

  • (line 60) Change the MQTT Broker IP address to the one assigned by Amazon
  • (line 61) Change the TOPIC to “ROBOT_POSITION”
  • (line 103) Print the message to the console

subscriber.c

In the last article I copied the Transport Layer Security (TLS) keys from Amazon into the resources–>apps–>aws_iot directory.  For this application I will use exactly the same keys.  Then, create a new make target for the App and program the board.

WICED WiFi Make Targets

Test the WICED WiFi Subscriber App

To test the application I will, once again, use the Amazon AWS IoT web MQTT Client to send messages to my board.  In the screen shot below you can see the console window of the 943907AEVAL1F board.  After programming it:

  • starts up
  • gets WICED and ThreadX going
  • connects to my network (WW101WPA, gets a DHCP address: 198.51.100.16)
  • Find the IP address of the MQTT broker (34.194.80.220)
  • Opens an MQTT connection to Amazon.

When I publish the message “20304050” using the MQTT Client to the “ROBOT_POSITION” topic,  you can see that it comes out on the console of the WICED WiFi development kit.

Amazon IoT MQTT Test Client

That proves that we have end-to-end communication.  In the last article, I will fix up the Publisher and Subscriber application to read and write the I2C connection so that it can actually do the Robot ARM control.

Electronica 2016 – The WICED Server

The last three days at Electronica I have been showing people how to build the Robot ARM Controller.  In previous posts I talked about the process for the Servo Motor controller and the CapSense user interface.

image009

In this post I am going to focus on the TCP/IP Server running on the Cypress WICED board.  Remember that this board performs two functions

  1. An I2C Master which writes data to the PSoC Servo Motor Controller
  2. A TCP/IP Server listening on TCP Port 40508.  The command format of the TCP/IP Packet is a 2-digit ASCII coded hex number representing the position of motor 1 followed by a 2-digit ASCII coded hex number for motor 2 e.g 3240 takes motor 1 to 0x32 aka 50% and 0x40 aka 64% for motor 2

The first section of code (lines 11-14) gets things going by starting WICED and attaching to the network.  The next section (lines 16-26) sets up the I2C Master and creates a standard message buffer (called tx_buffer).  Finally on lines 28-30 creates a socket and starts listening to TCP/IP Port 40508.

screen-shot-2016-11-11-at-7-30-38-am

The main loop of my server starts by waiting for a valid active connection (line 34-36).  Then when it gets a valid connection it

  • Line 43: receives the data into a packet
  • Line 45: gets a pointer (rbuffer) to the data in the packet
  • Line 46: translates the ASCII data into integers
  • Line 50: frees the tcp pack
  • Line 52: sends the updated position to the PSoC via I2C

screen-shot-2016-11-11-at-7-35-08-am

All of this source code is posted to the iotexpert GitHub site at git@github.com:iotexpert/E2016RobotArm.git

Electronica 2016 – Servo Motor PWMs

As I talked about in my previous post I am going to use a PSoC as a servo motor controller as well as a CapSense UI.  The problem is that I wanted a really easy way to plug the servo motors into the PSoC.  It seems like all of the servos have a 3 wire interface, Power, Ground and PWM.  Here is a picture that I got from Adafruit’s website.

155-01

I was originally hoping that I could connect that servo directly to the PSoC, drive a ‘1’ to the power and a ‘0’ to the ground and PWM to the third input.  But, it turns out that these things suck some serious juice (100+ma?) so driving the power with the PSoC isn’t in the cards.  Given them amount of time that I had left, there was not time for a custom board, so I was in the situation of using a breadboard with wires all over the place which is ugly and a bit of a pain.  However, on Thursday I thought that I might find a “Servo Shield” and sure enough there are a number of them out there including this one which I got from Adafruit.  The problem is this shield uses a 16 channel I2C –> PWM driver from NXP.  I am not a fan of doing things with peripheral chips that PSoC can do for itself.  But, when I got the shield this morning in the mail there was a cool prototyping area on the shield.  So, I made my own header for connecting to the PSoC.  Here is the front:

img_3309

And here is the back:

img_3308

You can see that I shorted the whole row of ground together with a big blog of solder and wire.  I did the same thing with the power (the middle row).  Then I made a wire from each of the 4 PWMs pins to a good place on the PSoC (which I could drive the pins directly from one of the TCPWMs)

img_3300

The board worked great on my bench.  The only thing that I have done which is VERY questionable is that I wired the power supply for the system directly to the V5.0 aka VBUS… which I suppose will get me through the conference, but is probably a bad idea (the green wire in the top picture)

As I was flying to Detroit I thought that I might try to see how the I2C->PWM worked… so I read the data sheet for the NXP PCA9685.  It turns out that the chip is pretty cool.  You can set the output frequency by setting a divider value in one of the registers (oxFE).  The number you set is val=round(25e6/(4096*rate)) – 1.  That means for me to get 50hz to drive the motors I need to set the divider to 121.  Then to set the duty cycle each output has a 12-bit PWM where you can set “LED ON” and a “LED Off” count.  For instance to get a 25% duty cycle you can set the On to 0 and the off to 1024.

After I got off the airplane in Detroit I went to get some “dinner” and I wanted to try out the shield so I hooked it up:

img_3304

You always get a bunch of funny looks in the airport when your table looks like this:

img_3310This left me with only one problem.  How to drive the shield PWMs onto something that I could see… I didnt pack my Tek in my carry on (though I suppose I could have used one of those little scopes).  But, I digress.  What I decided to do is make the PSoC echo an input onto on output pin that was connected to an LED.  So, I drew this schematic.  This can only be done in with a PSoC because I used a logic gate in the UDB to flip the 9685 PWM from Low to High so that my active low LED would work right.

screen-shot-2016-11-05-at-8-02-36-pm

Next I fly to Charles De Gaul, the suckiest airport in the first world.  What will I do on the airplane there?  I don’t, but given those empty beer glasses I may sleep.  More to follow when I get to Germany.

Electronica + WICED + The Robot Arm

The good news is that the Robot Arm arrived from Amazon, which I was very happy about because it was a day late.  The even better news is that it works like a charm.  First I needed to assemble it, which I did with a little bit of help from my able lab technician and a trip to Lowe’s to get a base.

img_0003

Then “we” attached the base to the Robot.

img_0008

After the robot arm was put together on the base, I needed a little bit of firmware to run it.  First the schematic:  You can see that I have

  1. Two PWMs – one for each Servo motor
  2. A Capsense slider to move one of the axis on the robot
  3. A switch and LED to turn On/Off the PWMs

screen-shot-2016-11-05-at-7-04-50-am

The robot arm has 4 “axis” which are each controlled by “servo” motors.  Servo motors have a small controller built into them that takes an input signal that is created by a PWM and turns the motor to the right place.  To drive the motor you need a input signal that is 50HZ, with a high pulse that ranges from ABOUT 1ms to 2ms.  When the pulse is 1ms the motor is all the way one direction, when the pulse is 2ms it is all the way the other direction.  To make the motor do what you want you give it a pulse somewhere in the middle, for instance if you want it to be half way then the pulse width is 1.5ms.

The easiest way to make this work is with a Pulse Width Modulator (PWM).  Conveniently enough, the PSoC4 BLE that I am using to build this project has 4 of them.  I set the input clock on the PWM to 12MHz, then I turned on the prescaler to divide by 4.  I then set the period to 60000.  Given all of that, the output frequency is 50hz.  which you can calculate by 12,000,000 / 4 / 60,000 = 50.  Given the period is 50HZ and there are 60000 clock ticks per period, each tick is 3us.  To make things easier on the rest of the system I want to give the input a range between 0% and 100% (as an Integer).  This lets me calculate the number of ticks I need to set the pulse width.  The formula is 3*(1000 + 10*percent).  I determined this empirically with an oscilloscope and changing the values to see the range of motion of the Robot Arm.

img_0012 img_0013

To achieve all of this, the PWM configuration is:

screen-shot-2016-11-04-at-7-49-33-pm

Now I configure the CapSense block to have a linear slider.

screen-shot-2016-11-04-at-7-52-55-pm

Finally I assign the pins:

screen-shot-2016-11-05-at-7-11-02-am

And a little bit of firmware:

Line 4 is a #define macro that calculate the correct compare value for the PWM.  After a little bit of experimenting with the Robot I figured out that it really wants the PWM to range between 800 microseconds and 1.8 milliseconds.

Line 5-7 initialize the original position of the PWM

Line 15-19 and 19-23 are helper functions which just turn on and off the PWMs.

Line 25-34 is an interrupt handler that is trigger when the user presses the switch.  It toggles a global state variable, turns on or off the PWMs and turns on/off the led.

In main I get things going on lines 38-43.  Then start an infinite loop that reads the capsense, and if the value is set then I set the value for the PWMs.  Remember that the capsense slider returns a value 0-100 so I can use it directly.

screen-shot-2016-11-05-at-7-03-25-am

After all of that my lab technician once again test it:

Electronica & WICED & PSoC

I am headed to Electronica in Munich tomorrow.  Cypress has a maker space in our booth where I will be teaching people how to use our products.  For some reason they always give me a microphone which seems crazy given that I am a bit wild.  The last show or two I have done demos using PSoC BLE.  This time I thought that I would also add WICED to the mix… so what is it going to be?

I saw this video on the Amazon AWS IOT website where their CTO introduces the AWS IOT platform by showing a demo of a robot arm.  The arm is connected to the AWS IoT Cloud (in some magic way) and is controlled by a Leap Motion controller connected to the cloud (also magic).  I hope that both of them were connected using WICED WiFi… but who knows since de didn’t show what was up his sleeves.

I thought that was really lame that he just magically brought the robot arm and controller from under the table and didn’t actually show you how to make it.  I am not really into doing things half ass and I don’t believe in magic, so what I am going to do is show people how to actually build that… live… Ginsu Knife Tiger Style

No magic, other than the magic of PSoC and WICED.  So, the day before yesterday I ordered what I think is the same robot arm… and now I need to write a little bit of firmware.  This is what I am going to build:

electronica-wiced

The only thing that I am a little bit worried about is getting to the Amazon Cloud from the LTE router in an high radio traffic environment of an electronics show… If that turns out to be a problem then Ill have to figure something else out… which will make life interesting.

Over the several days Ill post the firmware and pictures as I get it sorted out.

Alan

Cypress Academy — WICED WiFi 101

I have spent almost every waking hour for the last month writing a textbook for my new Cypress Academy class.  The textbook (as you might gather from the title of this post) is called Cypress Academy–WICED WiFi 101.  It has been an adventure learning the chips, modules, development kits and most importantly the WICED Software Development Kit well enough to teach other people.  During the next few weeks Ill write about this experience and talk about my experience.

Here is a picture of the textbook.  First, as you can tell by the cover, two amazing, bad-ass engineers worked with me on book.   James Dougherty, came from the Broadcomm IOT group and is a WiFI bad-ass.  And Greg Landry a 27-year Cypress engineer par excellence.

img_3294

While I was flying to California I was frantically trying to finish the class.  Here is a picture of me programming the Development Kit on the airplane.  I will say that you get some strange looks from everyone else.  You can see the WICED-SDK on my screen.

img_3283

Finally during the week I taught the first class:

img_3285

Over the next few weeks I’ll write about the chapters and basically release it into the public domain.  Here is the table of contents:

Chapter

Time

Purpose

00-Intro

30

An Introduction to the class (this document)
01-Survey

120

A tour of the WICED WiFi SDK, WiFi Standard, Chips, Modules, and Kits.
02-Peripherals

120

How creating a new project and how to use chip peripherals such as GPIOs, interrupts, UART, I2C, etc.
03-RTOS

120

How to use the Thread-X RTOS in a WICED chip.
04-Library

0

How to use WICED libraries for file systems and graphics LCDs.
05-WiFi

60

How to connect to and interact with WiFi access points.
06-Sockets-TLS

60

Establishing (secure) communication using TCP/IP Sockets
07a-Cloud

07b-MQTT-AWS

07c-HTTP

07d-AMQP

07e-COAP

240

An introduction to cloud Application Layer protocols

Building a WICED IoT device using MQTT on the Amazon AWS

Building a WICED IoT device using HTTP

Building a WICED IoT device using AMQP

Building a WICED IoT device using COAP

08-Project

240

Class project.
09-Shield

0

Details on the analog co-processor shield board.
10-Glossary

0

Glossary of terms.

 

WICED WiFI

Last week I had the supreme privilege of hosting the WICED WiFI + Bluetooth + Zigbee software team at my office in Kentucky. This included the overall manager for WICED software (a truly remarkable guy), the engineering managers for WiFI and Bluetooth, the head of applications for WICED as well as a bunch of the firmware guys.  It occurred to me during the week that the people joining Cypress was the best part of the Broadcomm IOT acquisition.  And that is saying something as I really like the products.  Also at the summit were all of the software engineering leaders for PSoC (who I have worked with closely all of my career).  Needless to say, it was a bunch of badass developers.

The purpose of the meeting was to introduce the PSoC team to WICED and then talk about the future roadmap for those products.  Obviously I can’t talk to much about the 2nd part… well actually the only thing I can say is that it will be amazing as we will be able to offer PSoC with the power of WICED.

What I can talk about is the first part.  So, I thought that I would show you one of the things that we did with WICED.  First of all, WICED (Wireless Internet Connectivity for Embedded Devices) is the brand name that Cypress uses to describe all of the WiFi, Zigbee and Bluetooth chips and modules that were acquired from Broadcom/Avago.  The other thing we call WICED is the WICED SDK which is used to mean Eclipse plus all of the tools (programer, plugins etc) plus the software library that is used to build products using the WICED chips and modules.

In the world of programming the first example is always “hello world”.  In the world of MCUs the first example is always “blinking led”.  It turns out that the first example in WiFi is “scan” to show that you can see all of the WiFi networks around you.   The purpose of all of these examples is to prove that all of the tools can do their thing.

To start with they gave me this devkit, the BCM94343WWCD1_1  IMG_3049

The first thing to do is install WICED 3.7.  When you start WICED you will see a screen like this:

Screen Shot 2016-08-22 at 8.22.06 AM

For the purposes of the first design there are two important things to see on this screen.  First on the left side is the project explorer.  It has all of the guts of WICED.  As part of the installation we provide you a bunch of “apps”.  These apps range from simple examples (in the snip folder) to full fledged production quality applications (in the demo folder)

  • demo – full fledged applications
  • snip – short example projects
  • test – tools for debugging and testing wifi
  • waf – WICED Application Framework support (like an OTA Bootloader)
  • wwd – low level driver examples

Screen Shot 2016-08-22 at 8.27.04 AM

The example that I want to build is “scan”  specifically “scan.c”.  That can be found in the apps/snip/scan folder.  In this screenshot you can see that I opened “scan.c”

Screen Shot 2016-08-22 at 8.43.49 AM

The next thing that you need to do is build a “make target”.  The WICED team built a makefile that can seemingly do everything.  The makefile uses the name of the make target to setup all of the options required to do the make.  If you look on the right side of the screen you can see the currently existing targets:

Screen Shot 2016-08-22 at 8.24.40 AM

The easiest way to make a new target is to copy/paste a currently existing target.  Then you can right click on the new target and edit it to get things setup correctly.  The target name defines:

  • snip – the directory
  • scan – the subdirectory will the files (scan.c and scan.mk)
  • BCM94343WWCD1 – the name of the devkit (you can see it on the picture of the devkit)
  • download run – instructions to go ahead a boatload and start the app running

Screen Shot 2016-08-22 at 11.32.06 AM

Next, I plug in the devkit.  When it attachs, the devkit will enumerate as two USB devices

  • WICED USB JTAG Port
  • A serial port (in this case on COM12)

Screen Shot 2016-08-22 at 11.29.45 AM

After I plug in the kit I run Putty and attach to COM12 at 115200 baud

Screen Shot 2016-08-22 at 11.36.32 AM

And finally, double click the make target to build, download and run.  After it starts, the Putty screen fills up with all of the WiFI networks that are around me.

Screen Shot 2016-08-22 at 11.30.39 AM

All of that was pretty easy to get going.  Next lets see if I can actually do something.  Last week I showed the guys the Elkhorn Creek Water Level monitoring project and I told them that by the end of this week I would put one of their devkits into that system, so the next several posts will be about that process. (I hope)