Embedded World 2017: PSoC Analog CoProcessor CapSense GUI

Summary

I have been building up pieces of code that are going to allow me to show the PSoC Analog CoProcessor –> WICED WiFi –> Amazon IoT –> WICED WiFi –> Secret New Chip –> Robot Arm.   In the previous two articles (part1, part2) I have shown you how to build most of the WICED firmware.  In this article I am going to focus on the PSoC Analog CoProcessor firmware (but if you look real close you can see the secret new chip’s development kit).

In the picture below you can see the red shield board.  This is a shield with the PSoC Analog CoProcessor plus a bunch of sensors that show the power of that chip.  The shield also includes 4x CapSense Buttons which I am going to use to set the position of the Robot Arm.  The PSoC will serve as a front end companion to the WICED WiFi Development Kit.  They will communicate via I2C with the PSoC acting as an I2C Slave and the WICED WiFi as a master.  Here is a picture of the all of parts minus Amazon.com’s cloud.

Embedded World 2017 Components

PSoC Analog CoProcessor

The PSoC Analog CoProcessor has the new Cypress CapSense block that gives you a bunch of new features, including enough measurement range to measure a capacitative humidity sensor (which you can see in the upper left hand part of the board).  For this demonstration I am just going to use the 4 CapSense buttons.  They will serve as the user interface for the Robot Arm.  The 4 buttons will set 4 different positions, 20%,40%,60%,80%.  I will be talking in much more detail about this shield in coming posts (later next month)

PSoC Analog CoProcessor Schematic

The PSoC Creator schematic is pretty straight forward.  I use the EZI2C slave to provide communication for the WICED board.  There are 4x LEDs that sit right next to the CapSense buttons,  and there are the 4x CapSense buttons.  The only slightly odd duck is the Bootloadable component which I use because when I designed the shield I did not put a programmer on it.  The BootLoadable allows me to me to load new firmware into the PSoC via the I2C interface.  Here is the PSoC Creator Schematic:

PSoC Creator Schematic

The CapSense configuration just specifies the use of 4x CapSense buttons that are automatically tuned by the Cypress magic.

CapSense Configuration

The last step in configuring the schematic is to assign all of the pins to the correct locations.

Pin Assignment

PSoC Analog CoProcessor Firmware

One of the great things about all of this process is how easy the firmware is to write.

  • Line 3 declares a buffer that will be used to relay the position information to the WICED board.  I start the position at 50%
  • Lines 8-9 start the EZI2C which starts up the EZI2C protocol and tells it to read from the “position” variable
  • Lines 10-11 gets the CapSense going

Inside of the infinite while(1) loop, I read from the CapSense and do the right thing

  • Lines 17-22 reads the CapSense status
  • Lines 24-27 set the correct position based on which buttons are pressed (notice that if no button is pressed then the position stays the same)
  • Line 29 turns on the Bootloader if B0 & B3 are pressed

PSoC Analog CoProcessor Main.c

Testing the PSoC Analog CoProcessor System

The easiest way to test the system is to use the Bridge Control Panel which comes as part of the PSoC Creator installation.  It lets me read the value from the EZ2IC buffer to make sure that the CapSense buttons are doing the right thing.  The command language is pretty simple.  You can see in the editor window that I typed “W42 0 R 42 X p;”  Everytime I press “enter” it sends the I2C commands:

  • Send an I2C start
  • write the 7-bit I2C address 0x42
  • write a 0
  • send a restart
  • read from address 0x42
  • read one byte
  • send a stop

You can see that I pressed each button and indeed got 20,40,60,80 (assuming you can convert hex to decimal… but trust me)

Bridge Control Panel

In the next article I will modify the WICED Publisher to poll the PSoC Analog CoProcessor and then publish the current state.

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.

FreeRTOS: A PSoC4 FreeRTOS Port

Summary

In my work life, I am working on some systems that will require more complicated firmware architectures built using real time operating systems.  As I need to get more familiar with RTOSs, I thought that I would go ahead and start using them in my PSoC 4 projects.  The logical one to start with is FreeRTOS.  In this article I will take you through the steps to create a PSoC4 FreeRTOS port.

  1. Introduce FreeRTOS
  2. Execute a PSoC4 FreeRTOS Port
  3. Create a PSoC4 FreeRTOS Test Project (the blinking LED)

FreeRTOS Background

FreeRTOS is a light weight, open-source, real time operating systems for embedded systems that was developed by RealTime Engineers.  Their basic business plan is to sell consulting and support services to semiconductor companies their customers.  All of the source code is available (mostly in plain C) and easy to use.  In addition there are ports to 35 MCUs (including all of the Cypress ARM chips).  FreeRTOS is frequently cited as the most popular embedded RTOS which is easy to understand as I have found it easy to use and very stable.

Execute a PSoC4 FreeRTOS Port

The port of FreeRTOS to PSoC4 is actually pretty trivial, once you figure it out.  But I suppose that is how things often go.  FreeRTOS comes preconfigured with a GCC version of an ARM Cortex-M0 port.  All that needs to be done is to hook the basic port to the correct PSoC4 systems.  There are generic porting instruction on the FreeRTOS site but these are my PSoC specific steps:

    1. Download FreeRTOS V9.0.0
    2. Add the include directories “FreeRTOS/Source/include” and “FreeRTOS/Source/portable/GCC/ARM_CM0” to your project by right clicking on the project and editing “Build Settings…”  You should add those directories to the “Additional Include Directories”Configuring the PSoC 4 FreeRTOS build settings
    3. Right click on the project and “Add Existing Item” so that you can add the .c & .h files from FreeRTOS/Source/portable/GCC/ARM_CM0  to your projectAdd the PSoC4 FreeRTOS Files to Project
    4. Add the .c files from FreeRTOS/Source/ to your project
    5. Add the .h files from FreeRTOS/Source/include to your project
    6. Add “heap_1.c” (or which ever memory manager you want) from FreeRTOS/Source/portable/MemMang
    7. Create the “setupFreeRTOS” function to install the Interrupt Service vectors required by FreeRTOS.
