I am back in Kentucky after an absolutely CRAZY week in Germany at Embedded World.  Looking back on the week I was extraordinarily proud of Cypress.  That was by far the best showing that we have ever had at a trade show.  And I really enjoy spreading the gospel of PSoC & WICED.  I thought that today I might post a few pictures from the week.

First, here is a picture of me delivering the benediction of PSoC & WICED at the end of my talk.

The day before setting up and testing the PSoC–>WICED–>Amazon–>WICED–>PSOC–>Robot ARM

Some video from my talk… thank you RS Components

One of the Cypress 3.0 Videos

The Germans have a deep and philisophical understanding of the proper use of Pork.  Here is the meat plate at Barfüßer in Nuremberg.

The show was awesome… and Im glad Im home for a few days.

Summary

In this article I will take you through the firmware that I will be using to control the Robot Arm Servo Motors.  The Business Unit Manager is being a total pain the neck about letting me tell too much about his new product before the announcement at Embedded World next week.  He is from Indiana, so that probably explains his dogged recalcitrance (just joking… Im from KY and there is a big rivalry).  Anyway.  You will be able to see some things about the new chip if you look closely what I am doing.  My design will have:

• An EZI2C to support communication with the WICED I2C Master
• Two PWMs to control two servo motors
• A connection to the onboard switch and LED to turn the servo PWMs on/off

Building the Servo Firmware

To make the design I first create a new project and the edit the schematic.  In this new chip there is clearly some logic gates as you can see that I control the PWMs with a Toggle Flip Flop.  Basically every time I press the switch it toggles the flip flop and then either starts or kills the PWMs.  This is very handy when you are trying to figure out what is going on with the PWMs and the servos.

As in earlier Cypress chips you double click the component to configure it.  Ill start with the PWMs and observe that we have another new GUI for configuring PWMs.  The servo motors want a pulse that is between 1 and 2 ms wide at a frequency of 50hz.  My PWM has a 12 Mhz clock input, which is then divided by 4 with the prescaler, and finally by 60000 by the PWM itself.  That equation yields a period o.052 kHz which (also known as 52hz) as PSoC Creator helpfully tell us.  By setting the compare to 3000 I will end up with a pulse of 1MS (about).

In order to configure the PWM to have the start/kill inputs, I select the Advanced tab and setup the PWM to start when the toggle flip flop goes low.  And I get it to kill (stop) when the toggle flip flop goes high.  I choose active low because the LED that is attached to the circuit to indicate the state to the user is active low.

Next I configure the EZI2C by double clicking it.  It looks like there is a new interface for EZI2C as well… but under inspection there is nothing too tricky.

Once I have the schematic built, I need to assign the Pins which is done using the DWR Pins Menu (as you did with earlier Cypress chips)

Hmmm it looks like the new chip comes in a BGA, and seems to have a bunch of pins.  For the purposes of this demo, I assign the two motor pins too two of the pins on the Arduino Adafruit Servo Shield that I am using to make the connectivity easier.  This was a neat way for me to be able to plug in servo motors and provide them with power from something other than the chip, but still drive them with the chip.  Here is a picture of my shield.

Build the Firmware

The firmware is very simple.

• Declare a structure to hold the data from the I2C master (lines 8-11)
• Start & Configure the EZI2C (lines 21-23)
• Start & the PWMs (lines 24-28)
• In the main loop, when there is a complete write from the I2C Master, Update the PWM compare values
• The function convertPercentToCompare calculates the compare value required based on a number 0-100 (aka percent)

Testing the Firmware

To test the firmware I use the Bridge Control Panel to issue I2C Commands (as I did in the earlier post).  You can see that I did a list devices.  Then sent several different percents (they are in hex).

Here screenshot from my oscilloscope where you can see that I entered 0x32 (aka 50%) so the width of the pulse is 1.5ms @ 50Hz.

And it seems to work pretty well at controlling my Servo Motor Robot ARM.  Nicholas looks a little bit crazy, probably the result of too much Solder smoke?

In the next article I will make the final connection to the WICED WiFi kit which will give me end to end connectivity through the Amazon IoT Cloud.

Alan

p.s. I love this new chip, you guys are going to be blown away.

Summary

In a previous post I showed you how to build a CapSense GUI using the PSoC Analog CoProcessor.  And, in an earlier, post I showed you how to make a WICED WiFi MQTT Publisher App that can send data to the Amazon IoT Cloud.  Now I need to put it all together so that I can I2C read from the CapSense GUI and then publish that data to the Amazon Cloud.  In order to do that I will need to make a few modifications to the Publisher App:

• Delay 100 ms (meaning the WICED WiFi board is I2C polling)
• Read the I2C Register 0 on the PSoC Analog CoProcessor Board
• If the position has changed, then Publish the new position to the Amazon MQTT Message Broker

