|
|
View previous topic :: View next topic |
Author |
Message |
future
Joined: 14 May 2004 Posts: 330
|
how would you implement(read) a 256 byte table? |
Posted: Mon Jul 26, 2004 3:44 pm |
|
|
I am using byte const kpa[256] to convert from a/d reading to pressure...
Looking at the simulator log I saw a lot of code just to read this table.
Does someone have a better/faster way?
Maybe a #rom int8.. I did a search but the results that appears to have something useful are from the old forum... unreachable. |
|
|
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Mon Jul 26, 2004 4:41 pm |
|
|
Code: |
/* Table of CRC values for high order byte */
char Table_CRC_Hi[256] = { // A global stored in RAM is faster than a constant by 50%
//const char Table_CRC_Hi[256] = {
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01,
0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0,
0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01,
0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81, 0x40, 0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41,
0x00, 0xC1, 0x81, 0x40, 0x01, 0xC0, 0x80, 0x41, 0x01, 0xC0, 0x80, 0x41, 0x00, 0xC1, 0x81,
0x40
} ;
|
|
|
|
future
Joined: 14 May 2004 Posts: 330
|
|
Posted: Mon Jul 26, 2004 6:44 pm |
|
|
Neutone, thank you for the reply.
I use the same way to do the conversion, if you look at the generated code for this table lookup you will see that it is big, and this is what I am complaining.
I am looking for a way to optimize it using tables, program reads, pointers or other method that I dont know yet. |
|
|
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Mon Jul 26, 2004 9:33 pm |
|
|
The line that is commented out is a table lookup. The other line uses RAM and runs much faster. I don't think there is a faster method than a table stored in RAM. |
|
|
Ttelmah Guest
|
Re: how would you implement(read) a 256 byte table? |
Posted: Tue Jul 27, 2004 3:25 am |
|
|
future wrote: | I am using byte const kpa[256] to convert from a/d reading to pressure...
Looking at the simulator log I saw a lot of code just to read this table.
Does someone have a better/faster way?
Maybe a #rom int8.. I did a search but the results that appears to have something useful are from the old forum... unreachable. |
The comment 'what do you expect', comes to mind!...
The Harvard architecture of the PIC, prevents direct reading/writing of the program memory. On the older chips, the only way round this, was the RETLW instruction, so to fetch a byte from the ROM, involved adding the location as an offset to the program counter, then calling that address, which returned the value.
The newer chips, instead have the 'table read' instruction, which allows a byte to be fetched, but you still have to calculate the address involved (adding your offset number to the location of the start of the array), transfer this value into the table address registers, and fetch the byte. The total time involved is not large (typically about fourteen instructions), but is inherent in the chips architecture.
It is _slightly_ faster to fetch a value from RAM, but even here, if this is from a location addressed by a variable, the same arithmetic is needed to calculate the real address (gives about twelve instructions needed), and then the indirect addressing register is used to fetch the value. Values stored in RAM though are massively faster when addressed uing a constant. So:
val=array[1];
Will result in the immediate transfer using a single instruction from the defined address. However the same operation from ROM, still has to incur the overhead of the table fetch.
Best Wishes |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Tue Jul 27, 2004 9:37 am |
|
|
Of course you can do it smaller with a polynomial, but it will be slower and less accurate (unless you used a polynomial to generate the table).
What is the application? I have done several pressure measurement systems, mostly high accuracy. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
future
Joined: 14 May 2004 Posts: 330
|
|
Posted: Tue Jul 27, 2004 4:46 pm |
|
|
I'm doing an automotive application, I use it to convert the manifold absolute pressure (MAP) to kilopascals.
The map sensors outputs almost 0~5volts for 0~100kpa |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Wed Jul 28, 2004 7:20 am |
|
|
It sounds like you could get away with a simple 2 term formula, y=mx+b.
With any decent sensor this will give you better than 1% accuracy with only one multiplication and one addition in fixed point math.
Put your data points into a spreadsheet and find the best fit slope and offset numbers. Those become m and b in the formula.
If you need accuracy better than the linearity of your sensor and A/D you may have to add another term, y=ax^2+mx+b. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|