extern void xPortPendSVHandler(void);
extern void xPortSysTickHandler(void);
extern void vPortSVCHandler(void);
#define CORTEX_INTERRUPT_BASE          (16)
void setupFreeRTOS()
{
    /* Handler for Cortex Supervisor Call (SVC, formerly SWI) - address 11 */
    CyIntSetSysVector( CORTEX_INTERRUPT_BASE + SVCall_IRQn,
        (cyisraddress)vPortSVCHandler );
 
    /* Handler for Cortex PendSV Call - address 14 */
	CyIntSetSysVector( CORTEX_INTERRUPT_BASE + PendSV_IRQn,
        (cyisraddress)xPortPendSVHandler );    
 
    /* Handler for Cortex SYSTICK - address 15 */
	CyIntSetSysVector( CORTEX_INTERRUPT_BASE + SysTick_IRQn,
        (cyisraddress)xPortSysTickHandler );
}

8. Create the FreeRTOSConfig.h First, add a new file called FreeRTOSConfig.h file to the project (right click on the project and “add new item”.  This file contains a bunch of CPP macros to setup FreeRTOS.  You can get this file by copy/pasting from the the linked website into your blank FreeRTOSConfig.h file.
9. Modify FreeRTOSConfig.h I made the following changes to the default configuration file:

// Add the PSOC Creator Macros for the PSoC4 Registers 
#include "project.h"
// PSoC Creator creates a #define macro for the clock settings from the DWR
#define configCPU_CLOCK_HZ ( ( unsigned long ) CYDEV_BCLK__SYSCLK__HZ )
// SysTick Defaults to 1ms
#define configTICK_RATE_HZ                      1000
#define configSUPPORT_STATIC_ALLOCATION   0
#define configSUPPORT_DYNAMIC_ALLOCATION  1
#define configTOTAL_HEAP_SIZE               10240
#define configAPPLICATION_ALLOCATED_HEAP 0
// During an assert just put into a busy wait
#define configASSERT ( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }

Create a PSoC4 FreeRTOS Test Project

The example project is a simple blinked LED.  It starts with a “Task” function which I call LED_Task.  This just reads the current value of the RED Led pin, inverts it, and writes it back.  Then it does and RTOS delay of 500 ms.  The main look just turns on the interrupt system, initializes the RTOS, Creates the LED Task, then starts the scheduler.  The Scheduler will never return.

void LED_Task(void *arg)
{
    (void)arg;
 
        while(1) {
        RED_Write(~RED_Read());
        vTaskDelay(500);
        }
}
 
int main(void)
{
    CyGlobalIntEnable; /* Enable global interrupts. */
 
    setupFreeRTOS();
 
    /* Create LED task, which will control the intensity of the LEDs */
    xTaskCreate(
        LED_Task,       /* Task function */
        "LED Blink",    /* Task name (string) */
        200,            /* Task stack, allocated from heap */
        0,              /* No param passed to task function */
        1,              /* Low priority */
        0 );            /* Not using the task handle */
 
    vTaskStartScheduler();
}

ThingSoC: Four I2C OLED Displays with PSoC4L

Pattern Agents are running a crowd funding effort for ThingSoC TSoC4L … help them here

Summary

In the previous ThingSoC post I took you through building the firmware to make the PSoC4L drive the ThingSoC I2C hub.  Now what?  When originally looking around I saw a picture with 4x LCDs connected to the I2C hub, which I thought was cool. In this post Ill show you how to do the same thing with PSoC and the U8G2 library which I talked about in this article. To do this I will:

  1. Create New PSoC4L Project + Integrate the U8G2 Library
  2. Update the PSoC4L Firmware
  3. Test the PSoC4L Firmware

Here is the picture:

4 I2C Displays, Inspiration

Create New PSOC4L Project + Integrate the U8G2 Library

Maybe it should have been obvious, but for some reason it never occurred to me to do a copy/paste to duplicate a project.  I guess that I’m slow that way.  To do this right click on a project in the workspace explorer and then do paste.

PSoC Creator Edit Build Settings

The next step is to integrate the firmware from the U8G2 Library. Start by “gitting” with “git@github.com:olikraus/u8g2.git”.  Then you need to add the directory to your project by right clicking the project and selecting “Build Settings”.  You need to add U8G2 Library to the additional include directories.

Add the U8G2 Library

Add the all of the .h and .c files by right clicking the project and selection “Add->Existing Item”

copy the u8g2 files into the PSoC4L project

Navigate to the U8G2 library and add all of the .c and .h files.  The last thing you need is to bring in the HAL that I wrote for PSoC and described in this post.  Specifically you need to bring in the two functions

  • psoc_gpio_and_delay_cb
  • u8x8_byte_hw_i2c

I suppose that I should package the whole thing up in a component.  But, Ill leave that as an exercise for the reader.

Update the PSoC4L Firmware

The cool thing about the whole setup with the I2CHUB is that it allows you to have 4 devices with the same I2C address attached to one PSoC SCB at the same time.  To get going with the firmware, I start by defining an array of u8x8_t structures to represent the 4 different displays attaches to the 4 different ports on the I2C hub. (line 186).  Then I create a function called setupDisplay that initializes the display etc. (lines 199-203).  The only trick in the firmware is that Dennis Ritchie defined arrays to run from 0-3 but the I2C busses are labeled 1-4,  this is the reason for subtracting 1 from the input lcd number.

PSoC4L Firmware to initialize the U8G2 Display

The next step is modifying command processors in the main loop.  Specifically, I will add the commands q,w,e,r to startup the displays on I2C ports 1,2,3,4.  And, I will add those commands to the help print out.

Modifying the PSoC4L CLI

Test the PSoC4L Firmware

In order to make a connection from the Grove 4-pin connectors to my breadboard I used Switch Doc Labs connectors which I bought from Amazon.com.  For some reason you can’t purchase them from the Switch Doc Labs website or the SeeedStudio website, but they are very handy.  As an unrelated side note I had never seen (or in fact ever heard of) Switch Doc Labs.  But their website has a bunch of tutorials about the Raspberry Pi and Grove ecosystem boards for use with IoT-ifying house plants.  Seemed pretty cool.

Grove to Breadboard Switch Doc Labs Breakout Cable

Now when I press “qwer” in my command console I get this:

PSoC4L Driving 4 OLED LCDs

You can find all of the projects in the TSoC Series at my GitHub ThingSoC repository git@github.com:iotexpert/ThingSoC.git

Index Description
ThingSoc: TSoC PSoC4L Development Kit from PatternAgents Introduction to ThingSoC
ThingSoC PSoC4L: Using & Debugging the PSoC4 Clock Debugging a beta firmware problem
ThingSoC: The TSoC GROVEY I2CHUB : I2C Hub/Switch Evaluating the ThingSoC I2C Hub
ThingSoC: Multiple I2C Displays Using the I2CHUB and U8X8 Library A project using ThingSoC I2C Hub & 4 OLED Displays

Pinball: OLED Display

I screwed up the Pinball board design AGAIN!!!  It is so frustrating.  Ill write about the new design soon (and punish myself for the error.) As I worked on redoing the design I decided to put a footprint on the PCB for a small OLED LCD.   The display has an I2C interface, is about an inch wide and has 128×64 pixels… But, best of all can be purchased on eBay from China for about $3.00.  Here is a picture of the display with a PSoC4M driving it:

The display will go on the right side of the board.  Here is a rendering of the new board from the OSH Parks website:

After I decided to put the footprint on the board I bought several displays from Amazon to try out, and to make sure that I knew how to make them work.  I immediately ran into some drama which caused me an evening of frustration.  If you look at the picture closely you can see that the power and ground pins are swapped:

After I realized that was going to be a potential problem I put in a set of 0 ohm resistors on the upper right hand part of the board so that I could swap power/ground and scl/sda connections.  Here is a snapshot of the schematic and layout:

This left me with what software to use to drive the display which I will address in the next post.

 

Eagle PCB Layout Guidelines + OSH Park

Summary of Eagle PCB Layout Guidelines

I typically design my PCB’s in Eagle and have them manufactured at OSH Park.  Each new PCB layout feels like I am starting nearly from scratch because I only do about 1 or 2 boards per year.  Every time, as I go through the process, I promise myself that I am going to write down the list of things that I always need to relearn.  But, I never seem to get the list written down.  Today things change.  Here is my list:

  1. Make sure that you can actually purchase the components you put in your design
  2. No Airwires
  3. Vias tented (or not)
  4. Ideally no more than 2 vias on a net
  5. Power nets > 40mil
  6. Auto router setup
  7. Fill on the ground plane
  8. Ground fill around CapSense Widgets
  9. Test points on key nets – at very least power and ground
  10. Silkscreen font size
  11. Silkscreen labels on key nets
  12. Silkscreen key information onto the board
  13. Put in power supply jumper
  14. If there is I2C then put in a blank header to connect a mini-prog-3
  15. Extend the QFN footprints enough to be able to rework them
  16. Try not to route under QFNs
  17. Try not to use QFN with 0.5mm pitch
  18. Use the eye tool to compare every net in the schematic and layout
  19. DRC
  20. ERC
  21. CAM Job
  22. Don’t forget about the stencil

Make sure that you can actually purchase the components you put in your design

I used a footprint I found on the internet assuming that there was good availability for it.  But, I ended up having to order some weird USB connectors from a salvage shop in Poland.  I guess that I felt lucky to have been able to find them at all.  Unfortunately, I did the whole board and sent it to the shop before I was sure that I could buy everything.  Always always check to make sure you can purchase the device you place on the board.

No Airwires (seems like it would be obvious… but)

Airwires show the connectivity that is drawn in the schematic.  Unfortunately they don’t conduct electricity.  Until a REAL connection is made you will have a yellow flight line connecting between the pins in your layout.  Before you tapeout the board you MUST MUST press the Ratsnest button and get the message “Ratsnest: Nothing to do!”

Eagle PCB message when all connections are made i.e. no airwires exist

If you do this:

An example of an air wire that will make you Eagle PCB not be connected.

Then you will need this:

An example in Eagle PCB of what happens if you leave an airwire unconnected

Vias tented (or not)

A tented via or a plugged via is a connection between the top and bottom of the printed circuit board that is covered with solder mask.  In general there are probably enough vias on your board that if you don’t cover them you will not be able to see the silkscreen (either because it won’t print on copper or because the PCB vendor will trim it).  Here is a picture of one of the versions of Physics Lab where I forgot to tent the vias.  In the upper left where it says “Elkhorn Creek Engineering” you can see that the “l” in Elkhorn and the “g” in Engineering is partially missing where there is a via in the board.

An example of an Eagle PCB with untented vias.  This board was made at OSHPark

In Eagle PCB, Vias (and Pads) are automatically covered with the “tStop” mask.  Here is a screen shot of a PCB that I am working on with just the “Pads”, “Vias” and “tStop” layers shown.  You can see the “big” holes which are Pads for through-hole components.  You can see that they have the diagonal white lines through them that represents the “tStop” mask.  tStop is the mask that prevents the solder mask from being applied.  In the picture you can also see the tStop on places where there are SMD pads.  And, you can see a bunch of the smaller vias which are not covered.

An example of an Eagle PCB with via and stop mask turned on.

To tell Eagle PCB to turn off the tStop for vias you need to change the design rules on the “Tools->DRC->Masks” screen.  The limit parameter tells Eagle PCB to NOT create “tStop” for any via/pad that is less than 30mil in diameter.

Eagle PCB DRC rules screen where tented vias are specified.

No more than 2 vias on a net

I always strive to keep all of the nets on my two layer print circuit boards to have no more than 2 vias.   To look for this I click on the “eye” tool to probe each net of the layout, then I manually trace the net.  Here is a screen shot of a net that I try to avoid.  You can see that the net starts on the SMD pad in the lower right, then winds its way to the top left.  It goes through 4 vias.  Unfortunately it goes through one more via before reaching the SMD pad just below the upper left.

An example of proving a network using the Eagle PCB eye tool to look for more than 2 vias on a net.

Power nets > 40mil

I like the power and ground nets to be routed in at least 40mil wires.  To do this, you first need to create another net class in the “Edit–>Net classes” menu.  I always create a class called “power”.  Then I set the minimum width to 40mil.  If for some reason you want to have a minimum clearance or drill you can set this here as well.  If you leave it at 0,  Eagle PCB will use the default rules.

How to specify 40mil spacing on a power net in Eagle PCB.

After you have created the power net class, you then need to assign the correct nets to the net class.  You do this in the schematic by selecting the “I” tool, then clicking on the net.  Then you can select the “Net Class” for that net.  In this case I am editing the V50 net.

How to attach a signal to a specific net class in Eagle PCB.

Auto Router Setup

I am absolutely terrible at designing PCBs.  This frustrates me to no end.  One of the crutches that I like to use the the Eagle PCB Autorouter.  The only change that I currently make is to use the “*” option to let the router go whatever direction it thinks that it should.

Configuring the Eagle PCB Auto Router.

Fill on the ground plane

To create a ground plan you need to:

  • Draw a “polygon” around your board in the “top and bottom” layers.
  • Attach those polygons to the correct net e.g. “gnd” by typing the “name” command and then clicking on the ground polygon

When you press the “ratsnest” button Eagle will fill the ground plane.

An example of the ground plan pour in Eagle PCB.

If you want it to unpour it you can run “ripup @;”.  When the ground plane is not filled it will appear as a dotted line around the board:

Eagle PCB ground plane pour example

To attach the top and the bottom ground planes together you need to put a via on the correct net.  To do this:

  • Click on the “via”
  • Click where you want it to attach the top and bottom
  • Add to the the right net using the “name” command and then typing the signal name

How to attach a polygon to the ground plan in Eagle PCB.

Ground Fill Around CapSense Widgets

In order to get the best CapSense performance you want to have a “hatched” ground plane surrounding your widgets.  The methods for doing this are documented in the CapSense Design Guideline Section 6.4.9 “Ground Plane”.  Here is an idealized view of the back of the front and back of the board:

PSoC CapSense ground plane

PSoC CapSense ground plane example

The guidelines go on to recommend that you use 25% (7 width 45 spacing) coverage on the top and 17% (7 width 70 spacing) on the back.  To do this in Eagle PCB you draw a normal polygon on the top and bottom.  Then you use the name command to give it the “ground” name.  Then you click the “i” to set the parameters.

  • Set the width to 7 (mil)
  • Set the polygon pour to “hatch”
  • Set the Spacing to 52 (mil).  The only trick is that the Eagle PCB spacing isn’t actually the spacing between the lines but the Pitch between the hatched cells.  So to achieve 45 mil spacing with a 7mil line you need 45+7=52 “spacing”

Specifying the ground plane pour for a PSoC Capsense in Eagle PCB

Test points on key nets – at very least power and ground

It is a serious PITA to debug a board if there is no place to attach test leads.  I like to use a looped wire that you can install onto the board through a PAD.  Here is a red one that I use on power nets that I bought from digikey.com

PCB Probe Point

Silkscreen Font Size (don’t go less than 30mil@15%)

I believe that the best practice for your silkscreen fonts is to first tell Eagle PCB to use “Always vector font” on the “Options–>User Interface” menu.  This will make what you see on the board much closer to what you see on the screen.

Eagle PCB Vector Font

There are two issues with font size.

  • First, what can you see (Im 48… so my fine vision is going away) so I think 30mil is the absolute minimum.  40mil or 50mil is even better.
  • Second, what your PCB design house can print (about 5mil at OSH Park)

I am having my current PCB made at www.oshpark.com.  I could not find their silkscreen spec on their website… but an OSH Park Person “tweeted” that they can print 5mil silkscreen.

Given all of that.  Your best bet is to use a “vector font”.  When you select a vector font, you specify how tall the characters are, and how thick the lines are as a % of the height.  Here is a screenshot of my “SDAT” label.

Creating a silkscreen in Eagle PCB

I made this table of what I think is a safe range:

Eagle PCB Font Size Guidelines

On the the lukemiller.org blog I found a picture of an OSH park board with some different vector combinations:

Example PCB Font Sizes

On the justgeek.de blog I found another board:

Example PCB Font Sizes

Silkscreen on key nets

You should make sure and label every pin that you would need to interact with or debug.  For example, the board below has a place to plug in a miniprog-3 in 5-pin mode:  The connection is directional so labeling the pins is key: [Note: A friend of mine noticed that I labeled the MiniProg-3 connection INCORRECTLY!!!! notice that there are two V50 (when in reality the inboard one is supposed to be ground]

Example of an error in an Eagle PCB Silkscreen

Don’t forget about the back of the board.  If you don’t put labels on the back, you will endup trying to figure out what the holes are (like the ones in the lower right) by flipping the board back and forth.

Example of Eagle PCB Silkscreen

Silkscreen key information onto the board

You should definitely “comment” your board on the silkscreen with at very least:

  • Name of the board
  • Version number of the board
  • Name of the maker e.g. www.iotexpert.com

Key information on Eagle PCB Silkscreen

Put on Power Jumper

You should also put in a 2x100mil spaced jumpers with a 0 ohm resistor shorting them in the path of the power so that you can measure the power supply current.

If there is I2C then put in a blank header to connect a mini-prog-3

If you have an I2C bus in your design, and you have room on the board, you should provide a place to plug in the 5-pin mini-prog3 to help you debug.  This will let you interact with chips on the bus without having completed the firmware for the central MCU.

Cypress Miniprog-3

Extend the QFN footprints enough to be able to rework them

If you extend the edge of a QFN pad by 0.3mm past the edge of the chip, you will have some chance to be able to see that the original reflow worked (or didn’t).  In addition you will give yourself a small chance to be able to rework it with a soldering iron.  For example in the picture below you can see the pin one in from the left has no solder on it.  I was able to successfully rework this pin with a soldering iron.

Eagle PCB QFN Footprint

Try not to route under QFNs

If you have all solder mask under your QFNs it will be much easier to do the original reflow as it will push solder out from under the chip.  On tiny pitch QFNs if you have routing you may end up with a messy blob of solder.  Here is an example of what not to do.

Example Eagle PCB QFN Footprint

Try not to use QFN with 0.5mm pitch

Try to use 0.65mm pitch QFNs as they are much easier to reflow.  If you use 0.5mm pitch QFNs you are going to struggle to get them correct.  If you use a pitch less than 0.5mm then good luck to you.

Use the eye tool to compare the schematic and layout

I always open up the schematic and layout in side by side windows.  Then I click on each device in the schematic and look at the results in the layout.  In the picture below I clicked on “SWCOL2”.  This is called cross probing.  You should look at each net one by one to make sure that nothing funky happened.

Eagle PCB Eye Tool for net cross probing

DRC

The Design Rule Checker (DRC) in Eagle PCB works pretty well.  USE IT.  You can get a rules file from OSH Park (for their two layer process) from their website

You can also use the freedfm.com website to check your files.

Two things that you should be aware of when you run your final DRC.

  1. If you setup a special rule for the power net-clasesses that is greater than the minimum rule you may want to turn it back to the minimum when you run the final DRC.  For example, when I setup the ground layer as a power layer, I set the minimum rule to be 40.  Before I run the final DRC I set it back to 6.
  2. For any polygon that is setup as a pour, you will need to set the minimum width of that polygon to be the same as the minimum for the layer.  For example: the minimum top metal width at OSH park is 6mil.  This means you need to set the minimum width of the ground pour to be 6mil.  Here is a screenshot of the corner of the board:

Eagle PCB DRC

ERC

The Eagle Electrical Rule Checker (ERC) typically catches some problems.  By far my biggest problem with the schematics in Eagle is that I occasionally make two wires “connect” by touching, but Eagle doesn’t think that they are connected.  The ERC seems to catch this problem pretty well.  You should at least run it and go through the errors to make sure that they are false.

CAM Job

In order for OSH Park to make your PCB you need to make Gerber files.  Actually, OSH Park can do that for you, but I recommend you do it for yourself so that you are sure what is going to get made.  Gerber files are the lingua franca of the PCB business.  One file contains one layer for manufacturing, so you will need one file for each layer.

To do maker the Gerbers you need to run the “CAM Processor” which can be found on the tools menu.  I reccomend that you start with a preexisting CAM job (like the one that you can download from OSH Park)

The CAM job will have one “tab” for each layer that it creates.  In the picture below you can see that I am making the Top Silkscreen.  That layer is created by combining “tPlace” and “tNames” onto one layer and then writing it to the file “…/…/…/gerber/.GTO” in the GERBER_RS274X format.

Eagle PCB CAM Job Configuration

The file naming convention is:

File Extension Description
.GTO Top silkscreen
.GTL Top copper
.GBL Bottom copper
.GTP Top Paste (aka the solder paste layer.. you make the solder stencil from this layer)
.GBO Bottom silkscreen
.GTS Top Solder Mask
.GBS Bottom Solder Mask
.TXT Drill file – used for CNC mill that drills the holes in your board.. this is not a Gerber file

After you have the Gerber files you can look at them in gerbv which is an open source tool.

Gerbv Gerber Viewer

Stencils

Lastly, don’t forget your stencil.  I buy mine from www.oshstencils.com which is linked to www.oshpark.com, so you can just select your solder mask from the project that you already uploaded.

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 – CY8CKIT-145 User Interface

I finally made it to Munich late yesterday afternoon… then I proceeded to turn my hotel room into an electronics lab as I frantically worked to finish everything for tomorrow.  Earlier this year I wrote a whole series of posts about the PSoC4000S & CY8CKIT-145 after the Embedded World show.  We finally have volume production on the development kit and will be giving them out at the show this week.  So, I decided to use the -145 as part of the user interface for my Electronica project.  The devkit functions as the block labeled “PSoC Capsense”.  The wire between the “PSoC Capsense” and the “WICED WiFi” will be I2C (the green and red wire from the picture below)

electronica-wiced

The -145 devkit has the PSoC4000S silicon on it which has the new mutual capacitance capsense block.  On the devkit, there are three mutual cap buttons and one slider.  Here is a picture of the devkit connected to the WICED WiFi board that I am going to use:

img_3318

I want to make as simple of a PSoC Creator project as I can possibly do as I want to be able to easily do it live.  Here it is:

screen-shot-2016-11-07-at-10-12-23-am

The CapSense block is configured with three mutual cap buttons and 1 self-cap slider:

screen-shot-2016-11-07-at-10-13-54-am

On this development board, the three mutual cap buttons share the same transmit line, so you need to configure the component that way. The screen shot below shows the configuration of the “Button1_Tx” which is set to share the “Button0_Tx”.  You need to make the same setting for “Button2_Tx”.

screen-shot-2016-11-07-at-10-15-34-am

The next step is to assign all of the pins to the proper locations:

screen-shot-2016-11-07-at-10-18-10-am

Finally the smallest amount of firmware that I could think up to hold it all together.

Line 3-6: define a structure that the WICED board will be able to read.  It will represent the position of two of the Servo motors.  The CY_PACKED provides the compiler appropriate key words to make the bytes be right next to each other in the RAM, i.e. not word aligned..

Line 8: initializes both positions to 50%.

Lines 12-17 get the components going

Line 22: Checks to make sure that the CapSense block is not scanning before it reads the results

Line 24: Tells the CapSense block to process the results from the previous scan

Lines 25-31: Looks at the three buttons, sets the LEDs and sets pos1 to be either 25%, 50% or 75%

Line 33: Reads the position of the slider and assigns it to “pos0”

Lines 34-35: Gets the scanning going again

screen-shot-2016-11-07-at-10-21-02-am

To test the system I first used the bridge control panel.  First, connect to the kitprog2.  Then I setup a read from the I2C address (0x08) which is the address of my board.  I then click repeat which runs the read command over and over again.  In the picture below you can see that I tested the three position of the button (25,50 and 75 which are also known as 0x19, 0x32 and 0x4B).  Then I tested the slider by touching it about in the middle (0x3A)

screen-shot-2016-11-07-at-10-31-52-am

The next thing to do was make sure that the WICED devkit could read my I2C slave, so I wrote some WICED firmware to read the I2C registers every 500ms:

screen-shot-2016-11-07-at-10-55-08-am

But, occasionally I  was getting a “read failed”:

screen-shot-2016-11-07-at-10-58-48-am

Last night in my sleep deprived state I was struggling like crazy to figure it out.  This morning after some sleep I realized that the WICED board that I have must not like getting its I2C clock stretched.  So, I changed the priority of the I2C interrupt on the PSoC and that fixed the problem:

screen-shot-2016-11-07-at-10-28-03-am

Keep watching here for more updates on the project.

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.

 

Pinball: The PCB Version 1.0 – Fail

I got the boards back and assembled several of them… and they do not work.  It has been a really really frustrating few days trying to figure out what was going on.  I started with the assumption that I had a soldering problem so I soldered it and resoldered it about 10 times.   I used the soldering iron, I used hot-air, I reflow’ed the board, and I did 3 different complete board re-dos.  None worked.  I really wanted this to work before Maker Faire.

Finally I gave up and sent my board to our kit team in India.  This is not such a simple thing to do as you need to have commercial invoices for all of the stuff that I sent them… after getting it rolling and patiently waiting for three days for Fed-Ex to get it through all of the customs hoops etc. I get this email from the Kit Manager:

email

Damn damn damn… I know that I double checked the package.  That is such an amateur mistake… alway always always check your footprints.  But Ronak is right, here is a screen shot of the Eagle Layout which I clicked on Pin 2. (I rotate the image to make it line up with the data sheet)screen-shot-2016-09-24-at-8-16-22-am

And it matches the the picture from the data sheet for the module… However… notice that it says “Bottom View” which means I flipped it.

screen-shot-2016-09-24-at-8-14-43-am

Here is a screenshot of the package in the eagle library… sure enough. It is flipped.

screen-shot-2016-09-24-at-8-24-47-am

More evidence, here is the top view:

 

screen-shot-2016-09-24-at-8-13-47-am

So, I need to fix the package and then re-do the layout.  I start this process by making a new branch in git.

screen-shot-2016-09-24-at-8-41-00-am

Then open the library and the package:

screen-shot-2016-09-24-at-8-40-10-am

To make things easier I turn off all of the layers except for Top.  This allows me to easily click on each pad.  One thing that is a bit of a PITA is that you have to change of all of the pads to something else before you can change each one to what you want e.g. you can’t rename the pad currently named 1 to be 32 because there is already a 32.  So, what I do is rename each pad to the new name with an A on the end (see the image below).  Once that is done I go back around and remove the “A”s.

screen-shot-2016-09-24-at-8-51-18-am

Once my package is fixed, I update the library that I am using in my layout.

screen-shot-2016-09-24-at-8-59-55-am

Eagle immediately tells me that I have a problem… which is true, so true.

screen-shot-2016-09-24-at-9-00-20-am

Then I ripup all of the nets, which is so sad.  The problem is that all of the things I had on the left are now on the right and visa-versa so I need to think about the whole placement.

screen-shot-2016-09-24-at-8-57-45-am

Once I have ripped up all of the nets, I then cross probe all of the nets (In this case M1R which is also pin 31) to make sure that I have the connections in the right place.

screen-shot-2016-09-24-at-9-04-12-am

OK.  Looks good.  Not commit the changes and put them back to the github with a change request.

In the next post Ill talk about the new layout.

You can find all of the source code and files at the IOTEXPERT site on github.

Index Description
Pinball: Newton's Attic Pinball An introduction to the project and the goals
Pinball: Lotsa Blinking LEDs Everyone needs a bunch of LEDs on their Pinball Machine
Pinball: Matrix LEDs (Part 1) Saving PSoC pins by using a matrix scheme
Pinball: Matrix LEDs (Part 2) Solving some problems with the matrix
Pinball: Matrix LEDs Component How to turn the Matrix LED into a component
Pinball: A Switch Matrix Implementing a bunch of switches
Pinball: Switch Matrix Component (Part 1) The switch matrix component implementation
Pinball: Switch Matrix Component (Part 2) The firmware for matrix component
Pinball: Switch Matrix Component (Part 3) Test firmware for the matrix component
Pinball: The Music Player (Part 1) The schematic and symbol for a Music Player component
Pinball: The Music Player (Part 2) The Public API for the Music Player component
Pinball: The Music Player (Part 3) The firmware to make the sweet sweet music
Pinball: The Music Player (Part 4) The test program for the music player
Pinball: The Motors + HBridge Using an Bridge to control DC Motors
Pinball: The Eagle Schematic All of the circuits into an Eagle schematic
Pinball: The Printed Circuit Board 1.0 The first Eagle PCB layout of the printed circuit board
Pinball: The PCB Version 1.0 Fail Problems with the first version of the Eagle PCB layout
Pinball: PCB Layout 1.2 Updates using Eagle Fixing the errors on the first two versions of the Eagle PCB
Pinball: Assemble and Reflow the 1.2 PCB Assembling the Eagle PCB
Pinball: Testing the Eagle PCB Firmware to test the newly built Pinball printed circuit board
Pinball: Debugging the Motor Driver Fixing the motor driver PSoC project
Pinball: Hot-Air Reworking the Accelerometer Solder Using a Hot-Air Rework tool to reflow a QFN
Pinball: Debugging the LM317 Power Supply- A Tale of Getting Lucky Debugging the LM317/LM117 power supply

Pinball: The Printed Circuit Board Version 1.0

I am supposed to be good at this stuff.  What is this stuff?  Simple, everything engineering.  Unfortunately, I suck at PCB layout.  This is something that I am loath to admit because it is so frustrating. There it is.  But I need a PCB to make this work, so here we go again.  What also sucks is that I entitled this post “Pinball: The Printed Circuit Board Version 1.0” because I know that it is going to take multiple versions.  I don’t know what the exact cause is going to be this time.  But it will be something.  Enough whining.  Onto the task at hand.

When you start from an empty board Eagle gives you the tantalizing picture of a blank board with the components you need laid out neatly.  All you need to do is move them onto the tabla rosa.

Screen Shot 2016-08-29 at 5.21.40 AM

Initially there are several constraints that I am trying to satisfy.

  1. I want the board to cost <$5 so it needs to be <5 Sq. Inches
  2. The Pinball machine has space on the front for something roughly the shape of a deck of cards (2.5″ x 3.5″)
  3. The power connector needs to be at the bottom
  4. The user interface needs to be at the right (buzzers, capsense buttons) because Billy is going to cover the left side with some acrylic.

We had originally thought about making a 3-D printed box for the design, but decided that it would be cool to be able to see the board.  It also saves several dollars in cost to get rid of the box.

All right, I suppose that it is time to get to it.  First I move all of the component from “off the board” onto the board.  They all need to appear inside of the dimension layer.  If you look at the pinball machine I want all of the wire to come from the top and then go down into the machine.  So I place the holes for the LEDs and the Switches at the top of the board.  I want the user interface to be on the right side of the board (since most of the world is right handed… sorry about the left handed people).  So, I place the capsense buttons and the reset button on the right side of the board.  The BLE Module needs to have the space under the antenna without a ground plane and without signals, so I decide to put it at the bottom of the board.  I decide that the I2C port for the LCD will go on the left side of the board as that will make the connection to the LCD on the left side of the pinball machine easier.  Finally I put the accelerometer and all of the stuff that it takes to run it on left left side as well.

screen-shot-2016-09-25-at-10-07-51-am

Once the placement is all done, it is time to route the signals.  I do this through a combination of the autorouter and manual routes.  After I get all of the routes done, I place GND via(s) all over the board to connect the top and bottom ground pours.

screen-shot-2016-09-25-at-10-06-25-am

When I click the rats nest button the pours happen and I can see that there are no unrouted nets.

screen-shot-2016-09-25-at-10-05-40-am

Next I  do the top silkscreen

screen-shot-2016-09-25-at-10-10-09-am

Finally the bottom silkscreen

screen-shot-2016-09-25-at-10-11-31-am

The last step is to re-check all of my printed circuit board rules (the subject of the next post).  Now that I have a printed circuit board I can send to OSHPark to be made.

You can find all of the source code and files at the IOTEXPERT site on github.

Index Description
Pinball: Newton's Attic Pinball An introduction to the project and the goals
Pinball: Lotsa Blinking LEDs Everyone needs a bunch of LEDs on their Pinball Machine
Pinball: Matrix LEDs (Part 1) Saving PSoC pins by using a matrix scheme
Pinball: Matrix LEDs (Part 2) Solving some problems with the matrix
Pinball: Matrix LEDs Component How to turn the Matrix LED into a component
Pinball: A Switch Matrix Implementing a bunch of switches
Pinball: Switch Matrix Component (Part 1) The switch matrix component implementation
Pinball: Switch Matrix Component (Part 2) The firmware for matrix component
Pinball: Switch Matrix Component (Part 3) Test firmware for the matrix component
Pinball: The Music Player (Part 1) The schematic and symbol for a Music Player component
Pinball: The Music Player (Part 2) The Public API for the Music Player component
Pinball: The Music Player (Part 3) The firmware to make the sweet sweet music
Pinball: The Music Player (Part 4) The test program for the music player
Pinball: The Motors + HBridge Using an Bridge to control DC Motors
Pinball: The Eagle Schematic All of the circuits into an Eagle schematic
Pinball: The Printed Circuit Board 1.0 The first Eagle PCB layout of the printed circuit board
Pinball: The PCB Version 1.0 Fail Problems with the first version of the Eagle PCB layout
Pinball: PCB Layout 1.2 Updates using Eagle Fixing the errors on the first two versions of the Eagle PCB
Pinball: Assemble and Reflow the 1.2 PCB Assembling the Eagle PCB
Pinball: Testing the Eagle PCB Firmware to test the newly built Pinball printed circuit board
Pinball: Debugging the Motor Driver Fixing the motor driver PSoC project
Pinball: Hot-Air Reworking the Accelerometer Solder Using a Hot-Air Rework tool to reflow a QFN
Pinball: Debugging the LM317 Power Supply- A Tale of Getting Lucky Debugging the LM317/LM117 power supply

Pinball: The Eagle Schematic

In the last bunch of posts I have talked about the main systems of the pinball machine electronics package.  Now it is time to assemble all of those pieces into a complete system on an Eagle schematic which you can find in the “eagle” directory on the github site.

I use the multipage capability of Eagle to partition the schematic into 7 pages.

  1. Main Page
  2. LEDs
  3. Switches
  4. Accelerometer
  5. Power
  6. Motors
  7. Test Points

The main page contains the

  1. PSoCBLE module:  Notice that I used every single pin except for VRef.  Also notice that I overloaded SWD-Clock and SWD-IO pins by attaching capsense buttons to those pins.  This means that I will never be able to debug and use Capsense at the same time.
  2. USB Connector:  When I was trying to figure out how to make the board less expensive my son suggested that everybody has a USB charger, so why don’t you just power the pinball machine with that?  I thought that this was a great idea as it eliminates a $5+ wall wart.
  3. Two buzzers.  These are super simple low cost 12mm through hole buzzers which are used by the MusicPlayer component.
  4. Two capsense buttons multiplexed to the SWDCLK and SWDIO pins of the chip.  Notice that they have a 560Ohm series resistor
  5. The reset button for the system which just pulls down the XRES when you press the button.  It also has the 10K pullup resistor which pulls up XRES when the button is not being pressed
  6. Pull-up resistors for the 5V I2C bus.
  7. A 5-Pin programming plug for the MiniProg-3 connected to SWDIO and SWDCLK and the Power/Ground
  8. A plug for the I2C LCD to connect to the I2C Bus

screen-shot-2016-09-25-at-6-44-48-am

Page two of the schematic contains two connectors for the LEDs which I talked about in detail in the Matrix LED Posts .  It also contains the current limiting resistors.  In order to save money in the BOM I am not going to actually put connectors into the 100mil center holes, but will let the kids learn to solder by attaching the wires directly into the holes with solder.

screen-shot-2016-09-25-at-6-45-06-am

Page three of the schematic contains the switch matrix connectors and diodes.

screen-shot-2016-09-25-at-6-45-20-am

I thought that it would be a really cool idea to have an accelerometer on the board to provide a tilt functionality.  This actually turned out to be a serious PITA because I couldn’t find a cheap accelerometer that was 5v.  So, in addition to the accelerometer I have to provide a level translator for the I2C bus (PCA9306) and a level translator for the Accelerometer interrupt line (the mostfet and pull-up resistors).  I also have to provide a 3.3v power supply (next page of the schematic)

screen-shot-2016-09-25-at-6-45-36-am

The 3.3v accelerometer requires a 3.3v power supply, so on this page I use an REG317 to create 3.3v from the VBUS power supply.

screen-shot-2016-09-25-at-6-45-54-am

In order to drive the two brushed DC motors I use a TB6621 motor driver chip that contains two H-Bridges.

screen-shot-2016-09-25-at-6-46-04-am

Finally I like to have test points on the board to measure stuff while I am assembling the board.

screen-shot-2016-09-25-at-6-46-15-am

In the next post Ill talk about the creation of the layout for the printed circuit board.

You can find all of the source code and files at the IOTEXPERT site on github.

Index Description
Pinball: Newton's Attic Pinball An introduction to the project and the goals
Pinball: Lotsa Blinking LEDs Everyone needs a bunch of LEDs on their Pinball Machine
Pinball: Matrix LEDs (Part 1) Saving PSoC pins by using a matrix scheme
Pinball: Matrix LEDs (Part 2) Solving some problems with the matrix
Pinball: Matrix LEDs Component How to turn the Matrix LED into a component
Pinball: A Switch Matrix Implementing a bunch of switches
Pinball: Switch Matrix Component (Part 1) The switch matrix component implementation
Pinball: Switch Matrix Component (Part 2) The firmware for matrix component
Pinball: Switch Matrix Component (Part 3) Test firmware for the matrix component
Pinball: The Music Player (Part 1) The schematic and symbol for a Music Player component
Pinball: The Music Player (Part 2) The Public API for the Music Player component
Pinball: The Music Player (Part 3) The firmware to make the sweet sweet music
Pinball: The Music Player (Part 4) The test program for the music player
Pinball: The Motors + HBridge Using an Bridge to control DC Motors
Pinball: The Eagle Schematic All of the circuits into an Eagle schematic
Pinball: The Printed Circuit Board 1.0 The first Eagle PCB layout of the printed circuit board
Pinball: The PCB Version 1.0 Fail Problems with the first version of the Eagle PCB layout
Pinball: PCB Layout 1.2 Updates using Eagle Fixing the errors on the first two versions of the Eagle PCB
Pinball: Assemble and Reflow the 1.2 PCB Assembling the Eagle PCB
Pinball: Testing the Eagle PCB Firmware to test the newly built Pinball printed circuit board
Pinball: Debugging the Motor Driver Fixing the motor driver PSoC project
Pinball: Hot-Air Reworking the Accelerometer Solder Using a Hot-Air Rework tool to reflow a QFN
Pinball: Debugging the LM317 Power Supply- A Tale of Getting Lucky Debugging the LM317/LM117 power supply