Skip to content

Polynomial data table in memory offers speedy access but adds system cost

Let’s continue our discussion on the challenge of accurately converting thermocouple readings to exact temperatures in the light of microcontrollers (MCUs) such as the Renesas RX. As I covered in an introductory post on the topic, thermocouples don’t offer a linear relationship between temperature and voltage output. Depending on the accuracy requirements of your application, you may need to solve a 5th to 9th order polynomial to get good temperature readings. One alternative is to use brute force and a good math package, and create a conversion table in advance. The table approach offers fast access to temperature data but can greatly increase memory requirements and therefore system costs.

If 10-bit resolution is suitable for your application, the table-based approach might be a good choice. If you have an MCU with a 10-bit ADC (analog to digital converter), then a table with 1024 entries will store the required data (see a sample table below). The ADC count acts as an index to the temperature data.

The memory requirements escalate quickly, however, if you need more resolution or if you have multiple thermocouples or other sensors in a system. To support 12-bit resolution you need a table with 4096 entries and 16-bit solution requires 65k entries.

The actual code required to access the table is negligible in size. Accessing such a table with the RX MCU requires only 8 bytes. Moreover, the table approach is the faster than any of the approaches to calculating the polynomial each time your application needs to read the temperature. With the RX MCU, the table look up would require only 1.5 µsecs.

Still the table size will necessitate the calculated approach in many applications. We discussed code size and memory requirements numerous times here on Doctor Micro. Memory is a major system cost factor. That cost factor led the RX design team to take great care in optimizing the processor design for code density. Moreover, we covered the impact that specific instructions such as BSR, ADD, BEQ, CMP, and MOV have on code density. Huge tables could render those advantages of the RX moot.

If system cost is a key concern, the calculated approach will be best. We’ll cover those fixed- and floating-point options in another post coming soon.

 This blog post was originally published on the Renesas Rulz Doctor Micro blog.

Post a Comment

Your email is never published nor shared.