Slot Machine

I remember when I was a 17-year-old, recent high school graduate, and was traveling with my grandparents from California back to their home in Michigan.  Of course we stopped in Las Vegas and walked the Strip just to see what there was to see.  Almost all of the casinos were open at the front so I wandered into one with my grandparents.  I saw a nickel slot machine and just had to stick a coin in.  Surprise, surprise, I hit the jackpot!  Jackpots were paid out as two rolls of 50 nickels each so a casino employee came over when the lights and sound went off.  He looked at me, handed the rolls to my grandmother and quietly told her that anyone under 21 really wasn’t supposed to be in there.

I like technology but I’m not a tech junkie by any means and I also like a lot of “old school” stuff like antiques, cars, etc.  For instance, if I ever decided to buy a pinball machine I’d want one from the 60’s or 70’s before they got too glitzy.  I’m also not a gambler but I remember how cool that old time slot machine was.  Just for fun I decided to check some out on ebay and about fainted when I saw the price tags.  I could probably afford it but I’m too cheap and there’s no place in our home for it anyway.  Still, I thought that the young grandkids might enjoy a toy like that when they come to visit so I decided to see if I could build a small version.


Old time slot machines had three windows and mechanical wheels with a variety of images that would spin behind the windows when a coin was inserted and the side handle was pulled.  The spinning wheels would come to a stop one at a time and some sort of payout would occur for various matching images.  They also tended to have flashing lights and noise if a jackpot occurred.  I wasn’t trying to exactly recreate an actual slot machine but at least it had to have some of the basics.  I needed a solenoid to activate the trap door for the coins when a jackpot occurred and some LED’s for flashing lights.  I also wanted some sort of sound so I found a sound recorder module in my junk box and recorded the ever popular phrase “Winner, winner, chicken dinner”.  It plays through a small speaker.

The display is one of the large digit surplus 1601 LCD’s that I have lying around.  I used square bracket characters to simulate three windows and finally decided to just use numbers instead of characters for the “tumbling” wheels.  I added a small buzzer to make a clicking sound while the digit “wheels” were turning.  I hemmed and hawed about whether or not to trigger the “spin” when a coin was inserted or to build a separate handle.  The coin slot I bought came with a coin reject button so I decided to use that to start the spin.  I mounted a micro switch so that it is activated when the coin reject button is almost fully pressed.  A piece of scrap PVC pipe was placed between the coin slot and the trap door to hold the inserted coins.

A big part of the fun was doing a little woodwork (one of my other hobbies) to build the cabinet.  I didn’t have anything that was quite right in my scrap pile so I headed to the local lumber store to look around.  One of the types they carry is poplar which, to me, sounded pretty bland.  But when I started sorting through boards I came across one that I just had to have because of its variety of color bands.  It was only later that I found out that it is an example of what is termed “Rainbow Poplar”.  Unfortunately, my photography doesn’t really do it justice.




Slot Machine

The schematic is shown above.  Most of the components have already been described in the previous section and are fairly obvious.  I placed four different color LED’s on the front, two on each side, and they flash back and forth when a jackpot is hit.  The schematic just shows those as two LED’s on PIC pins 11 and 12.  The sound module says it will run on 5 volts but the specs show it being happier with less than that.  Instead of a regulator I just put a couple of salvaged 1 amp diodes in series to drop the +5 volts to the module.  The inputs to the module prefer 3.3 volt levels so a resistor divider was added to the trigger input.

The solenoid runs on 12 volts and originally I had planned to just use a 7805 regulator to provide the +5 volts for the logic.  Because of the current draw of the large LCD, there was a lot of power being dissipated so I grabbed a simple DC-DC buck regulator board from my parts supply to do the job.  The small solenoid I used is not very powerful and won’t retract if too many coins are pressing down on the trap door.  That shouldn’t be a problem because I made the odds 8:1 to keep the kids interest up.  In any case, I decided to use a generic N-channel FET to activate the solenoid in order to reduce the voltage drop.