Here is a picture of the two boards connected together.  If you have a sharp eye you probably noticed that the LED next to B0 is on.  I changed the PSoC Analog CoProcessor firmware to retain the state of the last button press.

Modify the WICED WiFi MQTT Publisher Firmware

If you remember, the Publisher App was built to turn a light on and off when the user pressed the button on the board.  To do this, WICED MQTT Published an ASCII message of either “LIGHT ON” or “LIGHT OFF” that was stored in a char pointer called “msg”.  The original firmware also used the user button to trigger the publishing by setting a semaphore.  I want the board to poll every 100ms the current state of the button, then if it is changed from the last time, publish a message with the new position.  There are several things that need to happen to make this work

1. Setup the I2C device: (lines 297 –> 307)
2. Start the infinite loop (line 309)
3. Delay 100 ms (line 312)
4. Check to make sure that we are not in the middle of publishing.  The publishing is an asynchronous transaction. (line 314)
5. Read the I2C register of the PSoC (line 316)
6. If the position has changed, then setup the message and activate a publish (line 317-322)

Test the WICED and PSoC Firmware

To test the whole setup I program the board, then attach to the Amazon Cloud MQTT Test Client.  Then I use it to subscribe to the “ROBOT_POSITION” topic.  You can see in the picture below the transactions that I tested:

• The WICED Development Kit booted
• WICED I2C read initial position = 20 (0x14)
• I pressed B2 and it read position =40 (ox28)
• I pressed B2 and it read position =80 (ox50)
• I pressed B2 and it read position =60 (ox3C)

In the next article I will modify the Subscriber application to take the published position and write it via I2C to the new super secret development kit that is controlling the Robot ARM.

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 this article I will start this process of repairing the my brain damage by taking you through the steps I am following to create an MQTT connection to Amazons cloud using WICED WiFi.  I will post 3 articles on this topic:

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)

Amazon IoT & MQTT

The Amazon IoT Cloud can do an amazing, frightening, crazy overwhelming amount of different things.  Here is a picture of their architecture.

Above, you can see that Amazon has decided to follow on the language of IoT by actually calling the devices that attach to their cloud “Thing”.  This makes for some rather awkward English sentences, but I suppose they are not going to change it, so I will go with their language.  For the purposes of this demonstration I am going to create two “things”.  One will be “Publisher” and one will be the “Subscriber”.  The “Things” will attach and communicate to each other via the Message Broker in the Amazon Cloud.  The connection will be built in the WICED SDK using MQTT and run on the Cypress CYW943907AEVAL1F development kit.

MQTT stands for Message Queuing Telemetry Transport, which, in simplest terms is a lightweight TCP/IP based protocol that can run over secure sockets.  The good news is the Cypress WICED SDK has MQTT built in and provides a clean interface for you to develop firmware to create and use MQTT connections.  MQTT is pretty simple and has only four important concepts.

• Message Broker – A server that supports MQTT connections and hosts Topics
• Topic – The name for a queue of Messages (the Topic name can essentially be anything that you want in your system)
• Message – A string of bytes in any format you desire for your system
• Publisher – A device that sends a Message to a specific Topic on a specific MQTT Message Broker
• Subscriber – A device that has asked to receive Messages sent to a specific Topic

For the purposes of this demonstration I will create a Publisher (running on the 943907AEVAL1F board) that will publish a message with the desired position of the servo motors on the robot ARM to a Topic (named ROBOT_POSITION) on the Amazon Message Broker.  The Subscriber (running on a different 943907AEVAL) will subscribe to the Topic and will then send an I2C command to the PSoC controlling the Robot ARM.  For example if the 4 CapSense buttons B0-B3 represent 10%, 30%, 50%, 70%, 90% then when the users presses B0, WICED will publish a message of “10” to the Topic “ROBOT_POSITION”.  Then, that message will go to the Subscriber, who will send that message to the PSoC Servo Motor controller.

In order to make the connection to the Amazon IoT Cloud you need to use Transport Layer Security which is also built into the WICED SDK.  Good security is one of the best reasons to use Cypress WICED as we are taking that very seriously.

The AWS IoT Cloud supports a bunch of other functionality including:

• Connections to the Dynamo DB
• Simple Notifications (Text message, Email)
• Running Lambda Functions
• Plus a bunch more

However, all of that is outside of the scope of what I have time to show live.

WICED WiFI: Modify & Test the Publisher App

To build the application, I will copy and modify, then test the Publisher Demo App.  In order to simplify things I will use the pre-exising App that already has all of the MQTT stuff in it.   Cypress provide a bunch of example applications which all reside in the “apps” folder of the Project Explorer.  So, I will start by creating a directory called “emb2017”.  Then I will copy/paste the apps–>demo–>aws_ios–>pub_sub–>* into my emb2017 directory.

The next step is to modify publisher.mk file:

