Month: February 2017

IoT Expert in Shenzhen: Seeed Studio

Seeed Studio

On Wednesday before the flight to Shanghai we decided to see if we could find Seeed Studio. They are a Chinese Maker company ala Adafruit. I started by “googling” Seeedstudio to try to figure out where they were… but in China there is no Google. So I bing-ed … then on their website found the location. I took a picture of my screen to show to the taxi driver.

After a 30ish minute taxi ride, we were dropped off in front of a security gate. I “talked” to the security guard (who spoke as much English as I speak Chinese). After a few minutes of wild gesturing, he signaled us to follow him… to the entrance of SeeedStudio.

There was someone standing out front who spoke English. He led us into the office. They were at lunch, but asked us to sit and wait, which we did. After a while they brought out the International Product Manager. I introduced myself as a Cypress person. We talked for a while about ideas for cooperation between our companies. Then they took us on a tour. Here are a few pictures. First, the workshop:

For some reason they didnt label their boxes 🙂

Then out in the engineering area:

Finally goodbye:

IoT Expert in Shenzhen: Huaqiangbei Electronics Market

Summary

This week I am in Shenzhen, China teaching Cypress and Distribution Engineers how to program WICED WiFi. I thought that while I was here I should go see the crazy electronics and maker scene. So, my friend Greg and I headed off to Huaqiangbei Electronics Market (华强北), then SeeedStudio (the subject of the next post)

Huaqiangbei Electronics Market

Last week I wrote an article about using hot-air rework tools to fix screwed up PCBs. As I walked around, I wasn’t really sure what to expect, but I surely didn’t expect to find tons of little shops with hot-air-tools fixing cellphones (and other unknown things). In fact over the next several hours I ran into bunches of hot-air-tools… and bunches people who Im quite sure knew how to use them.

After wandering around a bit, we found the Huaqiangbei Electronics Market. This place is a giant 8-9-10 floor electronics bazar where as best I could tell you could buy almost any electronic component you could possibly desire. It was full of little booths selling everything you could imagine, from cellphones to PCs to reels of 0603 resistors.

One of the first floors of the place was little (like 15×15 feet) shops selling LEDs.

Here is some dude bagging up and heat shrinking bunches of through-hole LEDs.

And another booth selling LEDs

Everywhere you looked there where booths over flowing with components. Here is a booth with some Rupees.. and transistors.

I dont know how you would find ANYTHING with booth after booth overflowing with reels and reels of of surface mount parts. I suppose that it would help to know what the Chinese characters on the top of the case said.

Hey! Where the hell is the Cypress logo?

More craziness.

Here is a place selling industrial cameras.

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.

Introduce FreeRTOS
Execute a PSoC4 FreeRTOS Port
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:

Download FreeRTOS V9.0.0
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”
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 project
Add the .c files from FreeRTOS/Source/ to your project
Add the .h files from FreeRTOS/Source/include to your project
Add “heap_1.c” (or which ever memory manager you want) from FreeRTOS/Source/portable/MemMang
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();
}

A New Logo Design Contest for IoT Expert (Part 2)

You might have noticed that today the IoT Expert website looks completely new. And, you would be right. The whole thing has been re-done. Why? There are a lot of reasons, but the bottom line is that I changed my mind. When Yakob Dedi posted his original design to the 99designs contest I immediately thought, “Wow, that is the winner!” Then when I sent the design around, one of my good friends said that it was obviously the winner and I should stop wasting time with the others. But, for several reasons, I ended up going with the other design.

But, I regretted the decision. And every day that went by, it ate at me. One of the marketing people that I work with originally said the Yakob “IoT Expert” logo was the only choice from the contest that was iconic. This comment kept ringing in my brain. Finally I contacted Yakob (aka AnnSir on 99designs) , bought the logo and started the process of switching. And now, I am much much happier for it.

It turns out that the switch was not that easy because the WordPress template that I was using was not very compatible with the redesigned logo. Then, we descended into the pits of hell trying to find a good template starting point. Yakob looked at 100’s of different designs. He selected about a dozen that we went through the merits and problems of. Finally, we picked a template that seemed to provide all of the features we needed. The WordPress world has a frightening amount of open-source, freemium and paid developers and it is a pain to sort the wheat from the chaff. It is absolutely huckster-central.