The main routine just loops continuously until the button on the coin slot is pressed.  There is no requirement to insert a coin first to activate the spin cycle but I’m hoping that the kids don’t figure that out.  While the main routine is looping, it is incrementing the variable “Random”.  It will simply overflow back to zero the cycle after it hits 255.  When the “Spin” routine is called it just goes through a list of checks on the value in “Random” to determine if a winner has occurred.  As stated earlier, the odds are set at 8:1 but it can be easily changed by modifying the winning values in “Spin”.  If a matching value is not found, then the logic just shifts bits in “Random” and displays each three bits as a number.  A test is done to ensure that an accidental match of digits doesn’t occur.

The power up display shows a question mark in each of the three windows.  While the “wheels” are spinning, each window will alternate between a blank and a question mark and then finally settle on a number one at a time.  That logic is contained in the routine “Send_Digs”.  Instead of having to constantly rewrite the entire display, the routine “Send_Dig” writes to a specific LCD location.  Also, while the “wheels” are spinning, the routine “Clickit” is called to simulate the mechanical sound of the wheels.  This is accomplished by sending 2ms on / 100ms off sequences to the piezio buzzer.

When a jackpot occurs the LED’s alternate flashing from right to left, the sound module is activated, and the coin door is released.  There are no partial payouts, just all or nothing.  After the coins are collected the coin door must be manually pushed back up to latch.  That’s it for this post.  Check out my other electronics projects at:

Slot Machine

GPS Clock

In my basement shop area I have a digital clock and, in the same project box, I have a receiver for Accurite weather sensors.  The weather sensor part is based on an earlier project that I modified to receive and alternately display temperature and humidity from both an indoor and an outdoor sensor.  The clock was based on an earlier project where I used a 4.194304-MHz crystal to get a nice even 2-Hz interrupt from Timer1.  The problem with the clock was that a power glitch meant that I had to reset the time.  I suppose I could have added a battery backup but that was too boring of a solution so I decided to run it on GPS time instead.


GPS Units


I have several GPS units (without displays) that output the standard NMEA sentences.  In a previous project I mentioned a couple of these and showed how to display a bunch of GPS information on a 4-line LCD display.  The smallest and cheapest of the units I have is the NEO-6M so that’s what I built into my clock.

It’s easy to connect the Ublox NEO-6M module to the PIC because it uses a TTL-level serial port and outputs standard NMEA-0183 sentences.  The only real difference is that the NMEA standard specifies a serial baud rate of 4800 but the Ublox unit defaults to 9600 baud.  You can run the free “u-center” program to change the baud rate but I just left it as factory default.  As I mentioned in the previous GPS project there is also a utility program called GPSInfo (put out by Globalsat) that is very handy for viewing GPS information.  You can hook up the GPS unit to a standard USB to TTL cable for checking it out or for setting it up using a PC.  Keep in mind that the GPS chip on the module actually runs at 3.3 volts (via an on-board voltage regulator) so if you want to connect to its RX port you should level shift down from 5 volts.  The TX port can connect directly to the PIC or the PC.

Time Zones

Displaying GPS time is an easy thing to do as long as you just want to display UTC (Universal Time Coordinated).  The NMEA sentences are composed of ASCII characters which can be directly output to the LCD.  The time portion is in the format of HHMMSS.FF (hours, minutes, seconds, and fractional seconds).  For our clock the fractional part is not useful so all we need to deal with is six characters.  The problem is that you then need to convert to your local time and to a 12-hour AM/PM format if you want that.  But sometimes problems are what make life interesting so that’s what the software is really all about.

