| Navigation |
Home
IR Control
PIC IR Decoder
PIC IR Hardware
PIC IR Software
RC-5 Decoder
NRC-17 Decoder
JVC Decoder
NEC Decoder
Sharp Decoder
Sony Decoder
X-Sat Decoder
| PIC IR Software |
This chapter describes how the software of my PIC IR Decoders works.
You can safely skip this chapter if you're not interested in the software's internals, though I do think reading this chapter might be educational for the assembly language novices.
Here I will describe the part of the software which is common to all my PIC IR Decoders.
The actual decoding routines are described in the chapters which are dedicated to the particular protocols.
I will only explain the most important parts of the program.
The rest can be read from the source files, which are included in the download package.
It goes without saying that the software is written in my own SB-Assembler, which can be downloaded from this same site if you want to make alterations to the software. There is no need for the assembler if you only want to use the programs as they are, because all HEX files are included in the download package.
| PIC IR Software |
First of all let's make a list of all the tasks the software has to perform:
- Receive and decode IR messages
- Scan the display
- Flash the central decimal point whenever a valid IR message is received
- Clear the display 2 seconds after receiving the last IR message
All these tasks are to be performed simultaneously, at least they should appear to be.
The first task is obvious, we need to receive and decode the IR messages because that's what we're here for.
Receiving IR signals is a time critical process and may not be disturbed by other tasks.
The second task is also rather important.
All digits must be shown in turn in a rapid and steady pace, otherwise we can see the display flicker.
This task is also rather time critical.
The last two tasks are not very time critical, but have to be performed in a way which does not influence the first two tasks.
| Main Program Loop |
There is only one main program loop, which is a good start for most of our microprocessor adventures. We enter this main program loop right after initializing the machine and we'll stay there for ever, and ever, and ever, and ever..... Until the power is removed from the system.
;-----------------------------------------------------------------------------
;
; Main program loop
;
;-----------------------------------------------------------------------------
MAIN
;-----------------------------------------CALL THE IR RECEIVER STATE MACHINE--
CALL IR_MACHINE Call the IR receiver state machine
;-----------------------------------------------------SCAN DISPLAY EVERY 5MS--
DECF SCAN_DELAY,F Decrement scan delay counter
BTFSC STATUS,ZERO Only scan display if counter = 0
CALL SCAN_DISP
;-------------------------------------------------------SYNC MAIN WITH TIMER--
.SYNC BTFSC TMR0,7 Wait until bit 7 of TMR = 0
GOTO .SYNC Not 0 yet!
MOVLW TIMER_UPDATE Reload timer again
ADDWF TMR0,F
GOTO MAIN
Most of this snippet are comment lines.
If you delete the comments, there is hardly any code left.
That's good, because we have to be fast to be able to decode all supported protocols.
How fast?
After some careful considerations I've decided to let the main loop execute in exactly 50 micro seconds.
This means that each task is called every 50 µs, over and over again.
The first task is to call the IR Decoding routine IR_MACHINE.
Every protocol will get its own IR Decoding routine and will be described later.
The second task is scanning (multiplexing) the displays.
That doesn't have to be done every 50 µs though.
Therefore I used a delay counter which is decremented every iteration of the main loop.
The SCAN_DISP routine is only called when this counter reaches zero.
The final piece of code in the main loop is a synchronization loop.
This loop will ensure that every iteration of the main program loop will last 50 µs.
For this purpose I use the PIC's hardware timer.
That timer will increment every instruction cycle.
At 4 MHz that will be every 1 µs.
We will simply wait until the timer overflows from $FF to $00, which can be detected when bit 7 of the timer changes from 1 to 0.
As soon as the timer overflows it is updated with a value that will ensure a 50 µs interval.
The timer is not simply reloaded, but is updated.
Imagine that we just had a very busy main loop which lasted 70 µs instead of 50.
The next main loop will then last only 30 µs, gaining up for lost time.
Why didn't I use an interrupt driven timer? Simple, because we're in a hurry! An interrupt routine will take about 10 µs extra because of the call, the return and the necessary context switching that are involved. This time can be put to better use in this time critical application.
The shortest execution time of the total main loop, excluding the time spent in the subroutines, is 11 micro seconds. The shortest execution time of the IR state machine is 6 µs, which makes a total of 17 µs for the entire loop. The .SYNC routine will eat away the rest of the time to complete the 50 µs. This ensures ample time for the other tasks, which rarely all occur at the same time.
| Display Scan Routine |
The display is multiplexed, which means that there's only one of the four digits turned on at a given moment. Each digit is turned on for 5 ms, after which it is switched off to allow the other digits some time of their own. Thus the total scan cycle will take 4 x 5 ms = 20 ms, which makes the scan frequency 50 Hz.
The display scan routine is built around a state machine.
A what?
A state machine.
Every time the routine is called it updates a pointer to point to a routine that has to be executed the next time.
That way we execute a total of 4 different routines, one for each of the digits.
Surely there must be a reason why I used a state machine.
And the reason is: time!
Normally one would update a pointer, which points to the segment pattern of the next digit.
Updating such a pointer involves incrementing the pointer, limiting the range of the pointer and adding an offset to the location of the segment pattern in RAM.
Furthermore a shift register must be updated, which will drive the next anode.
Updating this shift register involves shifting the previous value and limiting its range.
Clearly this all takes quite some time.
We will soon see that the state machine can nibble away some instruction cycles at the expence of a slight increase in the number of program steps.
;-----------------------------------------------------------------------------
;
; Scan display routine
;
;-----------------------------------------------------------------------------
SCAN_DISP MOVLW MS5_COUNT Reload scan delay
MOVWF SCAN_DELAY
MOVLW %1111.1111 Switch off all Anode drivers
MOVWF PORTA during the switch
MOVF SCAN_STATE,W Jump to next display's routine
MOVWF PCL
The first part of the scan routine is common to all digits.
First of all the scan delay counter is reloaded.
This counter will ensure that the SCAN_DISP routine is called every 5 ms.
Then all anode drivers are switched off.
Switching off all digits at this stage ensures that we won't see ghost segments which slightly light up when we load a new pattern while the previous anode is still driven.
Then the state machine kicks into action.
A pointer to the routine for the next state is loaded into the program counter PCL.
I took care that all state machine routines start at program page $00, which makes indirect jumping a little easier because PCLATCH can remain $00.
Loading PCL with a state pointer effectively means that we're jumping to one of the four routines SCAN_DISP1, SCAN_DISP2, SCAN_DISP3 and SCAN_DISP4.
;-------------------------------------------------------------SCAN DISPLAY 1--
SCAN_DISP1 MOVF DIGIT1,W Get pattern of left most digit
MOVWF PORTB and send it out
MOVLW %1111.1110 Switch left most digit on
MOVWF PORTA
MOVLW #SCAN_DISP2 Next time do SCAN_DISP2
MOVWF SCAN_STATE
RETURN
I will use SCAN_DISP1 as an example.
The other 3 routines are basically the same.
So the state machine directed us here, which means that digit 1 has to be turned on now.
We simply get the pattern for DIGIT1 and copy it to PORTB, the segment outputs.
Then we drive the anode for digit 1 by loading PORTA with the proper bit pattern.
Finally we set the state machine pointer to the SCAN_DISP2 routine, which will be called the next time we have to scan the display.
Do you recognize the power of the state machine now?
We can simply use direct addressing to get the pattern for digit 1, no pointer needs to be incremented, limited and offset to get the pattern.
And the proper anode is directly addressed, without having to shift and limit a shift register.
The total execution time of the display scan routine is 15 µs.
I said that the other 3 state routines are basically the same. That is not entirely true because I abused two of them to do some extra tasks.
;-------------------------------------------------------------SCAN DISPLAY 2--
SCAN_DISP2 MOVF DIGIT2,W Get pattern of 2nd left digit
MOVWF PORTB and send it out
MOVLW %1111.1101 Switch 2nd left digit on
MOVWF PORTA
MOVLW #SCAN_DISP3 Next time do SCAN_DISP3
MOVWF SCAN_STATE
DECF DP_DELAY,F Decrement DP_DELAY every 20ms
BTFSS STATUS,ZERO
RETURN We're done if counter <> 0 !
BSF DIGIT2,7 Clear Digit 2's decimal point now
RETURN
SCAN_DISP2 is one of the states which differs slightly. The first 6 instructions should be very familiar to you. Yes they are very similar to the ones found in SCAN_DISP1. It's up to you to point out the 3 differences.
But the fun is at the end of this routine.
There a counter called DP_DELAY is decremented, and every time it reaches $00 bit 7 of DIGIT2 is set.
This piece of code's purpose is to switch off the decimal point that is used to indicate that a good IR message was received.
Remember that was one of the 4 original tasks of the software!
Every time a good IR message is received DP_DELAY is loaded with a small value and bit 7 of DIGIT2 is made 0, which effectively lights the center dot.
This small value of DP_DELAY is decremented each time SCAN_DISP2 is called, which is every 20 ms.
As soon as the counter reaches 0 we set bit 7 of DIGIT2, effectively turning the dot off again.
The keen observer will notice that the counter continues to count down, even if the dot is off.
That is no problem, because after 256 iterations the dot which is already off is turned off again.
Not stopping the counter at 0 saves us some valuable micro seconds.
;-------------------------------------------------------------SCAN DISPLAY 4--
SCAN_DISP4 MOVF DIGIT4,W Get pattern of right most digit
MOVWF PORTB and send it out
MOVLW %1111.0111 Switch right most digit on
MOVWF PORTA
MOVLW #SCAN_DISP1 Next time do SCAN_DISP1 again
MOVWF SCAN_STATE
DECF CLR_DELAY,F Decrement CLR_DELAY every 20ms
BTFSS STATUS,ZERO
RETURN We're done if counter <> 0 !
MOVLW %1011.1111 Only display 4 dashes
MOVWF DIGIT1
MOVWF DIGIT2
MOVWF DIGIT3
MOVWF DIGIT4
RETURN
SCAN_DISP3 has no extra's and is identical to the SCAN_DISP1.
But SCAN_DISP4 does have some extra's too.
Again the first 6 instructions are similar to the ones found in SCAN_DISP1.
After showing digit 4 to the user the counter CLR_DELAY is decremented, which is done every 20 ms.
If that counter reaches zero all four digits are cleared to a dash in the center.
That way we can make the displayed code disappear after a few seconds when no valid IR messages are received any more.
Each time a valid IR message is received a large value is loaded into CLR_DELAY and the received message is displayed.
CLR_DELAY will be reloaded as long as valid IR messages are received.
Once the counter is not updated in time it will eventually reach zero, which causes the display to be cleared.