Month: September 2016

When Billy and I talked about making the electronics package for the Pinball machine, I suggested that it would be cool to have some motors.  Mr. Mechanical Engineer’s eyes lit up when I made that suggestion.  There are tons of things that the kids to could with a couple of controllable motors.  You could imagine conveyor belts, spinning obstacles, and all manner of lift systems.

I wanted to use inexpensive DC Toy motors.  The problem with most motors is that they require higher voltages (5-9 volts) and currents (250mA for the one that I wanted) than the PSoC (or generally any MCU) is capable of delivering.  Well that’s OK, it turns out there is a whole class of Power Management ICs (PMICs) which provide translation between an MCU and a Motor.  The one that I am going to use is called the TB6612.  This chip has dual Hbridges that help you control both the speed and direction of two motors.

First, the chip uses NMOS transistors configured as switches to let you control higher power (voltage and current) circuits.  Here is a picture of the input to the PMIC from the datasheet:

Second you want to be able to control the speed and direction of the motor.  Here is a screen shot from the data sheet that shows the inputs and what happens with the motor.

Here is a picture that shows you how the current flows through the Hbridge as well as showing the circuit that keeps you from short circuiting between the phases.

So, how do you control the speed?  Simple, you use a PWM to create a train of pulses that have different duty cycles.  The greater the duty cycle, the faster the motor goes.  The lower the duty cycle, the slower the motor goes.

One last problem.  The chip requires IN1, IN2, PWM and Standby, but I want to only use two outputs from the PSoC.  So, what I decide to do is

• Turn the standby off (so that the chip is always active)
• Attach the PWM input to high so that the motor is always spinning
• Attach In1 and In2 to the PSoC.  The PSoC will then set them to the correct value and PWM.

In the next post Ill start the process of turning all of the different blocks into a schematic that can then be turned into a printed circuit board.

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

 

In the previous three posts I created a Music Player component by building the symbol+schematics, making a public interface, and writing the firmware.  In this post I will show you the test program called “MusicTestComponent”.

In order to get access to the PinballComponents library project I first right click on my project and edit the dependencies.  Specifically, I click on the box that adds the “PinballComponents” as a dependency of the MusicTestComponent project.

After setting up the dependencies you can then make a schematic with the MusicPlayer and a UART.  The UART will be used to trigger commands to be sent to the MusicPlayer Component.

I start the main firmware by creating a test song called “scaleNotes” (lines 5-12).  I then turn that array of Notes into a Song by declaring  a Song and adding the scaleNotes to the song (lines 15-19).

At the start of the program I turn on the interrupts and start the components (line 27-31).  Then I add my song to the component (so that it can play it) with line 33.

In the main loop of the program I grab characters from the UART and issue commands to the MusicPlayer component based on what button the users presses.

On lines 57-62 I have a debugging pinout that prints out the currently playing note number each time the note changes.

Thats it.  In the next post I will start taking you through the process of designing the printed circuit board.

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

In this previous posts I showed you the Schematic/Symbol and the public API for the Music Player.  In this post I will take you through the firmware.  The first section defines:

• Parameters of the system, specifically the clock frequency and PWM prescaler (line 4-5)
• The internal variables that are used to keep track with what is happening on the son (lines 8-12).
• The notes for twinkle twinkle little star (Lines 22-43)
• An array to hold songs (line 47-48)

The GetNote function just returns the current songs currently playing note number.  I used this function when I was trying to debug the player.

The FrequencyToPeriod uses the settings of the PWM and the desired frequency to calculate the Period/Compare values to achieve the desired output.  The PWM has three parameters that change its output.

• The input clock
• The input prescaler (just a divider on the front end of the PWM)
• The period (what you are trying to calculate)

The next note function figures out the right settings for the PWM based on the desired frequency of the note, then sets up the PWM to the correct values (line 88-91), it then calculates how long to play the note (line 92).  Finally it sets thing up for the next note (line 97-101)

