A dsPIC-Based Infrared Controller

Abstract

Presented is an infrared controller which uses a dsPIC30F2010 digital signal controller. This project was intended primarily as an introductory project to demonstrate the capabilities of the dsPIC chip. On-chip peripherals including the PWM, Timers, and UART are utilized in this project however the true capabilities of the chip (namely the DSP core) are not used.

IR Controller II

This controller is basically a programmable, 'learning', remote capable of sampling the infrared signals from a variety of devices and playing-back macros consisting of signals from these multiple sources. The original intent was to produce a centralized remote controller for satellite music channels which, for a single command, can turn on both the satellite receiver and home theatre amplifier, select a specific music channel on the satellite, and select the appropriate input source on the amplifier. Commands are received via an RS-232 link on the controller allowing control from a remote terminal consisting of an LCD and keypad.

Hardware

The IR controller is built on a dsPICDEM 28-pin prototyping board which features a 30F2010 MCU and a connector for an ICD-2 debugger module. The project requires connection to both an IR LED and an IR receiver module which are soldered directly onto the prototyping area of the demonstrator board. Pin RD0 of the MCU, which serves as the output from the on-chip PWM peripheral, drives an IR LED directly through a 47 ohm current limiting resistor. Pin RE0 connects directly to the output of an IR receiver module. This module features three pins - Ground, Power, and Output - and derives its power from the demonstrator board. Many modules require a pull-up resistor: a 2K2 or 4K7 resistor between the output pin of the module and the +5V power line should suffice. In this particular project, the module was removed from a scrapped VCR - the original PCB was inspected and the Vcc and ground leads easily identified.

Since access to the UART is required as well as the ICD debugger the Rx/Tx lines from the MCU must be rewired on the demonstrator board. Unfortunately, the default configuration of the 2010 chip utilizes pins RF2 and RF3 for both connection to the UART as well as the debugger. To solve the problem, and allow simultaneous use of both the debugger and the UART, jumper the RF2 and RF3 lines to the ICD debugger inputs and connect wires between RC13 and RC14 to the RS-232 transceiver chip (a DS275) on the demo board (visible in the photo as blue wire-wrap wires). Remove R5 and R6 on the demo board to allow the rewiring. A simple line in software (bset U1MODE, #ALTIO) routes the internal UART lines to the alternate I/O lines (RC13/14).

Software

In order to sample a new IR signal it is necessary to make a small change to the program an used the ICD debugger to read the sampled signal in File Registers. To begin, the following lines are un-commented and a breakpoint is added to the 'nop':

;Sample IR Signal to RAM
	call	SampleIn	;To sample, enable and break
	nop			;Breakpoint
The program is then RUN under the IDE environment, the new remote faced at the IR receiver module, and the key pressed. When a low-going signal is detected in the 'SampleIn' function, 0x800 binary samples are obtained. Each sampled bit is shifted into a RAM location and, after eight bits are samples, the byte-wise pointer is incremented to point to the next memory location. When done, the entire sampled signal is located at 0x900 in memory - One may now simply open the file register window and COPY the data from there into a the 'const' section of hwords (see any of the samples in the data tables section).

In operational mode the 'SampleIn' function is not called and the system continually waits for a command via the RS-232 link. An ISR (__U1RXInterrupt) is utilized to allow reception of characters from the UART and buffer them into a memory location called 'Command'. With the appropriate command received, the system plays-back samples by initializing a pointer (w5) to the appropriate sample table and calling 'SampleOut'. The samples are decoded in an anaolgous manner to how they were sampled (by rotating the register containing the byte to play-back) and turning the 40KHz PWM peripheral ON and OFF.

Conclusion

Hardly a 'polished' project, this application is a gem in the rough and requires a good bit of cleanup. First, the sampling system needs to be made considerably more user-friendly than to require the user to modify code then CUT and PASTE infrared samples from memory into tables in program code! Assuming the controller is used only for a single IR device, this method is functional (however not elegant).

Finally, it would have been wise to allow the linker to manage memory rather than hard-coding memory locations as is done here. One simply has to change the following lines:

 	MOV #0x08A0, W15 	;Initalize the Stack Pointer to top-of-RAM
	MOV #0x08FE, W0 	;Initialize the Stack Pointer Limit Register
	MOV W0, SPLIM
to
	mov	#__SP_init,W15	;Initialize the Stack Pointer to base address
	mov	#__SPLIM_init, W0	;Initialize the Stack Pointer Limit Register
	mov 	W0, SPLIM
as suggested by Microchip. As well one must allocate memory for the samples using the 'bss' directive instead of simply using memory which is simply assumed to be unused (0x900 in the prototype) as follows:
.section	.xbss	;Uninitialized X- space
.align	2
Samples:	.space  0x100        ;Reserve 0x100 Bytes

Download the firmware in MPLAB 7.xx assembler format