As for time zones, you might think that there would simply be 24 of them with 12 of them east of the UTC location (+ zones) and 12 of them west of the UTC location (- zones).  In fact, there are a few oddball ones that are fractional hours and a couple that exceed the 12 hour “limit”.  If you happen to live in one of these areas I apologize because my software only accounts for the 24 whole hour zones.  There are also some of us who use Daylight Savings Time part of the year but that is not accounted for in the software.  I may make a later update to the software to handle it but it would require an “opt-out” capability as well as the storage in EEROM of future dates for the transition.  The software would need to be updated if those dates change at some point.  The hardware provides a switch for easy setting of the time zone so I settled for that at the moment.


GPS Connection

The hardware connections are shown in the diagram above.  The connection to the GPS is simply from the GPS transmit output to the PIC serial port receive input.  As mentioned earlier, the switch on PIC pin 4 is for setting the time zone.  The LCD connection is the standard 4-bit setup that has been used in a number of previous projects but the LCD itself is different.  Usually I have used the standard 1602 LCD (16 characters by 2 lines) but I chose to use a surplus 1601 display that has large characters so my old eyes can read it more easily.   The 1601 operates the same as the 1602 except it doesn’t have the second line.  In fact, my test board uses a 1602 and didn’t require any software changes.



The GPS outputs standard NMEA-0183 sentences which are ASCII strings that contain a variety of information.  For this application I chose the GGA sentence simply because that is what I used in my previous GPS project.  Fields of information in NMEA sentences are separated by commas so after the GGA sentence header is detected the software would normally count commas and call the appropriate routine for each desired field of information.  Only the time information is needed here and that is in the first field so no comma counting is needed.

The six time digits are buffered and then processed after all of them are received.  The GPS may output some incomplete messages early on so the buffering routine verifies that each character is an ASCII numerical value.  If a bad character is received, the message is discarded.  This may also happen on rare occasions during normal operation, particularly if the serial port communication drops a bit.  I’ve only seen this once and all that happened is that the time paused for a second and then jumped two seconds instead of one.

In order to convert the UTC to local time, the UTC offset (time zone) must be applied.  Because the UTC time from the GPS is in ASCII format, the software converts the ASCII characters to decimal, adds the tens of hours to the units, and then adds the UTC offset.  The UTC offset is stored as a positive BCD value with a sign bit so it is first converted to an integer value and a two’s complement is done if the sign bit is set.  Once the local time hour value is calculated a lookup table is used to convert it to BCD and then a routine converts the BCD to ASCII for display.  The lookup table needs to handle the 24 hour UTC format as well as +/- 12 time zones.  In order to do this, the UTC times from 0000 to 2300 occupy the middle 24 entries in the table with 12 entries before and 12 entries after to account for the time zones.  I chose to use a 12-hour format so I also added a lookup table for the AM/PM part of the display.

The time zone is retrieved from EEROM during initialization and briefly displayed.  If it has not been set at least once then the setting routines are called.  The setting routines can also be called at any time by pressing the switch.  The setting routines will initialize the display to “UTC OFFSET +77”.  If a negative time zone is required, a short press of the switch will change the value to “-00”.  If a positive time zone is required, then press and hold the switch until the value changes to “+00”.  Once the value is at zero, each short press will increment it up to a maximum of 12.  After reaching the desired time zone, press and hold the switch until the display reads “OFFSET SAVED”.  The software uses a 100ms timeout for switch debounce and counts 10 timeouts (1 second) as the command to transition to the next setting step or to exit.  If you make a mistake during entry, just exit and then press the switch again to reset it.

The NEO-6M doesn’t require a good position fix in order to output the correct time so it should output messages as soon as it gets one satellite.  Until then the display will read “NO DATA”.  That’s it for this post.  Check out my other electronics projects at:


HIIT Timer

