THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

RECYCLE YOUR CODE

Conversion and Optimization Techniques
by Stephen Bowling

Start ý A Code Example ý Optimizing the Code Conversion ý Sources and PDF

OPTIMIZING THE CODE CONVERSION

There are still a few modifications that can be done to improve the efficiency of the code. Letýs take a look at what can be done. For reference, Listing 3 shows the optimized code.

Consider the variable locations. For the minimal code conversion, you left the three variables in their original locations. There is no advantage to moving these variables because they are all located in the Access Bank region (0ý7Fh). In fact, no relocation of variables should be required for an application that uses 256 bytes or less of data memory. In this case, all variables will be located in bank 0 (0ýFFh), and no data memory banking will be required. For applications that require more than 256 bytes of data memory, there are benefits to relocating the variables. More frequently used variables should be located in the Access Bank so that they can be accessed in a single instruction cycle.

Certain program instructions can be changed or deleted to decrease program memory usage. All data memory banking instructions that modify the IRP, RP0, and RP1 bits can be deleted. The CALL and GOTO instructions use two program words in the PIC18Cxxx architecture so that the entire 2-MB address range can be encoded into the instruction. These instructions write to the program counter directly, so you can also delete instructions that write to PCLATH before CALL and GOTO instructions. Certain CALL and GOTO instructions can be further optimized to reduce program memory usage. The RCALL (relative call) and BRA (unconditional branch) instructions have been implemented in the PIC18Cxxx architecture. These one-word instructions may be used when the destination program counter location is less than 2048 bytes away from the present address.

It should be noted that PCLATH still needs to be set up when using a data lookup table. When the low byte of the program counter (PCL) is the destination for an instruction, the values in PCLATH and PCLATU will be transferred into the program counter.

Lookup tables that contain large amounts of data can be modified to decrease program memory usage significantly. When the data is encoded using RETLW instructions, two bytes of program memory are used to store each byte of data. In the PIC18Cxxx architecture, the lookup data may be accessed using table read operations. Because there are 100 bytes of data, it would be beneficial to convert the temperature lookup data in my example application.

Because the data memory is available, you can load the temperature lookup data into data memory at powerup. At the beginning of the program, TBLPTRU, TBLPTRH, and TBLPTRL are initialized to the location of the temperature data table in program memory. You also load FSR1 with the location for the table in data memory. The data is transferred with minimal code using the automatic post-incrementing modes for the TBLRD instructions and FSRs. Listing 4 shows how this is accomplished.

Now that the lookup data has been transferred to data memory, it may be easily accessed using the PLUSW addressing mode of the FSRs as shown:

lfsr 1,RAMTempTable ; load FSR1 with the address
; for our data table in RAM.
Movlw Offset ; put table offset in WREG
movff PLUSW1,Result ; move data table value to result register

The automatic post-increment mode of the FSRs has also been used in the optimized code to clear the data memory before program execution ends. The following code segment clears the data memory in the PIC18C452:

lfsr 0,0 ; set fsr0 to 0
ClrRAM clrf POSTINC0 ; clear location and incr. FSR
movlw 0x06 ; have we cleared 1536 bytes?
subwf FSR0H,W
bnz ClrRAM ; no, keep going

There is one final optimization that you can make to the source code. The interrupt service routine in the PIC16C74B code saves WREG and STATUS in temporary registers. This is not required for this application because the main program loop does not perform any function. However, most applications require context saving, so I included it in the source code. You can remove the context-saving instructions in the code because the PIC18Cxxx devices have three shadow registers for the WREG, STATUS, and BSR registers. When an interrupt occurs, these registers are automatically saved in the shadow registers. To restore the saved registers at the end of an interrupt service routine, a "fast return from interrupt" is performed as follows:

RETFIE FAST ; restore values from shadow registers

One thing to remember about the shadow registers is that they are only one level deep. If priority interrupts are enabled and a high-priority interrupt occurs during a low-priority interrupt, the shadow register values will be overwritten. So, if your application uses both high- and low-priority interrupts, be sure that the shadow registers are used only for the high-priority interrupt service routine.

THAT'S ALL THERE IS TO IT

Now, youýve seen that migrating an existing PICmicro software design to the PIC18Cxxx device family is a relatively simple process. The PIC18Cxxx device family has many features that enhance program efficiency, while maintaining source code and peripheral compatibility with other device families. The thermometer application, as written, consumes 205 ý 14-bit words of program memory on the PIC16Cxxx architecture. The converted and optimized code uses 145 ý 16-bit words of program memory on the PIC18Cxxx architecture, providing a 19% reduction in program memory usage.

PREVIOUS • NEXT