As we worked through the new design, Yakob suggested that I move to icons for the menus. When I saw his designs I was convinced.

I hope you like the redesign. Send me email, tweet me or make a comment.

Pinball: Debugging the LM317 Power Supply- A Tale of Getting Lucky

Summary

My father always says he would rather be lucky than good. I always assume that had something to do with his age. I never liked that sentiment. Actually “not like” doesn’t even begin to cover my dislike of that idea. I guess that I am always distrustful of luck. But todays post is a story of good luck. In my post about testing the PCB I showed a picture of my Fluke Meter showing 4.153V DC. That is cool, expect the power supply in my system is supposed to be regulating the power to 3.3v. I didn’t sweat the number at the time, but that is a long way from 3.3v. In fact it is enough to put 3.3V chips-like my accelertomer-at risk of blowing up. So now what?

LM317 Power LDO Power Supply

Well, on my board I used an LM317 Low Drop Out adjustable regulator. When I went to setup things up I googled and found this schematic and table of values. So that is what I put in my design.

I knew that the regulator is adjustable and the feedback resistor network sets the voltage of the output. When I had the wrong voltage I assumed that I had the wrong size resistors. So I unsoldered the damn resistors and measured them. They were dead on, so I put them back on the board. This left me really wondering, so I went and looked at the datasheet for the LM317. This is what it says:

There are a bunch of LM317 calculators on the web. When I looked at them I realized that something might be really bad. Specifically the resistors from the table (R1=1.2k, R2=1.8k) were probably too large. That means that there was probably no enough current going back into regulator. So, this could be the source of my problem. As I was soldering and unsoldering I realized something really BAD. I did not put a LM317 on the board. I put a LM117 on the board. Holy shit batman! Why does that work at ALL?

The basic answer is that the LM117 that I used was a 3.3V regulator and had the feedback resistors built in. Meaning, it wasn’t adjustable at all. I got totally totally luck as the pinout was exactly the same as the LM317 and ALL I had to do was connect the ADJ resistor to ground instead of the stack. Moreover, the “tab” was not connected to anything so the output voltage wasn’t shorted to ground either.

As I read the datasheet I learned something else. My layout is a long long way from optimal. Here is a picture from the datasheet.

And here is my layout.

LM317 Layout

Oh well. I got lucky. Totally. I don’t like it. But there it is. When I tapeout the board again Ill fix the regulator 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: Hot Air Solder Reworking the Accelerometer

Summary

If you have to use a hot air solder tool, you are probably having a bad day. But when you need a hot air solder rework tool, you are very, very glad to have one. I am sure that there are people who can get a QFN off a printed circuit board without one, but I am not one of them. It is even more fun to put a QFN back on a board without one. But, once again, I am not one of those people.

Hot Air Solder

I have a Metcal HCT-900-11 Hand Held Convection Rework tool aka Hot Air Solder tool. This machine can blow out hot air … really, really hot air, up to about 950 degrees Fahrenheit. I’m pretty sure you could cut your arm off with it. The tool has a bunch of nozzles of different shapes and sizes. Using one of these things is an art form because you need to get the temperature right, the airflow right, the distance from the board right or you will find yourself blowing components off the board and making things worse.

Pinball machine PCB Solder Problem

In the post where I discussed the first test of the Pinball board I told you that the power supply was not working. It turns out that the cause of the problem was a big blob of solder under the accelerometer. To fix that problem I had to remove the tiny little 3x3mm QFN accelerometer using the hot air solder tool. Once I did, there was a big mess of solder under the package which I cleaned up with a braided copper wick and a soldering iron. I suspect that I put too much solder onto the pads with the metal stencil when I built the board.

Here is what the board looked like after I cleaned it up:

Pinball PCB Solder Problem

And here is a picture of the damn tiny chip. The problem with all of these chips is they are meant to be used in cell phones, so they are as small and thin as possible. And to make matters worse, the pads are on 0.5mm pitch or smaller.

Hot Air Solder Rework

When I first started fighting with these QFN problems, I talked to the guys in the Cypress Development Kit team in India. The manager of the group recorded this video of Jesudasan Moses, who is a wizard with hot air solder tools and a soldering irons. This video was a huge help and I am grateful to them for recording it.

To fix my problem I followed the same process. Here is the video:

