Sensor Calibration with Lookup Tables

• Lookup tables are lists of data bytes stored sequentially in program ROM or RAM, often used to store calibration data for sensors in order to compensate for non-ideal sensor behavior
• Calibration can be done in hardware or software, tuning the gain and offset for each sensor or calibrating via a lookup table to correct the output value

Hypothetical Sensor Calibration

• Sensor 2's output is offset by 0.5 V from Sensor 1, and Sensor 3's output is 1.2 times Sensor 1's output
• Lookup tables can calibrate the outputs of Sensors 2 and 3 relative to Sensor 1
• Option 1 for calibrating Sensor 2 involves a subtraction after the offset is looked up, while Option 2 saves the "correct" values directly in the lookup table, saving a subtraction

Considerations for Lookup Tables

• Complex relationships between input and output values can be handled with lookup tables
• Limit testing may be required to apply a lookup value for ranges of input values
• In Computed GOTO lookup tables, the lookup values are stored in program memory
• Implemented as a normal subroutine that is called when a value needs to be looked up
• First instruction manipulates the program counter
• Subroutine has multiple lines from which it can return using the RETurn with Literal in W (RETLW) instruction

Computed GOTO Characteristics:

• Values of the table are successively included in the instructions
• With the ADDWF instruction omitted, the subroutine will always return from the first RETLW instruction
• With the WREG pre-loaded with a value, this pre-loaded value is added to the PCL, and the subroutine will return from the instruction at the altered address
• The PCL needs to be offset in even numbers to avoid a word alignment

Computed GOTO Lookup Disadvantage

• Computation is easy to use but each data byte takes up two bytes of program memory because the data has to be coded as part of an instruction

Table Reads and Writes:

• The program memory is implemented as 8-bit registers, so table reads and writes allow access to each byte individually
• Two bytes can be stored per program word

Implementing Dense Data Tables:

• Refer to Section 5.2.2.2 Table Reads and Table Writes, and Section 6.1 Table Reads and Table Writes in the PIC18F45K22 datasheet
• The table pointer is loaded with the address of the memory location to be accessed.
• Special instruction places the content of a specific program memory register into the TABLAT register
• Lookup tables can be stored in data memory, but will be destroyed upon reset
• Calibration lookup tables can be stored in data memory

Indirect Addressing:

• Achieves dynamic changing of addresses to data memory locations
• Allows implementation of pointers in Assembly Language

NIBBLE Table Basics

• Understanding of the different ways in which data tables can be implemented in a µC including the assembly language coding of data tables

Code Example 16: Computed GOTO

• The values are coded into a number of RET(urn) with Literal in) W (register), i.e. RETLW, instructions
• Offset value (in WREG) specifies the number of bytes that the program counter should advance
• It should be multiples of 2 (LSB = 0)

Code Example 17:

• Demonstrates implementation of a table where the bytes are stored successively in program memory
• Only data are stored without needing to store it as part of an instruction
• The "db" directive in MPASM stands for "declare data of one byte".
• Used to reserve space in memory to be intialised with bytes
• label db value1, value2, .... valueN

Code Example 17b: Table Writes

• It's not possible to write one byte at a time on the PIC18F45K22
• The hardware allows writing a block of 64 bytes at a time to the program memory
• One would need two write operations if more than 64 bytes needs writing to memory -- first writes 64 bytes -- second writes the remaining bytes

Macros: code Example 19

• Reduces the repetitiveness of coding
• Macro will be coded only once that will be copied as needed
• Can customize certain requirements
• Sequence of instructions/statements will be coded ONE time within the macro definition
• It supports modular programming in assembly language
• Has an include file
• The invoked macros code can be physically inserted into the program code to verify it.