Help creating large 'float' lookup table

[Burt Poppenga]

Hello,

I am using PCM 3.136 and a 16F877. I would like to create a large lookup table of float values in ROM at compile time and then access them at run time. For example:

const float LU_TABLE[2][356] = {
{9.627,9.645, ...},
{9.665,9.686, ...}};

Arrays of this size don't work, but I have read other threads that show the use of #rom. I would like to make sure that this area of ROM isn't used by other stuff (like #org does).

Any suggestions?

Thanks,
Burt
___________________________
This message was ported from CCS's old forum
Original Post ID: 10807

[PCM programmer]

:=Hello,
:=
:=I am using PCM 3.136 and a 16F877. I would like to create a large
lookup table of float values in ROM at compile time and then access them
at run time.
---------------------------------------------------

Here is one method:

[Burt Poppenga]

Many thanks for the reply.

So in a nutshell you are suggesting breaking up the large table into smaller tables that can be handled. If each ROM location is 16 bits, then does each entry of:

float const ROM_TABLE_x[] = { 12.4747, ...

end up consuming two rom locations (for the 32 bit float)? If so, I was thinking about using fixed point to encode my data to save ROM space (my data would fit into an 8.8 fixed point number). Does anyone already have CCS C routines to convert:

8.8 fixed -> float
S.7.8 fixed (signed) -> float
float -> 8.8 fixed
float -> S.7.8 fixed


Thanks again,
Burt
___________________________
This message was ported from CCS's old forum
Original Post ID: 10826

[PCM programmer]

:=So in a nutshell you are suggesting breaking up the large table into smaller tables that can be handled. If each ROM location is 16 bits, then does each entry of:
:=
:= float const ROM_TABLE_x[] = { 12.4747, ...
:=
:=end up consuming two rom locations (for the 32 bit float)? If so, I was thinking about using fixed point to encode my data to save ROM space (my data would fit into an 8.8 fixed point number). Does anyone already have CCS C routines to convert:
:=
:= 8.8 fixed -> float
:= S.7.8 fixed (signed) -> float
:= float -> 8.8 fixed
:= float -> S.7.8 fixed
--------------------------------------------------------

On a 16F877, each ROM location is not 16 bits -- it's actually
only 14 bits. In the code that I posted, the compiler puts
a RETLW instruction in each ROM location. The CCS floating
point format uses 4 bytes per float, so that's 4 ROM locations
per entry in the tables.

If you want to pack data into the ROM using all 14 bits, you
can't use RETLW. You'll need to use the read_program_eeprom()
function. Here's an example of that (using text strings):
http://www.ccsinfo.com/forum/viewtopic.php?t=7971

If you need 16 bits, you'll need to go to the 18Fxxx series
processors.

Tell us what your overall goal is. There might be people on
here who could let you know about a better way to do it than
by using float tables.
---------
Edited on Feb 4, 2005:
Corrected the link so it points to the correct article, instead of
giving a "404" error. When this post was ported from the old
CCS forum to this new one, all of the embedded links were broken.
___________________________
This message was ported from CCS's old forum
Original Post ID: 10828

[Burt Poppenga]

I have an application that has a sensor hanging off the A/D converter. Based on the sensor reading and configuration of the application, I need to look up a floating point value to complete some computations. As it turns out, I can get away without using floating point numbers (I can use a form of fixed point, and 14 bits is just barely enough).

So I need to have 4 tables, each with approximately 300 entries (longs, where only 14 bits are used).

I can't really go the route of:
#ORG 0x1800, 0xXXX
const int16 ZN_1[300] = {
963,964,966,969,971,973,976,979, ... };

Because the array is just too long (and I don't really want to break up the tables).

So I tried to go this way:
#define ZN_1 0x1800
#ROM ZN_1 = {
963,964,966,969,971,973,976,979,982, ... }

But I am afraid that bad things could happen because the ROM area is not reserved by the compiler. So I tried:
#RESERVE 0x1800:0x1FFF

Right after my #ROM. This caused complier errors in some pretty strange places.

Any help would be great!

Burt
___________________________
This message was ported from CCS's old forum
Original Post ID: 10843

[PCM programmer]

:=So I tried to go this way:
:= #define ZN_1 0x1800
:= #ROM ZN_1 = {
:= 963,964,966,969,971,973,976,979,982, ... }
:=
:=But I am afraid that bad things could happen because the ROM area is not reserved by the compiler. So I tried:
:= #RESERVE 0x1800:0x1FFF
:=
:=Right after my #ROM. This caused complier errors in some pretty strange places.
------------------------------------------------------------
#reserve is used for RAM. You have to use #org for ROM.

The following code works. To see the ROM values, compile
the code, then go to the Window menu in MPLAB, and select
"Program Memory". Scroll down to hex address 0x1800 and
you'll see the data. (It's not shown in the .LST file)

#org 0x1800, 0x1FFF {}
#define ZN_1 0x1800
#ROM ZN_1 = {963,964,966,969,971,973,976,979,982}

___________________________
This message was ported from CCS's old forum
Original Post ID: 10861

[Burt Poppenga]

Many thanks ... works like a dream!
___________________________
This message was ported from CCS's old forum
Original Post ID: 10872

[little_angel]

IF i use PIC18 series this method working ?

Example: i wan to display float that contained "-"
-0.3
-1.147
-1.298

I declared with

[Ttelmah]

256 float values, need 0x400 bytes....

Best Wishes