PIC lookup table

[niick]

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!

-Nick

 

[IRstuff]

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?

TTFN

 

[niick]

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.

 

[Madcow]

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

 

[IRstuff]

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.

TTFN

 

[MacGyverS2000]

nick,

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.

Dan
Owner

http://www.Hi-TecDesigns.com

 

[MacGyverS2000]

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).

Dan
Owner

http://www.Hi-TecDesigns.com

 

[richs]

Hi-

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.

Cheers,

Rich S.

 

[MacGyverS2000]

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.


Dan
Owner

http://www.Hi-TecDesigns.com

 

[richs]

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.

Cheers,

Rich S.

 

[niick]

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?

 

[MacGyverS2000]

rich,

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.


Dan
Owner

http://www.Hi-TecDesigns.com

 

[MikeHalloran]

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

 

[MacGyverS2000]

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.


Dan
Owner

http://www.Hi-TecDesigns.com

 

[richs]

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.

Cheers,

Rich S.