• Make the “Name” unique.  Each application name must have its own unique name or your firmware will not build correctly.  In this case I name it  “App_emb2017_Publisher”
• Add BCM943907AEVAL1_WW101 to the valid platforms list.  A platform is the WICED name for the Board Support Package.  In this case we create a BSP for the PSoC Analog AFE Shield.

After the Makefile is fixed up, I will need to modify the Device Configuration Table (aka wifi_config_dct.h) so that it knows about the network at my house.  The DCT is an area of flash that is used to hold security credentials, network SSIDs etc.  This place can be configured either statically at build time or programmatically at run time.  In this case, I will just set the SSID/Password at build time.   For this example I will use the WW101WPA” network which is a pre-shared key WPA2 network with a password of “kywpa123” (Yes, if you come to my house in KY you will be able to attach with that password.  If you do, please knock on the door and we can have some Bourbon together).

In order to make a TLS connection you will need to have three files:

• rootca.cer – Amazon’s Root Certificate
• privkey.cer – A private key (paired with a public key) that will allow you to establish a secure connection
• client.cer – A certificate that identifies your AWS “Thing”

All of these files come from the Amazon IoT website and need to be copied into the “…/resources/apps/aws_iot” directory.  They will be compiled along with your application and placed into the DCT of your WICED device by the Makefile.  This happens as a result of this section of the Makefile:

The next step in the process is to modify the publisher.c program.  When you setup an Amazon IoT account, it will create a virtual machine with the Message Broker running on it.  That VM will be given a unique name which you will need to hard code into your application.  In addition you need to change the topic and message sent.  Here are the changes that I made to publisher.c:

Now that all of the Firmware is setup, I need to program the board.  To do that I create a new “Make Target” in the WICED Make Target window. The make target tells the makefile system:

• Which app to build, in this case “emb2017/publisher”
• Which platform to use.  Platform == Board Support Package.  In this case “bcm943907EVAL1F”
• Lastly what to do, in this case build, download and run

The last thing to do is program the board and then test using the Amazon IoT MQTT WebClient.  This client can subscribe and publish to your Message Broker.  Our application is configured to Publish to the “ROBOT_POSITION” topic.  So, I will subscribe to that Topic, which will cause all messages that are published to that topic to be displayed.  This happens when I push the Mechanical Button 0  the PSoC AFE Shield

In the screen shot below you can see the console of my 943907AEVAL1F board as well as the MQTT Test Console.  The board starts by turning on WICED, starting the RTOS, turning up the TCP/IP stack, then attaching to the network etc.  After all of that is done it starts an MQTT connection to the Amazon IoT MQTT broker.

On the AWS MQTT client, you can see that I pressed the button three times which published three messages.

In the next Article I will take you through the creation of the Subscriber side of this application.

Embedded World 2017: Summary

I will be at Embedded World 2017 in Nuremberg, Germany next week.  For some crazy reason the powers that be at Cypress seem to think that it is a good idea to hand me a microphone.  For the last several trade shows I have done live demonstrations of Cypress chips, which seem to get a pretty good crowd.  Here is a video of me talking at Electronica 2016:

https://www.youtube.com/watch?v=bXCnE4wLl_Q

Here I am two years ago at Embedded World 2015.  Unfortunately there were more people there watching me talk than have viewed this video!

Over the next couple of days I will post the pictures, schematics and source code for the projects that I will be showing.  If you are there you should definitely come see me as I give a good Ginsu Knife show… and I will be giving away development kits.  Best of all there is a new chip coming that I am going to get to show off … a very remarkable IoT offering that will put us in the lead (and if you are reading this you will get some early insight into).

At Electronica last fall I showed I showed Cypress PSoCs doing CapSense and Servo Motor Control over a WICED WiFi link.  You can read about that stuff here.  It was a really good demonstration, and everyone thought that was fun, but I always regretted that I didn’t send the data to the cloud.  Here is a picture of the architecture  that I was planning to build for that show, but I cut out the trip to Amazon AWS and replaced it with a TCP/IP Server running on the WICED chips:

This time I am going to go all the way.  In addition there will be a Development Kit for a new product that we are announcing at the show.

The bottom line… for this live demonstration of Cypress awesomeness I am going to use

1. The CYW943907AEVAL1F WiFi board as connectivity to the Amazon Cloud.
2. The Top Secret new development kit with a really fun new chip that we have all been waiting for  (notice the Type-C connector, Mutal Cap Capsense Sensors, that might be an antenna at the top and for sure there is something cool under that post-it-note)
3. The Cypress Analog CoProcessor AFE Shield Board… which I will be talking more about in future posts, but is built with the PSoC Analog CoProcessor
4. The CY8CKIT-145: As a CapSense User Interface 

Over the next 3 days Ill post the intermediate steps of building the project.  I am flying to Embedded World 2017 on Sunday so I am going to need to get rolling.