Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.


Link To This Forum!

Partner Button
Add Stickiness To Your Site By Linking To This Professionally Managed Technical Forum.
Just copy and paste the
code below into your site.

PIC lookup table

PIC lookup table

I am working on a PIC program for a boost gauge. My input is a pressure output should be 3 4-bit BCD numbers.  The part i am having trouble with is a lookup table for the input pressure.  the easist way i have come up with to do this is having a lookup table.  The problem is that since this is a 10-bit a/d converter, the lookup table will need to be 1024 words long.  The PCL register is only 8 bits. Can you add the 8 least significant bits to the PCL register, and then add the carry and 2 most significant bits to the PCH bits of the PCLATH register?  Will there be any other problems i am overlooking because this is such a large table? I have seen some articles on making lookup tables under 256 words long, but nothing about over 256.  Thanks in advance vor any help!


RE: PIC lookup table

I confused as to why you are surprised?

"3 4-bit BCD numbers" is 0 to 999 range, which is not that different than your 10-bit A/D at a 1024 range, so you had that problem before you selected your A/D.

>  Why did you select a  10-bit A/D?  
>  Is that resolution justified, e.g., does going from n to n+1 counts significantly change your control output?
>  Do you really need the full range of 10-bits?  What is the actual input pressure range?


RE: PIC lookup table

The 10 bit a/d is built into the PIC.  I will be measuring from 0-40 psi with a resolution of 0.1.  That exceeds the 8 bit boundary.  I dont understand how to make the table accessable across a page boundary.

RE: PIC lookup table

The math routines in an544 have a binary to bcd function.
Also what processor are you using?

RE: PIC lookup table

Again, do you really need 40psi/1023 resolution?  That's 0.04 psi resolution.

Even if you do, a simple interpolation will still probably get you sufficient accuracy from an 8-bit table.


RE: PIC lookup table


Right justify the result.  Copy ADRESH into the PCLATH, then "addwf" ADRESL into PCL.  You will have four 256-byte blocks of retlw instructions.

What PIC is this?  If it's a higher end series (18F, some 17F series), consider using a DT table to automatically create the necessary retlw instructions.


RE: PIC lookup table

Oh, I forgot to add...