Where I live, the cold months seem to go on forever so I have to find some way to exercise that keeps me indoors.  I could afford to go to a gym but it takes too much time, I’d have to show off my old body in public, and I wouldn’t be able to watch re-runs of Charlie’s Angels on a big screen TV.  Fortunately, our condo has a partially finished basement which gives us room for a treadmill, a manually operated stationary bike, and that big screen TV.  I’ve had a pretty set routine for awhile but I recently read in an AARP bulletin that it’s ok for “seniors” to engage in some forms of High Intensity Interval Training (HIIT).  After doing some research I found that one of those techniques could be perfectly adapted for use with my stationary bike.  I tried it, survived, and decided that I would try it again but decided that it was a hassle counting seconds for my high/low intervals.  Not to worry because I have a shoe box full of micro-controller chips and a lot of free time on my hands.


For the uninitiated, HIIT basically involves a warm up time followed by sequences of high intensity activity followed by low intensity activity.  In my case, the recommendation I found has 5 minutes of casual bike pedaling followed by 20 seconds of fast pedaling followed by 90 seconds of casual pedaling.  The only thing that varies with the high/low intensity sequences is how many you do.  For me the range is generally 4-6 sequences and then a few minutes of cool down.  The other thing I found was that HIIT should only be done 2-3 times a week, interspersed with other types of activity.  I figured that I could do the HIIT and then the next day do my regular treadmill routine.  That works for me but I’m no expert so don’t take this as advice.


HIIT Timer

The schematic for the timer is pretty boring because it just involves several LED’s connected to the PIC outputs.  I built it into a small plastic project box that I fastened to my bike frame with Velcro.  I run it on two alkaline AAA batteries with an on/off switch.  The LED’s are different colors with green being the one for the low intensity intervals (including the warm up time) and red being the one for the high intensity intervals.  The other six LED’s keep a count of the number of intervals completed.  Given that the maximum number recommended was 6, that’s what I used.  It also was a convenient number because it made the software simple when turning on subsequent LED’s (no need for a counter).  I couldn’t decide if I should use yellow or blue LED’s so I alternated them.




The software is also pretty boring as it basically just runs a one second timer and counts seconds for each phase of the exercise from warm up through the intervals.  There are defines for the length of the intervals so that is easy to change if you need different values.  Timing isn’t critical so I chose to use the 250-kHz internal oscillator to help conserve power.

To get the one second interval I used Timer1 and preset it so it would overflow after the desired count.  The desired count for one second is the oscillator frequency divided by 4 (62,500).  The overflow generates an interrupt and all of the logic is contained in the interrupt handler.  The specific routines are assigned based on which portion of the sequence we are in – warm up, high intensity, or low intensity.  The only “fancy” part is that I wanted a warning of when the next high intensity interval was coming.  To do that I simply determined if there was less than 10 seconds left for the low intensity interval and then turned the green LED on/off every other second.  The sequence count LED’s are all assigned to PORT C so a simple shift of a “1” bit will light the next one while keeping the previous ones lit.  The high/low intervals don’t stop after all of the LED’s are lit so if you want more sequences you can easily add code to reset the LED’s and start lighting them again.  That’s it for this simple project.  Check out my other projects at:


I2C 4-Digit LED Interface

In an earlier project I detailed an I2C (two-wire) interface to the common 1602 LCD.  Recently I found a cheap 4-digit LED module that uses a pseudo I2C interface.  I don’t have a particular need for it but I went ahead and added one to a parts order I made.  If you know a little about I2C you know that it is a serial interface where the controlling circuit provides the clock and controls the direction of the single data line.  Usually you can hang several I2C modules on the same pair of line (e.g.: clock module and display module) because each module has a unique address.  I said this LED module has a “pseudo I2C” interface because it does not have an address.  That means that it needs to be the only device using the data line.

LED I2C Module

TM1637 Module

The module I have is similar to the one shown here.  It is typically listed as part number TM1637.  You can find a variety of information on the web but I had a hard time finding all of the details I needed.  I also looked at some existing code (Python and C) which can often be a dangerous thing to do.  The one critical thing I determined from the code was that the data bits sent to the LED module need to be LSB first.  That differed from the approach for the other I2C projects I have done.  Another idiosyncrasy that I noted is that the addresses for the digits go from left to right (starting with address C0).  That means that data must be written from most significant digit to least significant digit if using the auto increment addressing mode.  In fixed addressing mode you would just pick the appropriate digit and write directly to it.

