If I Had a Hammer

I did want to add a small note for the selection of the units for angle and ratio.

Both of these are working on my conceptual approach of "thinking like a computer".

People use degrees or radians for angular measurements, computers don't really know the difference, if the radian is conceptualized as pi * a value for units, then altering the number system slightly affords the ability to make 2*2¹⁴ instead of 2*pi. Then because a 16 bit integer offers +/- for direction of rotation 2¹⁵ is used to represent 2pi. The other advantage of this is independent of + or - of angles, location is determined by simply masking off the highest bit. Try it with a few operations. Another added benefit will be presented in a future installment.

For ratio, this is simple because if you multiply by a ratio, you need to round and divide out the remainder in order to get back to a whole number portion. Using a power of 2 to represent 100% means, the divide instruction compiles to a right shift logical. In this case 10 bits. Also, rounding can be easily implemented by adding 512 (b0000000100000000) before the shift.

Because pressure and temperature are on opposite sides of my favorite pV=nRT the fact that both are multiplied by 100 provides self canceling.

Just thought I would explain,

Jack

Needed to say something about tables versus formulas. For real time systems, tables always win.

• Given a non-linear curve where Y=f(x) and x is a measured value, the value at any point can be calculated using the function f(x)
• For simple linear equations accuracy is high and calculation can be performed simply with a single multiply and add
• For complex equations, accuracy becomes an issue, and the calculation can become difficult and time consuming.

• For short ranges, a linear interpolation can be used for a close approximation, but this becomes highly inaccurate outside a specified range

• Using fundamental calculus, if the range of delta X is distributed evenly, the linear interpolation between any two points more closely approximates any curve
• If greater accuracy is required the number of sections can be increased

• By producing a table of these values, the equation becomes simple for any value X_n where X_n is between X_a and X_b
• The equation becomes:

   ƒ (X)=Ya+(((Yb−Ya)·(Xb−Xn))(Xb−Xa) )

...lost one of the diagrams

Hi Jack,

I completely agree about tables.

They are very fast, good enough and you can do approximation between values if you need them

Back when I was programming 8085 processors, I built a single table that enabled me to do sine and cosine very quickly from the same table.

The time savings was immense, providing answers in a dozen microseconds verses using a math coprocessor that took milliseconds.

When I build an integrated avionics simulator, I used tables for most functions and the run time result was very nice as opposed to trying to replicate all of the functions dynamically.

Tables rule!

If you look inside any real time game, you will find tables everywhere.

DAB

I once had to calculate humidex in an 8-bit PIC microcontroller using the following formula - without using floating point:

Yup, that got turned into a look up table faster than you can say "Holy Excel spreadsheet, Batman!"

DAB , I probably built the exact same table.  I was going to provide it as another installment for tips and tricks.

If you build a 1/4 wave table using the binary radians that I described earlier, where 2pi = 215, bits 14 and 15 get used for determining the quadrant, and bits 0 through 13 get used for the table lookup.

The other trick to use is cos(n) = sin(n+8192) so everything comes out of the same table lookup.

if bit 15 == 1, return the negative value

if bit 14 == 1, use 8192 - n so the table reads backward.

One simple, but effective advice could be "learn to use spreadsheets and make graphs from them".

I used Excel in practically all sensor applications, before implementing the formula to a microcontroller, just to check that the raw output values make sense to what is measured.

• Recently I created a simple altimeter (hobbyist project) using an absolute pressure sensor. The barometric formula looks pretty hard to be calculated by a microcontroller:

or

However, using Excel, I found out that for a +/- 1000 m of altitude deviation is the pressure change ca. 11 Pa per 1 meter.

One integer subtraction and an integer division is much simpler, even after considering the computation error.

• Excel is also powerful to draw various graphs, calculate missing values and provide functions' approximations. This is especially useful when working with sensors that need to be calibrated (or were factory calibrated).

The following graph shows an example of a function providing relative humidity value from  HTS221HTS221 sensor's raw output(using two calibration values It also shows that the sensors I have on my table are linear but the slope is a bit different And last but not least that the higher is the sensors output value the lower is the relative humidity(Please excuse the missing labels it was just a quick graph to demonstrate the point X axis shows relative humidity in rH Y axis shows an 16-bit signed output from the sensor

More information on how you did this would be great. Sounds like a greatly useful skill to have but not something a lot of us do have.

Kas

Hi kas.lewis

The process is part of a table lookup routine that I have in my toolbox. The process treats all tables as an NxM array, where N is the width and M is the height. The linkage to the data is done using a getter function so the data store can be abstracted.

The function passes X as a parameter of f(x). Because N is the width of the table, there are N elements in the array of equal spacing the max value for X is defined during design. For most cases in my work, I use the ratio element (described earlier) 1024. The delta (spacing between elements) can now be determined as dX = 1024/N.

The operation now needs two components, Xi which is the index into the table, and Xo witch is the offset from the index. The two values are obtained with the two operators, integer divide, and integer mod (remainder after division).

Xi = x / dX;

Xo = x % dX

The getter function is called Z0 = getCal(table, x, y) using parameters of a table accessor, and the x and y indexes the function returns the content of the element (data type is determined by design).

The operation requires the indexed value and the next value in sequence or x(n) and x(n+1). However, if the table is N units the indexes only go from 0 to N-1, but if the divide operation returns N-1, N, which is the next element, is beyond the end of the array. To account for this, a linear extension is performed:

Z0 = getCal(table, Xi, y),

Z1 = Z0 + Z0 - getCal(table, (Xi - 1), y)

but for most cases it is simply Xi and (Xi + 1)

Last, the interpolation is done as described before, this time with the defined variables  Z0+(((Z1−Z0)·Xo)dX )

Hi Instructorman

I like the discussion of the baro sensor being used for altitude. The equations are good, and show step one of the process of developing an application. My intent of this forum was to provide tools and techniques to share with others in problem solving. So if you could, because you mentioned running into some hitches while working with standard packages like Excel, it would be extremely helpful if you would discuss what you did to overcome the issue in developing the embedded solution.

I can understand how a complex operation with  e^x  and complex powers can become involved, especially with smaller processors that don't have floating point hardware. I have to perform pH conversion in many of the functions for our system, so I understand the headaches of dealing with log and anti-log operations.

So if you would be so kind as to expound on the tricks that got you to a final solution, that would prove helpful to the group.

Thank you,

Jack