Make sure each of the four 256-byte tables reside completely within a 256-byte boundary (use an "org" statement  that begins on a boundary before each table if they're not contiguous, like 0x200 or 0x300).


RE: PIC lookup table


Some of the "larger" 16F pics have the ability to read
their program memory directly!  For example the 16F77 will allow you to do this and I'm 90% sure the 16F877 family will allow you to do this too!  I believe that you can set the address in a pair of registers, then read back the 14 bits of data held in the program word.  I've used this technique quite effectively for passing strings out.

Some of the "smaller" 16F pic DO NOT have this feature and indeed you must return the word with a retlw instruction.  I have "crafted" several of these tables.  I've built small perl scripts to output the "retlw  <value>" instructions in ascii then imported the output to the source code.  Sometimes it is faster to do this than to hand construct.  Another way that I have used is to generate macros and make it a real simple macro name, like "x".  Then you can use the assembler directives to craft the opcode and operand.

Just some tricks that I've used to get the tables loaded up.

I don't think that you can utilize the PCLATH register as you have suggested directly.  I cannot confirm this however and would be quite interested to see the results of your research along these lines.


   Rich S.

RE: PIC lookup table

rich, I assume your comments about not being to use PCLATH were aimed towards me...

I'm not sure what leads you to believe my method is anything unusable.  The whole idea behind PCLATH is to allow access to the high order byte of the PC counter... as such, changing it is as simple as loading a value in.  I've used it that way in every single program I've written in my 8+ years of PIC'in.

A perfect example is if you intend to modify the PCL for a reltw jump table.  If the PCLATH is set to something other than the current page, you need to modify... if you don't, the PCL modification will put your program counter somewhere in an incorrect page.  Code execution after that is anyone's guess.


RE: PIC lookup table

Hi macgyvers2000 (Electrical)-

"rich, I assume your comments about not being to use PCLATH were aimed towards me..."

No, the statement was to the original poster. Sorry for the confusion. However, I do have a question for you, macgyvers2000?

How do you preload the stack for the retlw return? I'd be interested.  I also deal with the smaller PICs that do not have the flash memory read.

Still seems easier to use the 14 bits of the program word read than going to multiple tables for 8 bits. That way, he can code the "3 4 bit bcd digits" all in one location. Also would use up less code space.  Trade off on time (looking at the 16F77 data sheet) would be just about the same.
Again, this pre-supposes that he has one of the larger 16Fxxx type PICs.

Fortunately, there are many ways to skin a cat.


    Rich S.

RE: PIC lookup table

Thank you too all of you for your help.  I've got the program running in software. Using a main lookup table, which jumps to 1 of 32 small code blocks that simply change pclath to the correct page, and jump to another 32 entry lookup table. This acheives the 1024 values correctly.  Now for some reason the code is not working when programmed to the PIC. I have a feeling it is something to do with the A/d conversion code. But i'm not sure. Any ideas that would prevent code that works in the simulator, to not work on the actual hardware?

RE: PIC lookup table


The stacks are generally 13 bits wide, which means as long as the return is within the same 8k-word space, the retlw statement operates without a hitch.  Things get a little more interesting if the table is larger than 8k.


RE: PIC lookup table

Lookup tables were all the rage when a fast processor had a 2MHz clock.  

They are not the only way to implement a transfer function.

You could just forget the table, and _compute_ the result you need.

Mike Halloran
NOT speaking for
DeAngelo Marine Exhaust Inc.
Ft. Lauderdale, FL, USA

RE: PIC lookup table

LUTs are not the sole domain of slow processors.  What if the data cannot be described by a low-order equation?  Why waste time on certain (simple?) operations (like reversing the bit pattern of a byte) when it could be put to better use?  Relocatable functions and state machines work beautifully using LUTs.

I'm not saying what niick is looking for is complicated, only that LUTs are still (and will most likely always be) quite useful.


RE: PIC lookup table

Hi niick (Electrical)-

Well, there are a couple of schools of thought.  If this is for work, it might be better to invest in a little equipment to help you debug stuff rather than the "midnight engineer"ing approach of adding LEDs and debug code.  

There is an inexpensive ($159.00 US ish) "In Circuit Debugger" ICD2 that resembles an overgrown hocky puck that you connect via USB (or RS232 with an additional $35.00 wall wart) to a windows based PC.  By using RB6,RB7 and the VPP/~MCLR pins on the device (assuming you have met the "qualifying" conditions of the ICSP/debugger (no caps on the VPP/~MCLR line) etc, etc.  You can use the PIC on the board to debug your code with the advantage of really using the A/D converter, real I/O etc, etc. With some of the smaller PICs, you can buy a "header" chip from Microchip which can plug into the PIC socket that has some extra I/O debugging pins on the header to allow all the I/O pins in the socket to be used.

Sometimes it's just better to bite the bullet and invest in a little insturmentation which, in the long run will save the company some money.

Otherwise, debug with the LEDs, test code, logic analyzer, etc.  That works fine, but does not give the visability into the PIC.  Maybe there are some 3rd party debuggers out there that someone else will recommend, but shoot, the time that it take to research, almost eats up the cost from buying the debugger from Microchip.

Hope that this helps.


    Rich S.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


White Paper: Agile Product Engineering and Improved Product Outcomes
Today’s product development cycle is fraught with difficulties. Increased demands for complex functionality and reduced product development windows cause engineering teams to borrow practices from the IT industry, swapping outdated serial workflows for a more flexible and collaborative design method known as Agile Product Engineering. Download Now

Close Box

Join Eng-Tips® Today!

Join your peers on the Internet's largest technical engineering professional community.
It's easy to join and it's free.

Here's Why Members Love Eng-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close