After three attempts, I got the chip mostly on. As you can see in the picture below, I was missing a connection to one of the pins. The other problem was that I melted the screen with the hot air. Suck.

Hot Air Solder rework of 5mm QFN

After I touched up that pin with a soldering iron I still couldn’t talk to it with the PSoC, and I didn’t have easy access to the I2C bus to figure out what was going on. In the future I need to make sure that there is a place to plug into the I2C bus to debug network traffic. I will add this to my PCB design guidelines.

Back to the soldering iron to fix it. I started by putting some flux on the pins of the QFN package. Then, I draged a very fine tipped iron with a little bit of solder on it across the pins. After a couple of rounds of this, I got the chip working. I still need to cleanup the flux, but here is a picture of one side:

And here is a picture of the other side. You can see that I mangled the capacitor to the right during the rework process.

I think that a significant source of problems was not having the entire underside of the QFN with Solder Mask. That would have helped repel the solder and kept the blob from forming. I think that I will add that to the checklist as well.

Unfortunately when I was looking at the layout trying to figure out what was going on, I realized that the accelerometer interrupt pin was not connected to the PSoC. This happened because I had the pins connected by “name” in the schematic. This is something else that I will add to the checklist.

Using a hot air solder tool is definitely an art form. One that I will need to practice quite a bit before I get to anywhere near Jesusdan level of skill.

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: Debugging the PSoC Motor Driver

Summary

I spent a lot of time the last few days building and testing the Pinball board. This morning when I plugged in my oscilloscope to test the PSoC motor driver, I saw this:

Here is a screenshot directly from the oscilloscope. When I saw this, I wondered what was going on. Why does the driver pull-up very quickly, but have some kind of RC delay on the pull-down? This was particularly troubling as the PWM was set to 50 Hz (see on the picture where the (1) Freq is showing the measurement)

Broken Motor Driver Output

Things got much worse when I increased the frequency to 500 Hz. In fact, the motor driver doesn’t pull-down at all.

Crazy PWM Output

PSoC Motor Driver

So where do I start debugging? First I looked at the PSoC Creator schematic. When you look at the schematic you can see that I took the PWM output and steered it to either M0L or M0R (or M1L or M1R). Then I used a control register to flip it.

The M0R/M0L signals are used to control the switches on the H-Bridge. Here is the actual schematic from the PCB:

PSoC Motor Driver Schematic

I chose the Toshiba TB6612FNG motor driver chip for this design. It has two H-Bridges built in and is the same one that we used on the PSoC 211 Robot. You can see from the schematics above that I save 1 pin by attaching the PWM input to “H(igh)” and that I pulse either In1 or In2.

Hbridge Schematic

When you look at this table, or the schematic, you’ll see my problem. I connected one of the inputs to “L” That means that the NMOS switch that controls the pull-down is always off. When the PWM is low, there is no pull-down. That explains the funny RC pull-down, which is just some leakage on that node.

To fix this, I make this change to my PSoC Creator schematic. In this configuration I get the following:

CR=00 the output = 00 (stop)

CR=02 the output = 1PWM = CCW

CR=03 the output = PWM1 = CW

Now when I run this thing, here is what I get (at my desired 20KHz):

And finally a video showing the PSoC Motor Driver working:

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:

Create New PSoC4L Project + Integrate the U8G2 Library
Update the PSoC4L Firmware
Test the PSoC4L Firmware

Here is the picture:

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.

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 all of the .h and .c files by right clicking the project and selection “Add->Existing Item”

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.

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.

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.

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

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

ThingSoC: The TSoC GROVEY I2CHUB : I2C Hub/Switch

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

Summary

One of the boards that the Pattern Agents guys sent me was a TSOC GROVEY I2CHUB : I2C Hub/Switch. In this post I will take you through the process that I went through to evaluate the board and build an interface to the ThingSoc TSoC 4L base board.

Introduction to the TSoC Grovey I2CHUB
Discussion of PCA9546A I2C
Using the MiniProg-3 to interact with the PCA9546A
Building a Command Line Interface (CLI) using the USB/UART
Adding firmware to mimic the MiniProg-3 I2C list to the CLI
Adding a “port change” feature to the CLI firmware

Introduction to the TSoC Grovey I2CHUB