The SysTickCallBack function controls the amount of time that

• A note plays (lines 138-139)
• The gap between the notes (lines 132-136)
• The buzzer sounds (116-124) if the TWO_CHANNELS are enabled

The Start function initializes all of the internal variables to turn off the songs.  The MusicPlayer uses the SysTick timer to keep track of how long the notes and the Buzzer have been on/off.

The Stop function turns off the Buzzers.

The function PlaySong initializes all of the internal variables that are used to keep track of the song status.  It points at the first note, then it calls the NextNote function.  This function returns the ErrorCodes value which enables me to do a range check and existence check on the song number (lines 185-188).

The SetBPM changes the internal variable _BPM which is used to calculate the duration of notes.  This function also returns an ErrorCodes value after doing a range check.

The AddSong function allows the component user to define a new song and to assign it the list of Songs.

The last section of code provides the buzzing functionality.  These function turn on and off the 2nd buzzer.  The first function turns on the 2nd buzzer at the requested frequency for either 0-means infinite time or a # of milliseconds.  Notice that this section of code only shows up if the user has turned on the second channel (line 230).

In the next post Ill show you the test code for the component.

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

After you have the symbol and schematic (look at the previous post) for the Music Player completed, the next step is to build the firmware to actually play the music.  This starts with building the public API in the MusicPlayer.h file.  I am not a musician… not even close.  When I was in 4th grade I tried to take up the trumpet, but the music teacher told me that I was terrible and should stop, so I did.  That was the last time I ever took crap advice from a teacher.

Anyway, I want a simple interface to

• Define songs
  • Made up of an array of notes with frequency (in Hz), duration (as a fraction of a whole note = 64 counts)
  • With a known number of notes
  • With a default beats per minute (BPM)
• Play songs
  • Start the song
  • Stop the song
  • Change the tempo of the currently playing song
• Play buzzer tones
  • Turn on the buzzer at a frequency for a duration
  • Permanently turn on the buzzer
  • Turn off the buzzer

Lines 7-10 define the basic type called a Note which is the combination of a frequency and a duration.  To make things simple a WHOLE_NOTE is defined as 64 time units.  So, a half note is 32 counts and a quarter note is 16 counts etc.  You can see some common definitions on lines 20-22.

Lines 12-18 define some common notes which are frequently used to build up songs.  These are all from the middle octave of a piano keyboard.  I found the frequencies from a table on the internet.

Line 24-30 define a list of possible error codes that can be returned by my functions.  Using an enum is much safer than returning an error code with a #define because the compiler makes sure that you actually return a value with meaning.

Line 32-36 defines a Song which is a combination of an array of notes, the number of notes in the array and speed to play the song.

Finally lines 38-49 define the actual public functions.

In the next post Ill take you through the firmware.

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

In order to build a test case for the SwitchMatrix component, I first create new project called “SwitchMatrixTest”.  Then I create a schematic with the component and a UART.  Notice that I draw the “external components” of the switch matrix, but I can’t hook it up to the actual component because I never created the external terminals for the SwitchMatrix component (bad Alan).

Next I edit the main.c First, lines 4-5 are to flags that are set by interrupt service routines.  The switchedFlag is set by the component when you have registered your interested in a switch changing event.  The sysTimeFlag is set every 200ms by the sysTick ISR.

Lines 15-19 saves the status of the switch interrupt flags for use by the main loop.

Line 27-34 is a simple timer that I implement using the SysTick timer.  I set a flag every 200ms which I use to printout things on a regular basis in the main loop.

In the main program I first start all of the components, interrupts etc in lines 43-47.  On lines 52-75 I process the user input and try out different functions of the component.

Lines 79-84 causes the status of the switches to be printed out IF the switched flag is set.  The switched flag is set in the callback function switchedCallBack();

Lines 87-91 print out the status of the switches every 200ms based on the system timer.

