Look-up table for 16 bit values How-to?

Jim McBride · Joined: 24 Mar 2004 Posts: 21

I have never used a look-up table and can't seem to find any helpful posts to get me the basics. Neither have (yet) I been able to find any direct example code in my "old" compiler sample code.

I need to set and execute 32 different constant delays depending on a 10 bit adc/32. A case statement takes way to long. Would it be possible (faster) to use a look-up table to return a 16 bit constant (or two bytes hi and low) to insert into my delays?

Any samples/links greatly appreciated.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

The Ex_sine.c file has a look-up table in it. They declare it as a byte
table, so change it so it's declared as an 'int16'. Here's the file location:

Jim McBride · Joined: 24 Mar 2004 Posts: 21

Wow, I did not expect the data table would be so easy. But I am not sure if it will work for me.

ide v3.43
pch v3.188
PIC12F675

As you pointed out previously (in another post), my compiler version can handle delay_us(byte) as variable or delay_us(1 - 65536) as constant. I was hoping to put a 16bit constant in there using this code (snippet), but it does not work. See anything wrong or am I out of luck doing it this way with my compiler version?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

But the parameter is not a constant. The compiler doesn't know the
delay value at compile-time. It doesn't qualify as a 16-bit constant.

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

I'd like to refer to PCM Programmer's previous postings of long delay routines with a variable parameter (16-bit).

long_delay_us():
http://www.ccsinfo.com/forum/viewtopic.php?t=16656

long_delay_ms():
http://www.ccsinfo.com/forum/viewtopic.php?t=375

Jim McBride · Joined: 24 Mar 2004 Posts: 21

I guess that makes sense, bummer. Lets go about this from a different angle. I want 32 different delays ranging from 10hZ to 7kHz. A case statement takes longer and longer to get to the last case and 7kHz is not possible. Currently, case zero is my longest delay and case 31 is my shortest. One possibility would be to reverse the logic and put the shorter delays first. Do you see any other way of jumping to 32 different constant delay options?

Jim McBride · Joined: 24 Mar 2004 Posts: 21

Thank you ckielstra,
I have looked and thought about that but unless I am just missing something, it does not solve my problem.
Long delays are not a problem, I can use delay_ms(byte).
It is the really short delays that are killing me. Anything fancy I try to do kills me with the overhead.

In a loop that is capable of running up to 7khz (~143uS) I have to read in an ADC, pulse a pin to a frequency determined by the ADC as well as ramp up to and down from that frequency from zero. (All running at 4Mhz) This is easily done with a home brewed delay as a while() loop but the relationship between the ADC number and the frequency is logarithmic. I don't have enough time in the loop to do that math, so I chop it up into 32 "set" delays that follow the scale needed. I just can't figure out how to test for and get to the individual delays fast enough.
Any ideas?

collink · Joined: 08 Jan 2010 Posts: 137 Location: Michigan

Jim McBride · Joined: 24 Mar 2004 Posts: 21

You have me thinking in a new direction. Well actually two old directions, that for individual reasons, failed, but might work combined.

Delay_time being used in a while(x){x--;} loop delay?

The ramp is a little tricky. It is logarithmic as well. ie the delay time for a delay that is 10Hz needs to drop off much quicker than one for 5kHz. Otherwise the slower the pulses come, the longer it takes to slow down/speed up to the targeted speed. I should be able to combine two paired Lookup tables, one for delay_time and one for step (gain).

Thanks for helping me get unstuck, back to bangin' on duh keyboard....