The ThingSoC I2C Hub is a ThingSoC Compatible (not Compliant) board that serves as a bridge from the base board to 4 separate programmable I2C busses using an NXP/TI 9546A bridge chip. Each of the I2C busses is attached via a SeeedStudio Grove connector. Grove is an ecosystem of sensors (Humidity, Temperature etc.) that are all? mostly? I2C connected.

Discussion of PCA9546A I2C

The PCA9546A is made by TI and NXP (or whatever they are calling themselves these days) and can be purchased for about $0.70 from Digikey, Mouser, or Arrow. The chip is pretty cool. It will let you connect your I2C master to 1 of 4 I2C busses. It will actually let you connect more than one bus at a time. This chip enables you to connect multiple slaves with the same address to your I2C master.

Here is a simplified picture from TIs datasheet.

To control the system you just need to write into the control register with a bit mask. The bit masks contains which slaves busses you want switched on. Here is a screen shot from NXPs datasheet:

Using the MiniProg-3 to interact with the PCA9546A

I start the whole firmware journey by using a MiniProg-3 as an I2C<–>USB bridge. This allows me to type I2C commands in the Bridge Control Panel which go directly to the chip (without writing firmware). In the picture below you can see that I have the MiniProg-3 attached to the ThingSoC board using jumper wires. I also use the MiniProg-3 to power the board.

When I press “List”, the Bridge Control Panel probes all of the I2C addresses. If a device ACKs, it prints out that fact in the output window. In the picture below you can see that PCA9546A is attached at address 0x73. I then read and write the control register, which also works as expected.

The address 0x73 makes sense as you can see that (in the picture above) there is a blob of solder on “A2” which pulls it low (instead of the default high). Here is that part of the schematic:

Building a Command Line Interface (CLI) over the USB/UART

Now I am ready to build a command line interface using the USB <–> UART Bridge. First, I make a schematic with the USB-FS (Full Speed), LED and I2C components. Notice that the USBFS is setup as a USBUART. The I2C is configured as a Master.

The Pins are selected as:

Next is a helper function to printout text via the CDC UART:

PSoC Creator Firmware PrintBuff Helper Function

Then I write a little bit of firmware for the CLI. The function just reads from the UART and, if the user has pressed a button, then it issues that command.

Lines 99-103 get the USBUART going, and deal with changes (e.g. unplug events).

The only thing that you might not have seen is the “Clear Screen”. I just send out the escape sequence (old school) for clear screen and move home from the VT100 Escape Codes.

Adding firmware to mimic the MiniProg-3 I2C list to the CLI

When you press “List” in the Bridge Control Panel, what happens? Although I have been using the Bridge Control Panel for years I wasn’t exactly sure. To find the answer, I plugged in my Saleae Logic 16 and watched the output.

Probing using MiniProg-3 and Saleae Logic-16

In this screenshot from the Saleae Logic output screen, you can see that the Bridge Control Panel sends out a “Read 0x15” which was NAKed.

Saleae Logic 16 address 0x15 NAK

In this screen shot you can see that when the “Read 0x73” occurs, that the PCA9456A ACKs which tells the Bridge Control Panel that the device is there.

Saleae Logic 16 0x73 ACK

While I was writing the entry, I looked around at several implementations. It appears that sometimes people send “Write Address” instead of “Read Address”. I wasn’t sure exactly what was right, so I consulted Dr. Zwave. He really should go by Dr. I2C since that is what he did at Cypress. Anyway, he pointed out that you will hang the I2C bus if you try a Read and then don’t read the next byte. With a write you don’t actually need to keep writing. I decided to follow his instructions.

I have always liked the output of the Raspberry Pi I2CDetect command. Here is a screen shot from one of my Raspberry Pi’s where a PSoC4 is attached on I2C Address 0x8. I am not totally sure why the command does not probe addresses 0x00-0x02 (comment with the answer and Ill send you a devkit)

The implementation of i2c_detect on the PSoC4L is pretty simple. All I need to do is iterate through all of the addresses from 0->0x7F. Then attempt to write. If a device ACKs then printout the address, otherwise move on. Instead of one big loop, I split it up into two loops to make the printing a little bit simpler. Here is the code:

