Project Logs

Collapse

• Putting it together. Switch matrix

  Scott Gillins • 07/11/2014 at 16:40 • 0 comments

  In my project there are over 40 switches.In order to connect that many switches I would need a lot of ports on my micro.Since I did not have a micro that could handle that many connections along with the all the other I/O that I needed I decided to configure the switches in my project using a matrix configuration.

  With a matrix configuration a lot of pins on a micro are saved but additional processing and logic has to be programed into the system.A nested loop configuration will have to be setup in the code to iterate through all the pin combinations.By sending a signal down one row at a time and looking for that signal on the each of the columns one at a time we can determine what the state of each switch is.Because we send the signal down only one row at a time the position of the other switches that are also connected to that row will not cause a false switch state.

  Pseudo Code :

  Set all rows pins low;

  Set all cols pins low;

  Define row,col as int;

  Define matrix_state[7][7] as int;// matrix_state as 2 dimensional array of ints

  Loop through rows:

  For(row=0; row<7;row++){// outside loop to iterate through rows

  Set pin row high;

  For(col=0;col<7;col++){ //inside loop to iterate through
  cols

  Set matrix_state[row][col]= data read from port expander for
  pin col;

  } // close inside loop

  Set pin row low;

  } //close outside loop

  The above pseudo code is not a complete solution but instead shows the logic of what it takes to read through a matrix of switches.There will be more subsystems that we be called at each point in the code since I am using a port expander connected via I2C.I will not be able to just check the state of the pins but instead will have to make a call via the I2C bus to tell the port expander to report their status.

  After the code is run I will have a variable matrix_state that I can then use to test for other logic cases in my code.The logic case that will be tested in my code would use this variable instead actually checking the state of a physical something.For example if I have the Control-O-Matic setup as a missile launcher and I want to see if the missile arm switch is on or off I would not write code to go check the state of that switch.Instead with a mapping that indicates the arm switch is located at row 2 col 4I would then have my code read the variable matrix_state[2][4] to see the current state of the physical switch.The code would run the above code periodically to update the current states.The will allow all the sub functions to read a variable quickly instead of each sub function having to make a call to the I2C bus to get the information that is specific to that function.

• Putting it together. Electrical

  Scott Gillins • 07/09/2014 at 22:11 • 0 comments

  As I started to put together the documentation for this project of mine I realized that a traditional schematic would not provide much value since I used several dev boards and did not have one big PCB that had all the parts on it.  Since you still need to understand how it is all put together I have crafted a little block diagram to show how the major pieces are connected.  I plan to put together some more details on the individual blocks as time allows.  Maybe in version 2.0 I will integrate all the pieces into a single PCB.  I know it would make assembly a lot easier than it was this time.

View all 2 project logs