Erik,

I agree with Chris - lookup tables are probably the right solution. Read back to our discussion on speedometers and techniques to look up values.

What you want is T=f(R) for A,B constant.

As you know, the function above in nonlinear. Some of the ADC resolution will be of diminished value. What you need to do is think about your temperature display resolution and work the problem backwards in a spreadsheet program.

Create a column in your spreadsheet for all the possible temperature display values. {example: 00.0 to 99.9} If you were doing a bargraph, these would be your different class names. For each class, you want to know the equivalent resistance value R that is the maximum value associated with that display class. What this does is reduce your pre-calculated table to the size possible with your display. Even if you carefully did the calculation the hard and slow way, you've still got to round off to fit it on your display character width. This process starts with that roundoff and uses the spreadsheet to calculate the highest R reading that would trigger that display class.

For the example {00.0 to 99.9} there are only 1000 (bump to 1024) possible display classes. If you calculate the maximum limit R for each display class to a 16bit value expected from your ADC... all that is required is to organize the 2048 bytes into a binary search structure with implied addressing (i.e. no need to use tree node pointers on a static and complete binary tree.)

Now your problem is to take a R reading and use a binary search to locate the associated display class. Its very very fast.

Binary searches divide the feasible set of answers in half at every comparison. With just 10 comparisons of R to table values, you can determine the proper temperature readout.

The runtime is maybe quicker that one 16 by 16 divide.

Most people's first impression is that this technique loses accuracy. That would be wrong as the search values can be 16bits, 24bits or whatever... the only loss is the display resolution of your display. If you need many decimal points this might not be the right technique but then again you may be kidding yourself that they sensor is capable of that much accuracy anyway.

Another nice thing about the table is that you can build in the round-off associated with non-linear functions through the spreadsheet formula. This makes it a little more accurate than microcontrol roundoffs which are usually assumed to be linear and binary.

If you want to support C and F, you merely have two tables and the lookup routine starts with the address of the selected table.

My last use of this technique took a 32bit fixed format floating point value, chopped it to 24bits since the display didn't require the full calculated resolution, and ran that through a table sized 1024x3. I think I did it all without using the DPTR which I seldom code with, preferring instead @r0 and @r1. Before someone tries corrects me, yes it requires a clever trick to traverse the table thus. :)

aka J

PS: I use this technique a lot and have mastered its setup inside a spreadsheet. Its tricky to do all this efficiently but if your company is in a rush, throw money at me and I can code it real quick with the tables strategically organized for maximum speed. I don't need the money and I'm not cheap, I just don't want to be swamped by requests to do student's programming projects again. :)

I'd also suggest you check your final table implementation by putting a monitor program in your 8051 and write a PC program to submit all possible R values and read back the 8051's corresponding T value. It might save you an embarrasing product recall.