I2C Communications

I2C communications are accomplished by using just two wires: one for data (SDA) and one for a clock (SCL).  The data line is defined as being bidirectional so there needs to be a “master” device on the bus to control things.  The clock rate is limited by the slowest device on the bus and controlled by the master device.  Basically it sets a data bit and then toggles the clock line.  At the end of each byte transfer the master reverses the direction of the data line and then clocks in the acknowledgement bit from the slave device.

There are three basic commands for the LED module.  One controls the on/off and brightness of the display, one controls the address of the digit to write, and one controls the addressing mode (fixed or auto increment).  Usually an application will just load all four digits each time so the auto increment mode is normally used and the address set to the first (left-most) digit.


LED I2C Interface

The connections to the PIC are pretty simple with only two I/O pins being used.  That leaves four other pins on our little 12F683 for getting sensor data.  This same connection can be used with the 16F688 if we want more I/O pins.  The module already has the required pull up resistors on the SDA and SCL lines.


The software link is listed below.  While it is targeted for the 12F683, it is easily ported to bigger versions of the PIC like the pin compatible 16F688 that I use for a lot of my projects.  Some of the newer PICs also have a hardware I2C interface so most of the related software routines would be greatly reduced or eliminated.

The I2C routines are the same as those I wrote for the LCD project but a lot of the other LCD-specific code was not needed for the LED module.  I added a lookup table that converts single packed ASCII characters to the required LED segments.  I also added a second test routine that shows how you can make non-ASCII displays by turning on the right segments.  The data bit associations for the segments are shown in the header of the software source code.  The eighth bit in the segment bytes is reserved for turning on the colon that resides between digits 2 and 3 on the module.  In my tests it appeared that all four characters had to include a 1 in the eighth bit in order for the colon to light.

I added a line of code to the end of the “i2cwaitack”routine to try and recover if the slave does not acknowledge the data transfer.  If the slave fails to acknowledge a transfer then the software will be reset by enabling the Watch Dog Timer (WDT).  Newer PIC chips have a software reset command that can be used instead.  An alternative for some I2C applications would be to simply make a call to “i2cstop” and then continue where the code left off.  That’s it for this post.  Check out my other electronics projects at


Intruder Alert

In an earlier post on my website I detailed a PIC microcontroller project that allowed me to capture information about a variety of RF security system sensors I have.  In this post I have taken the information I collected for a cheap 433-MHz motion detector I bought on ebay and turned it into a usable circuit.  In addition to the PIC, I use an RF receiver module and a solid state voice recorder/player.  All of the parts, including the motion detector, cost less than $15 total so you can have some cheap fun with this project.



The motion detector module I used looks like the picture above.  It uses a 12 volt battery and has an extendable whip antenna.  The RF signal it puts out is strong enough that I didn’t even have to add an antenna to my RF receiver board for use in my house.  I used a sensor logger circuit (detailed in another project on my website) to determine the sync and bit times for the sensor as well as the actual data bytes.  The sensor outputs 24 bits (3 bytes) of data and each sensor has a different pattern.  There is also one stop bit.  The sync time turned out to be 10ms and the bit times were about 320us and 970us.  I verified this with a second sensor and also by capturing the RF receiver output on my oscilloscope.  There are many examples online that detail how to capture this information using a PC audio card.

RXB6 Front

The RF receiver module I prefer is a super heterodyne receiver called the RXB6.  It has much better range than the cheaper receivers that commonly get paired with an RF transmitter module.  In fact, when I was trying to buy a few extra RF transmitters I ended up buying them with the cheap receivers for less than 60 cents a set from a USA seller.  I’ve kept the bad receivers for now but will likely never use them.