In order to get my SwitchMatrix component to call back when a rising/falling edge occurs, I need to register that call back in the cyapicallbacks.h.  I first make a forward declaration of the function on line 15.  Then I #define the “SwitchMatrix_SWITCHED_CALLBACK” which tells the component which function to call.

In the next set of posts I will discuss the Music Player.

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

In the previous post I took you through the steps in creating the symbol and schematic for the Switch Matrix Component.  Next, we need to look at the firmware API.  First we will build the public interface to the component.  Ill start by adding “SwitchMatrix.h” to my component by

• clicking on the components tab
• right clicking on the “SwitchMatrix” component and selecting “Add Component Item…”

• Choosing “API–>API Header File”

In the SwitchMatrix.h I define the public interface to the component.  For the switches you want to have:

• A polling interface
• An interrupt based interface

On line 6 I wanted a bit mask to represent the status of the switches.  When I setup things originally I was not sure how many bits I was going to support and I wanted to be able to change the length of the bit mask with just one #define.  Given that my switch matrix component can do 8 rows and 8 columns a.k.a. 64 switches I probably should have set this mask to uint64_t.  BUT when I started the work I didnt know that type existed so I just used uint32_t.  It is even a bit more confusing because Cypress provides the non CMSIS-CORE definition of uint8, uint16, uint32…  All that aside, if you  change the #define it will change for all of the switches.

On lines 8-13 I define a new type that defines the list of possible interrupts (No interrupt, rising edge, falling edge or both edges).

Line 15 defines the start interface.  This component uses the systick timer to run the state machine that sequences turning on/off of the switch rows/columns.  The “number” is which of the 4 Cypress SysTick interrupt vectors to use.

Line 16 returns the status of switch at row,column and returns 1 for active and 0 for inactive.

Line 17 returns the status of ALL of the switches into a bit mask

Line 18-21 defines the interrupt based interface to the switch matrix.

• Line  18 request to be interrupted based on row,column
• Line 19: clears the interrupt flags
• Line 20: returns the falling interrupt flags
• Line 21: returns the rising interrupt flag

The big question with the interrupt interface is: What function is called when an interrupt happens?  The answer is: I used the “cyapicallbacks.h” functionality that PSoC Creator provides for you (more to follow).

All of the bit masks that I used are of the form of [ r2c2,r1c2,r0c2 r2c1,r1c1,r0c1 r2c0,r1c0,r0c0 ]

