![]() These methods could easily be applied to 16 and 32 bit platforms the sum-of-reciprocals would probably end up preferable on a platform without hardware multiply (although these days, how many architectures don't offer it?), but otherwise, the boring old polynomial is hard to beat. Not bad, but even a single crude division costs more than four MACs, so it's just not a good approach. I also considered a more creative approximation particular to thermistors of this type (a sum-of-reciprocals form), which took around 420 cycles and 81 words. I consider the latter unsuitable for both size (the minimal table still requires ~40 words) and computation time (the divisions required for a linear interpolation will probably not cost much space, but will take over 400 cycles easily the table lookup also has to be either a linear or binary search, which takes more time, and is variable). I consider the former unsuitable because of its size. The alternative on this particular platform would be a massive 4k word lookup table with a few cycles worth of code to grab it, or a reduced lookup table with linear interpolation. ![]() The math is exact, in that the final result is rounded no worse than a high-precision calculation truncated to the same scale, give or take one LSB. Actual error of a given 1% thermistor will probably be worse than this, so I consider it more than sufficient numerically. The function converts a 12 bit ADC reading to a 12.4 fixed point temperature with < +/- 0.25C error from the manufacturer's typical data. It could be optimized better for either constraint, if desired. Just don't get carried away: standard advice - save the optimization for the end, once you've got a working program, trimmed down, that finally needs it! Anyway, I've written a 7th order polynomial function - for thermistors, not thermocouples - which runs on AVR and doesn't take too much time (around 300 cycles), and little memory (74 words, including the coefficient table I think). Do the hard work and figure out what's actually going on, in the core, down to the bit level if possible! It's hard work, but it's rewarding, and often worthwhile. if at all! If that's the case, then I suggest embracing fixed point. If you think floats and math.h are required for this sort of thing, you're not trying nearly hard enough. I would say it's because I don't need to touch it, except that lately I've noticed the stupid thing locks up sometimes which is rather unfortunate. This makes it fast and compact but difficult to adapt for other people's uses, in fact I couldn't even explain it today because I haven't really touched this since I built it. the voltage reference, ADC resolution, and desired output precision are all baked in so the result is simply a 16-bit LUT (split into two tables) that directly turns an ADC code into a value. For my implementation a great deal of the hardware and processor details are baked in e.g. And each row is annotated with what real-world values it represents. But all it took was a minute or two to add the K-type parameters to the script and out popped an updated lookup table with no copy-paste needed. ![]() In fact I already did, because when I built this project initially I had the brilliant idea to use a J-type thermocouple because it was more sensitive, then quickly found out that the rather small benefits were outweighed by the vastly greater availability of K-type thermocouples for purchase. It's ugly, and I can't believe I wrote any of this PIC assembly as it looks foreign to me now, but it's serviceable and if I needed to change the type of thermocouple it would be trivial to build a new table from the ITS-90 parameters. For example, here's one I did a while back. Consider making a self-contained Python script to generate the table.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |