CY8CKIT-021: The BLEIOT Component

The PRoC (on the shield) and the baseboard share two pairs of lines that are connected to the Serial Communication Blocks (SCBs) on the chips.  One of the pairs is also connected to the standard I2C Arduino bridge pins and in fact this is how you bootloaded the PRoC in the previous example.  When I started thinking about the problem of making the PRoC on the shield talk to the baseboard I knew that I wanted either side to be able to initiate communication and I did not want either side to poll.  This fact eliminated the master/slave scheme of I2C or SPI.  OK.  UART it is.

The next thing that I knew that I wanted was one set of firmware that would work exactly the same on both side.  This lead me to build a component called BLEIOT.  This component has the following features

  1. It transmits its local status every 20 ms
  2. It is triggered by the Systick
  3. It uses UART to transmit and receive
  4. It has a “Update” API which will update the local and remote state
  5. It has dirtyFlags which are a bit mask of what was written from the other side and is different than the current local status
  6. The component works the same on both sides
  7. It has a data structure that represents all of the peripherals on the shield (LEDs, Thermistor, CapSense Buttons etc)

The system works by having a “local” copy of the state and a last known “remote” copy of the state.  There is a C-Structure that represents each of the system variables (LED, CapSense, …).  The way it works is:

  1. When something changes in your system you use the “Update” API.
  2. The update API changes the local state and the “Write Flags” which is just a bit mask of all of the local variables
  3. Every 20ms the component sends the local table to the remote side (assuming something has been written)
  4. The remote side then looks at each variable that has been “written” and compares it against the local copy.  If they are different then it marks the “dirtyFlags” with the corresponding bitmask
  5. On either side you can monitor the “dirtyFlags”.  If the dirtyFlag for a variable is set then you know that the other  side changed it and you can do something.
  6. When you run the “Update” API if you write your local copy to be the same as the remote copy then you will clear the dirtyFlag.

This project is available as BLEInterface in the CY8CKIT-021 workspace that is in the firmware directory on github at

Here is a picture of the architecture:


An example:

  1. Everything starts in sync
  2. The PSoC turns on an LED with Pin_Write()
  3. The PSoC calls the BLEIOT_updateLed API
  4. That BLEIOT_updateLed API updates the local state table
  5. That BLEIOT_updateLed API marks the “writeFlag” corresponding to the LED
  6. The PSoC systick triggers the BLEIOT component to send the local table to the PRoC via UART
  7. The PRoC UART receives the table and calls the BLEIOT_receive API
  8. The PRoC BLEIOT component looks at the “Write Flags” and notices that the LED was written, so it marks the dirtyFlag corresponding to the LED
  9. The PRoC  main loop notices the dirtyFlag and turns on the LED using Pin_Write
  10. The PRoC then runs the BLEIOT_updateLed function which updates the local state and clears the dirtyFlag
  11. The PRoC systick calls the BLEIOT_send which sends the local state table to the PSoC
  12. The PSoC calls the BLEIOT_receive
  13. The PSoC BLEIOT_receive notices that the LED was written but that its remote state now matches its local state so it doesn’t do anything

Building the Component

In order to make a component this component I need

  1. A symbol for the component
  2. A schematic (with the UART)
  3. The BLEIOT.h (which is the public interface to the component)
  4. The BLEIOT.c (which hold the functions that makeup the component)

To make the component I start by adding a “library project” to my workspace called BleInterface.  You do this from the new project dialog.

Then I click on the components tab of the BleInterface project.  This is a bit of a trick as it seems like the library is “empty” but it isn’t.

Screen Shot 2016-05-27 at 1.49.08 PM

The next step is to create a symbol by right clicking the library and saying “add component item” and choosing Symbol Wizard.  If you are doing this make sure that you give the component a good name (or at least something better than “component01”

Screen Shot 2016-05-27 at 1.54.36 PM

This component does not have any visible terminals so just accept the defaults.

In the next step I create a schematic to hold the UART component.  When you add the component item for the schematic you need to configure the architecture to target the PSoC4 family in order to have access to place the SCB UART.  After you have placed the UART component you will automatically get “buried” pins which you can assign for that component.

Now that I have a schematic and a symbol, the last steps are to add the .h and .c

The .h contains the public interface to the component.

Screen Shot 2016-05-27 at 2.46.10 PM

This section defines the public interface.  On update function per system state.

Screen Shot 2016-05-27 at 3.36.00 PM

The bit masks for the dirtyFlags and updatedFlags

Screen Shot 2016-05-27 at 2.46.48 PM

The definition of the table of variables.

Screen Shot 2016-05-27 at 2.47.15 PM

The last thing that you need is “BLEIOT.c”

Screen Shot 2016-05-28 at 8.31.24 AM

The update function is a generic function that will “update” the local table with the current value of one of the local status (LED0, CapSense …).  This function is called by the various helper function (updateLed0, updateBootload, updateCapsense,…)

Screen Shot 2016-05-28 at 8.32.08 AM

Screen Shot 2016-05-28 at 8.37.10 AM

Screen Shot 2016-05-28 at 8.37.35 AM

This function sends the data to the other side when it gets a turn from the systick interrupt

Screen Shot 2016-05-28 at 8.37.50 AM

In the next post Ill show you an example project of the BLEIOT.

index description