The next thing that you need to do is to implement the actual firmware for the system.  Start by adding “SwitchMatrix.c” to the component (using the same method detailed above except choose “API C File”.

On lines 4-9 I turn Symbol Parameters into #defines which can be used in my source code.  Remember that we let the user define the $NumCols, $NumRows and $RefreshInterval.

Line 10 is a neat way to make a bit mask of all 1’s up to a bit position.  e.g if you want 3’s aka 0b111 then you can do 2^3-1 = 7 = 0b111.  This bit mask is used to mask off the read bits from the pins.

Line 14 defines a variable which is the Current Column that you are looking at.  This changes every READ_INTERVAL/# of column ms and cycles through the columns.

Line 16 is an array of the bit masks of the status of each of the columns.

Line 17 holds flags for which rising and falling switches you are interested in for an interrupt.

Line 24-25 holds the status of which of the switches caused the interrupt.

The SetInterruptMode function sets the bit mask for the rising or falling interrupt.  The $INSTANCE_NAME_MASK_TYPE is the type (in this case uint32_t) of the bit mask for switches.  On line 41-42 I turn off the interrupt.  Then the switch on line 44 resets the bit based on the input.

The ClearInterrupt function just clears all of the interrupt flags (rising and falling).  It returns the state of the flags (before the reset).

The function “SwitchCallBack” (which should have been defined static) is the main brains of switch sequencer. It is called every 1 ms by the SysTick callback.  Lines 92-94 lowers the frequency of doing something by only updating the status etc every “READ_INTERVAL/Column” ms.

Line 97 reads the digital input pins of the switch matrix.  It uses the row_mask to mask off the bits that are not being used.  It turns out that this was not needed because when you read a bus of pins the Cypress APIs automatically mask off the other bits.

Lines 100-105 builds a bit mask of the status of all of the bits.

Line 111-112: sets the interrupt flags by comparing the “nextStatus” with the “currentStatus”

Line 118 moves turns on the next column pins.

Line 124: Calls back if there is an interrupt.  It uses the “cyapicallbacks.h” to figure out what to call back.  This could have been done by registering a function pointer… but oh well that is what Cypress decided.  To use this you do a #define MatrixSwitch_SWITCHED_CALLBACK with the name of the function you want called.

The next functions are just simple helper functions which return a status or start the component.

In the next post I will show you some simple firmware to test the component.

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

In the post entitled “Pinball: Matrix LEDs Component” I took you through the steps to create an LED Component.  In this post I will take you through the steps to do the same thing, create a component, for the Switch Matrix that I talked about in the last post.  Since I did the LED component I figured out how to embed the pins into the component and have a variable number.  I am going to go back and fix the LED component.

The first step to create the Switch Matrix Component is to click on the “Component” tab so that you can create a new component in the “Pinball Components” library.

Now, add a new component to the library by right clicking the “Pinball Components” library and selecting “Add Component Item…”

Start by creating a Symbol for the “SwitchMatrix” component.  If you don’t want to draw all of the parts of the symbol then just use the automatic “Symbol Wizard”.

Next, add three component parameters, which will be editable by the user of the component.  Do this by right clicking on the blank canvas part of the symbol editor and select “Symbol Parameters…”.  Add NumCols, NumRows, and RefreshInterval.  These will be usable in your source code as $NumCols, $NumRows and $RefreshInterval.

Then, put the component into the right place in the component catalog by right clicking on the blank canvas in the symbol editor and selecting “Properties”

Select the “Doc.CatalogPlacement” and type in the place where you want the component to show up in the Component browser.  In this case we want it in the “Pinball” tab, in the “Switch” category.  The name of the component will be “SwitchMatrix”

For this component I want the user to be able to change the number of rows and columns.  I will do this by embedding the row and col digital input/output pins inside of the component.  And, the row,col pin components will be busses so that I can change the number.  First, you need to add a schematic to your component to hold the pins.

I need to place a digital input pin (for the rows).  I select the number of pins to be 3 (this parameter will be changed by our customizer).  Also turn on the pull up resistors.

Then I place a digital output pin for the columns.

When I am done I will have a schematic that looks like this:

Now I need to fix things up so that the user of the component can edit the number of pins.  To do this, I need to be able to edit the hidden parameter on the Cypress pins component which has the property of the number of pins in the bus.  To do this I first need to enable the secret menu which lets me edit the raw parameter.  This is on the Tools->options->design entry->component catalog menu.  You can see the “Enable Param Edit Views”.  By selecting this option you will be able to edit the raw parameter values on the components.

Once you have enabled the menu you will be able to right click on the “Pins” tab of the component and show the “Show Expression View”

Instead of the graphical interface to the component (shown above) you will have a list of the raw parameters (shown below)  Scroll down to “NumPins” and change it to the parameter that I put onto the symbol, “$NumRows”

Lastly, do exactly the same thing for another pin for the Columns.  In the next post I will show and explain the source code for the component.

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

In the previous post I showed you how to build firmware to drive the LED matrix.  That firmware is in my TestMatrixBlinking project as led.h and led.c.  All that is pretty cool, but what I would really like is a component that is in a library, that I can configure the number of rows/columns and the update frequency–just like the other PSoC Components.  To do that I will go through the following steps

1. Create a new library project
2. Create a new component and symbol in the library
3. Add the led.h to the header of the component
4. Add the led.c to the implementation for the component
5. Update the component properties to have the update frequency, number of rows, number columns etc.
6. Add a reference the library in a test project
7. Make the test project

First create a new project in the workspace.  In this case, I will build a library project.  A library project can’t be programmed into a board, but instead is used to hold components.

Ill name the project “PinballComponents”

Then I will create a new component.  To do this click on the components tab in the workspace explorer (in this picture you can see that I already added the new component)

Next right click on the “PinballComponents” tab and select “Add Component Item”.  Then pick Symbol Wizard and name your Component “MatrixLed”.

After you do that you will have “MatrixLed.cysym” in your library project.

Now you need an API header file for the component.  To get this, right click MatrixLed and do “Add Component Item”.  Then select “API Header File” and tell it your header file will be MatrixLed.h

Now copy the source code from led.h into MatrixLed.h. Replace “MatrixLed” with “`$INSTANCE_NAME`”.  When PSoC Creator builds your project it will replace the $INSTANCE_NAME with whatever you name your instance.

The next step is to create the implementation.  To do this right click on MatrixLed and then select “Add Component Item”.  Pick “API C File” and name it MatrixLed.c

Copy the source from “led.c” into the “MatrixLed.c”. Replace MatrixLed with “`$INSTANCE_NAME`” just like you did in the .h file.

Now, right click on a blank space on the canvas in the symbol screen, then select “Properties”.  On the property “Catalog Placement” type in “Pinball/LED/LedMatrix”.  This will name a new tab for the component browser, a new subcategory and the name of the component.

This is how it will appear in the Component Catalog.

Now right click on the symbols canvas and select “Symbol Parameters”.

The symbol parameters will show up in the component customizer when the user double clicks.  Add five parameters:

• ColComponent as a string and a default value of “col” (this is the name of the pins component that you will use for the rows)
• COLS as uint8 and a default of 4
• ROWS as uint8 and a default of 4
• RowComponent as a string and a default value of “row” (this is the name of the pins component that you will use for the columns)
• Refresh as a uint8 with a default of 5 (this will set the #define for the Refresh rate)

Next I realized that if I move the “NUMROWS” and “NUMCOLS” macro from the .c to the .h I will be able to use those macros in my main.c

Then I modify the .c writes to the pins to have the names of the components

The last step is to create a test project to make sure that everything works.  I create a new project called “TestBlinkingComponent”.  In order to access the Pinball Components you need to add a dependency to the new project.  To do this right click the new project in the workspace explorer and select “Dependencies…” then add “Pinball Components” to your list by clicking the “Components” checkbox.

Now I make a schematic that looks like this.

Because I moved the #defines to the .h file I can use them in the main project.  You can see that on line 21 where I reference MatrixLed_NUMROWS

That is it for the component.  You can find it and the test project (TestLedBlinkingComponent) on github.

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

In the previous post I talked about the design and test of a matrix of LEDs, specifically a 3×3 matrix.  The benefit of the matrix is that you use only sqrt(# LEDs) GPIO pins.  For my Pinball machine I am planning on using a 4×4 matrix.  There are two problems with this technique:

1. You must limit the current through the LEDs so that you do not exceed the maximum current from the GPIO (which has the impact of dimming them)
2. You can only select one row at a time (which has the impact of dimming them)

So how do you solve these problems?

Problem 1: Maximum Current

The worst case current occurs when you have one row selected and all 4 columns selected.  Here is the equivalent circuit:

From the PSoC Datasheet I find that the maximum current in any GPIO is 25mA.  That means the maximum current through any of LED/Resistor branches must by less than one fourth (because I have 4 paths) of 25mA = 6.25mA.  We know that the forward voltage of the LED is about 3V.  In the previous post about LEDs I showed you that the worst case HighOutputImpedence is 180Ohms and the worst case LowOutputImpedence is 50Ohms.  Given those numbers, what is the value of the current limiting resistors?

R1 =  (5.5v – 3v – (180 Ohm*6.25mA) – (50Ohm * 6.25mA) ) / 6.25mA = 170 Ohms

Problem 2: Select One Row at a Time

How do you enable all of the LEDs to be turned on and still only select one row at a time?  The answer is that you need to time division multiplex the rows.

1. Turn on row 0 for 10ms, turn on the correct columns
2. Turn on row 1 for 10ms, turn on the correct columns
3. Turn on row 2 for 10ms, turn on the correct columns
4. Turn on row 3 for 10ms, turn on the correct columns
5. Go back to the start

This means the LEDs will “blink” but they will blink so fast that you will not see them blinking.  The LEDs are being refreshed at 25Hz with a maximum duty cycle of 25%.  Before I build a general purpose component (the topic of the next post) I will make .h/.c files to implement the the timing scheme.  I start this process by copying the “TestMatrix” project from the previous post into a new project called “TestLedBlinking”.

What should the API for the LED system be?  What do I want the user of the component to be able to do?

1. Start the system
2. Turn on a specific LED
3. Turn off a specific LED
4. Toggle a specific LED
5. Start an LED to blinking at some frequency
6. Stop the blinking of a specific LED

To implement this I add a “.h” file called “led.h” to my project.  This file will contain the public interface to my LED system. On lines 11-18 I create the function prototypes for the interface.  But what are lines 5-9 about?  I want the LEDs in my system to have three possible states (ON,OFF and BLINK) but a “binary” variable is only two states.  I could use an integer with some convention about what 0,1,2,3,…. means with #defines.  But this is error prone as it is not type checked by the compiler.  To help avoid the errors I create a new Type of variable (using enum) called “MatrixLed_LedState” that has the three states that I am interested in.   The rest of the file contains the public interface to the component.

After I finish the public interface I now need to build the implementation.  To do this I add “led.c” to my project with the c-functions and variables.

Lines 5-6 define the number of rows and columns in my design.  My comment says that you need to keep this less than 8 because the PSoC can only write to one 8-bit port at a time.  I use this to simplify the firmware.

Line 15 declares an array of uint8s that are the actual bits that need to be written to the columns to turn on/off the led in that row.

Line 17 declares a (row by column) sized array to keep track of the state of each LED.  It is of type “MatrixLed_LedState”

Lines 19-27 declare two arrays to keep track of the “counter” and “period” of the software PWM that I use to blink the LEDs.  (see the function MatrixLed_UpdateBlinking)

The first function to build is the “Start” function.

Lines 120-128 just iterates through all of the row,columns and sets the bit mask to 0 (LEDs OFF) and the States to (OFF).

On lines 129+130 I start the SysTick timer.  I do not like using CyDelay to keep time.  When you use a CyDelay the processor does what is called a busy wait loop that looks like this:

for(int i=0;i<10000;i++); // 10000 is the number of times the CPU has to go through the loop for some amount of delay.  This is dependent on the CPU frequency

This “for” loop keeps the processor sitting in the same spot doing nothing but making heat.  This is not going to work in our system as we need other things to be going on simultaneously (like running switches, buzzers etc).   Instead of a busy wait loop I will use the built in timer in the ARM Cortex M0 core.  That timer is called “SysTick”.  In the Cypress PSoCs, this timer works when the CPU is Active or in Sleep.  By default, it “ticks” every millisecond.  Cypress provides you an API to turn on the timer called “CySysTickStart()”  How do you use it?  You register a callback function using the “CySysTickCallback()”  This function takes two arguments

• The callback number (you can have up to 4 callbacks)
• A function pointer to the function you want called back when the timer “ticks”

The function MatrixLed_RunStateMachine is called by the SysTick interrupt.  This function is the basis of the whole system.  I want to every few milliseconds not every millisecond.  Specifically “every few” means every “MatrixLed_REFRESH” milliseconds.  I do this to save on CPU time.  In order to implement this idea I keep track of number of times the interrupt has been called using the static variable on line 108.  On line 112, when I reach an even number of “MatrixLed_REFRESH” I allow my processing routines to run.

The other thing that I do in this function is toggle a pin high when I start the processing and then toggle it low when I finish.  I wanted to know how long the interrupt routine ran.  It is a very bad idea for interrupts to take a long time as it can impact other things going on in the system e.g. servicing the BLE.  By toggling the pin I can attach the test board to a logic analyzer and see how long the interrupt service routine takes.  Here is a screen shot from my Salea Logic Analyzer where you can see that the interrupt takes 10.5uS (worst case) runs every 3.986 ms which works out to a duty cycle less than 1% (so it shows 0%).  Why is it 4ms as earlier I said that you should do 10ms?  I tried 10ms, but I can see the LEDs flickering so I increased the update frequency.

The next block of code drives the column and row pins to the right values.  On line 73 I declare a static variable currentRow which I use track which row needs to be driven this time.  Remember this function gets called every 10ms by the SysTick Interrupt.  Line 74 actually turns on the current row.  It uses the “<<” which is the c-operator also known as left shift.  That makes a value with a “1” in the position of the current row and a “0” in the other bits.  On line 75 I set the column bits to the correct value.  The system is “active low”, meaning you activate a column by driving it to ground.  After all of the updates are done you setup for the next time on line 76 by moving to the next row.

The only other interesting thing about this function is that I declared it with the keyword inline.  This keyword tells the compiler to NOT call it as a function but to put it directly in the assembly language at the place where it is called i.e. to embed it there.  Using inline will save CPU cycles as you don’t have to save a bunch of registers onto the stack, jump, pull a bunch of registers and jump back.  The only downside is that you will get multiple copies of the same function (wasting space).

The next function handles the blinking.  The blinking is a simple software PWM.  The PWM counts from the “Period” down to 0.  When it hits 0, it toggles the LED, then resets the counter back to the Period.

This function when called, iterates through the matrix of LEDs (using the two nested for-loops), if an LED is in the blinking state (line 89) then do the down count and toggle the LED if needed.

The MatrixLed_Blink function configures the state and period.  The period is set by:

Period = 1000/frequency/2/MatrixLed_REFRESH

The last three functions are just helper functions to set the bits in the “MatrixLed_ledRows” for the column values.

In the next post Ill show you how to turn all of this into a component.

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

In the previous post I talked in detail about driving LEDs using the PSoC4 BLE GPIOs.  The basic problem that I have now is that I want to drive way more LEDs than I have available GPIO pins.  Using one GPIO per LED means that I am only able to drive 8 LEDs with the 8 pins that I have reserved.  But I want to do 16 not 8.  So now what?  To solve this, I configure the LEDs into the Matrix.  In the schematic below you can see an example 3×3 test matrix.  It uses 6 pins and is able to drive 9 LEDs.

So how does it work?  Simple.  Write a 1 onto the row you want to enable then write a 0 onto the other rows.  Next write a 0 onto the column you want to enable and a 1 onto the other columns.  For example, if I drive 010 onto the “row” pins and 101 onto the column pins then the LED I have labeled 1,1 will turn on.  With this scheme the row pins are used to drive the “power” and the column pins are used to drive the “ground”.

Then I get the lab assistant a.k.a. 12 year old son Nicholas to build up a test board.

I need a little bit of firmware to turn on each LED one by one.

• Lines 17-19: iterate through the three rows/columns
• Line 23: write the correct pattern to the row driver (001,010,100)
• Line 21-22: print the current row column to the UART
• Line 24: write the correct pattern to the column driver (110,101,011)

After that everything seems to work… you can see how bright the LEDs are in the movie below.

In the next post I will show you how to Time Division Multiplex the LEDs and explain what the problem is with that scheme.

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