Now, when I press “l” on the CLI, it probes all of the legal addresses on the I2C bus from the PSoC4L. You can see that only the PCA9546A at address 0x73 is active. How cool is that?

Adding a “port change” feature to the CLI firmware

The last block of code adds three functions which let me control the PCA9546A control register.

To test the whole thing, I attach the Saleae Logic Analzer to I2C Port1. Then I probe to make sure that I can attach and unattached the bus.

Test Jig for PSoC Creator Firmware

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: Driving the OLED using the U8G2 Library

In the previous Pinball post, I wrote about getting the OLED going and getting the footprint onto my printed circuit board. Now I need to make PSoC firmware to drive the display. I turns out that there are a number of different driver chips out there including at least SSD1306, SH1106, LD7032, SSD1325, and ST7920 that handle multiplexing the columns/rows, managing frame buffers, power management, etc. To make matters more fun, these chips support I2C, 3&4 wire SPI and a couple of different parallel interfaces (6800, 8080). I certainly didn’t want to go down the rathole of building up a complete driver library. But I didn’t have to, as it turns out that that Oliver Kraus built and open-sourced a very nice library that you can get at www.github.com/olikraus/u8g2. This library (and its predecessor u8glib) seem to be in pretty wide use in Arduino and Raspberry Pi.

In order to make the library work with the PSoC I had to do several things

Download it from GitHub (git clone git@github.com:olikraus/u8g2.git)
Created a new PSoC4200M project for the CY8CKIT-044 (which was the devkit that I happened to have sitting next to my computer)
Change the build settings (right click on the project and select building settings) then add the directory in “Additional Include Directories” and include the “u8g2/csrc” directory.
Add the header files to the project by right clicking and selecting “Add->Existing item” so that the project can f
Add the U8G2 C-Files to the project (same as step 4 but add the C files)
Build a schematic which has an I2C (for the display) and a debugging UART. The I2C is configured as a master with 400kbs data rate. The UART uses the default configuration.
Assign the pins

Now I am ready to build some firmware that will drive the display. In order to use the library with a PSoC I need to create two functions for the U8G2 HAL to use as an interface to the PSoC hardware. You initialize the U8G2 system with a call to the u8x8_Setup function. In that call you need to provide function pointers too the two HAL functions

The GPIO and Delay Interface
The byte oriented communication interface

This is an example of the setup required:

The GPIO and Delay interface is used by the byte oriented communication functions to read/write the GPIOs and provide delays. This function provides the underpinnings of a bit-banged I2C, UART, SPI etc. Because I am only going to use PSoC Hardware to provide the I2C interface I will only respond to the delay messages. All of the delay functions are implemented as busy wait loops, which I am not a big fan of. The input to the function is a “message” that is one of a sprawling list of #defines in the file u8x8.h. I believe that I found all of the possible cases, but I am not sure.

The first message, UX8X8_MSG_GPIO_AND_DELAY_INIT doesnt need to do anything because the GPIOs are configured correctly by the default.

I did not respond to the messages of the form U8X8_MSG_GPIO_X which are the read and write of the GPIOs as I am not going to use the bit-banged interface.

The other function that needs to be provided is the byte-oriented communication function. This function needs to respond to the messages to start, send, and end communication. I just mapped those messages onto the PSoC hardware APIs. While I was trying to understand what was happening with the system I implemented a debugging UART which you can see in the #ifdef DEBUG_UART sections.

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

Month: February 2017

Seeed Studio

Summary

Huaqiangbei Electronics Market

Summary

FreeRTOS Background

Execute a PSoC4 FreeRTOS Port

Create a PSoC4 FreeRTOS Test Project

Summary

LM317 Power LDO Power Supply

Summary

Hot Air Solder

Pinball machine PCB Solder Problem

Hot Air Solder Rework

Summary

PSoC Motor Driver

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

Summary

Create New PSOC4L Project + Integrate the U8G2 Library

Update the PSoC4L Firmware

Test the PSoC4L Firmware

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

Summary

Introduction to the TSoC Grovey I2CHUB

Discussion of PCA9546A I2C

Using the MiniProg-3 to interact with the PCA9546A

Building a Command Line Interface (CLI) over the USB/UART

Adding firmware to mimic the MiniProg-3 I2C list to the CLI

Adding a “port change” feature to the CLI firmware

Meta

Tags

© IoT Expert