ISD1820 Module

The sound recorder/player module is commonly listed as ISD1820.  That’s actually the chip part number but it’s also the module designation.  The particular version I bought is shown in the picture but pretty much all of them work the same.  It’s convenient to have the push buttons on the module so you can do the recording and verify the playback before embedding it into your circuit.  These modules are typically set up for a maximum of 10 seconds of recording but the manual shows how to modify them for shorter or longer times.  The maximum time is 20 seconds but the tradeoff is lower quality.  It’s probably not a problem for simple voice messages.  I was pleasantly surprised at the clarity of the recording.

Motion Detector

The schematic is shown above.  The sound modules are often advertised as being able to run on 5 volts but the recommended range for the chip is 2.7-4.5 volts.  Just to be safe I’ve added a cheap 3.3 volt regulator (LM1117) to drive the sound module.  That also means that the play trigger from the PIC needs to be reduced in voltage so a simple resistor voltage divider is used.  The resistor values are not critical.  Just try to get the ratio of values to about 2:3.


There are some defines in the first part of the software that may need adjustment for your application.  There are defines for the sync time (in milliseconds) and the 0/1 bit times.  The bit times are actually for the OFF part of each bit because that is how the software does the measurement.  The bit times are not in milliseconds but are the expected count for the upper half of Timer1.  Each count in TMR1H represents 128 microseconds based on the 8-MHz clock frequency of the PIC.  This simplification works because the shorter bit time will always exceed 256 microseconds but never exceed 384 microseconds.  Likewise, the longer bit time will always exceed 896 microseconds but never exceed 1024 microseconds.  Again, this is based on measurements I made for my sensors.  Yours may be different.  Another set of defines is included to represent the byte values transmitted by the sensor.  These will be different for your sensor.

The software uses the 16-bit Timer1 to measure the sensor bit durations by counting only during the low level part of each bit.  That meant that I needed to use the T1G (Timer1 Gate) input of the PIC.  I also wanted to check on the pulse counts when they completed so I used the INT (external interrupt) input and set it to trigger on a rising edge.  Each bit (including the stop bit) always starts with a rising edge.  The bit value (0/1) is determined by the duration of the high part of each bit but we actually measure the low part because we also want to measure the low level time between data messages for the sync.

The interrupt handler is triggered by the rising edge of each bit.  At that point the upper half of Timer1 is read.  If the Synced flag is not yet set, then the software determines if we have measured a sync pulse.  The math is easy because all we do is round up (add 4) and then right shift three times (divide by 8).  That gives us the integer number of milliseconds.  If the value matches our required sync time then the Synced flag gets set.  That allows us to skip directly to the bit measurement part of the code for subsequent interrupts.  If a bit time matches, then it is packed into RF_Byte and the Bit_Found flag gets set.  If a bit time doesn’t match then everything previously collected is discarded and we wait for a new sync pulse.

After the return from an interrupt, the main part of the software checks the Bit_Found flag to determine if it needs to take action.  If a complete byte has been received then the software checks the value against the expected value for the sensor.  That is done by calling a simple lookup table with the indices for the table being the variable Byte_Count.  If a byte doesn’t match, then everything is discarded and we wait for a new sync pulse.  If all three bytes have been received and match, then the software sends a high-level pulse to trigger the sound module.  An Alarm LED is also turned on and remains on until power is cycled.  The reason I added that is to facilitate testing and as an event memory.  That way I can position the sensor and receiver at different locations and verify successful operation without having to use a second person to listen for the sound.  I can also test sensor locations to make sure that heater/cooler air flow or one of our cats doesn’t cause a false trigger.  That’s it for this project.  be sure to check out my other projects on my website:

Motion Detector

Rootin’, Tootin’, Shootin’ Game

When I lived in Orange County, California two of the biggest employers of college kids were Disneyland and Knott’s Berry Farm.  Because I had electronics training from the military I was able to get a job in the Knott’s shooting gallery instead of having to wear a funny costume.  The rifles used high voltage flash tubes with focusing lenses and the targets used photo cells.  The target counter circuits used germanium transistors set up as flip-flops.  The transistors were becoming harder to find so someone had tried replacing them with silicon ones.  Unfortunately, they found out that the fast switching times of the silicon transistors made them much more susceptible to noise.  That meant that a single hit on the target would ripple through the counters and light all of the lamps at once.  The lesson here is that sometimes slow is good.

Recently I was thinking about those days and decided to see if I could design a simple shooting game for my grandkids.  The game detailed here pits two players against each other to see who can get to five hits first.  I also decided to use a cheap red laser diode as the heart of the gun.  You could use laser pointers if you want but the circuit I include for the gun ensures that you get a single shot instead of a steady on beam.

Light Sensor Modules

Light Sensor Module

At first I was going to just use photo transistors for the sensor circuits but then I discovered the light sensor modules shown above.  I bought a pack of 10 for next to nothing from a China supplier.  The modules do use a photo transistor but they run the sensor voltage into an LM393 comparator so it provides a digital output as well as an analog one.  A potentiometer onboard can be adjusted to set the trip level of the comparator.  It also includes a power on LED and an LED that lights when the comparator switches the digital output.  That makes it easier to adjust the proper level.

Target Hardware


The bulk of the hardware consists of 10 LEDs and 10 resistors.  I used standard 5mm bright white LEDs for indicators 1-4 and a slow flashing LED for the 5th indicator.  The switch is normally open momentary contact and is used to reset the game.  The PIC microcontroller is a standard one that I’ve used in other projects.  As you can see in the pictures, I built the LED modules separately in order to make it easier to locate them in a target.

Target Layout

Target Top

Gun Hardware

Laser Gun

The basic hardware and schematic for the laser gun is shown above.  I built mine into plastic toy airsoft guns.  The barrel tube for the pellets is almost the perfect size for the laser diode modules and I was able to fit a battery holder for two AAA batteries in the opening for the magazine.  There are plenty of cheap laser diode modules out there and basically they differ only in the value of the current limiting resistor mounted onboard.  That resistor determines the voltage rating of the laser module.  I use two AAA batteries so I picked 3 volt lasers.  The switch is a single pole, double throw micro switch.  The capacitor is used to force a single burst of light with every pull of the trigger.  In one position of the switch the capacitor charges up and in the other position it discharges through the laser.


Like all of my PIC projects, the software is written in assembly language.  What makes this project a bit unusual is that the Main routine does nothing because all of the action takes place in the interrupt handler.  The PIC has a feature called interrupt-on-change which, in older PICs, generates interrupts on any positive to negative or negative to positive transition on an I/O pin.  This particular PIC allows the software to set the interrupt source to be either the positive edge, negative edge, or both edges.  The light sensor module will generate both edges on a transition so this feature is quite handy.  In this case, the software waits until the sensor output switches back high (off) before the interrupt is generated.

When a sensor interrupt is received, the software temporarily disables that input and sets a timer.  In effect, the timer acts like a debounce circuit for a switch.  At the 8-MHz clock selected for the PIC and the setup for the timer, the total timeout is about 130ms.  When the timer finishes, it also generates an interrupt.  At that point, the sensor input is re-enabled.  Each sensor input has its own dedicated timer so there is no conflict between players.

Each sensor interrupt will also light one of the LEDs for that player.  Instead of a counter, the software uses a variable that has one bit set.  That bit gets left shifted with each interrupt and is then OR’ed into the output port to light the next LED.  When the last LED is lit, the interrupt handler disables further interrupts and that effectively locks out the other player.  The reset switch is connected to the MCLR input of the PIC and the configuration bits are set to allow that function.  When reset is pressed, the software will reinitialize and clear the LEDs.  That’s it for this post.  Check out my other electronics projects.

Shooting Game SW