Carlos Vidales presented the principles behind touch-screen calibration in the June 2002 issue (“How to Calibrate Touch Screens,” p. 32), but his proposed calculation was, as he states, not optimized. Let's take a few steps toward optimizing it.
First, choose the calibration points each near a corner of the screen rather than putting two of them at the midpoints of two sides. That makes a bigger triangle and leads to better accuracy. It also makes a pair of display X coordinates and a pair of display Y coordinates at least nearly equal.
Don't let that near-equality worry you; it's better that way. In fact, exactly equal is better yet-it simplifies the equations. For instance, let's put (X2, Y2) in the lower left corner and make X1 = X2 and Y0 = Y2. This makes the second term in the expression for K the product of two small quantities. That product can be ignored for small angular misalignments.
One term in each of the expressions for A, B, D, and E now contains an exact zero factor, so those terms drop out. Now the calculation has only half as many terms as before, and we have not yet needed to represent a number larger than the product of A/D converter and display precision. Ordinarily, three bytes will do. We can improve on the article's expressions for C and F by using the now-known values of A, B, D, and E in two of the original equations. For instance, we can solve Equation 10c for C as C = XD2 — A * X2 — B * Y2, again only requiring double precison. Actually, a little cleverness will let us re-use the routine in sample.c to simultaneously do that calculation and the corresponding one for F. I leave that trick as an exercise for the reader.
Northwest Marine Technology
Carlos Vidales responds:
The article's comment about the calculations not being optimized referred to the actual software implementation. The purpose of the source code was to show all the important implementation details. There certainly are more efficient ways to implement the algorithm. That optimization is a numerical methods problem beyond the scope of the original article.
The suggestion that the points be chosen near the corners for a larger triangle, better accuracy, and a simpler set of equations may result in overflow and/or roundoff errors, and is not recommended for the general case. The location of the points suggested in the article helps avoid computational errors by keeping the size of all terms roughly within the same order of magnitude while providing non-redundant data to the algorithm.
In particular cases, it is valid to ignore small angular misalignments, but the assertion of the article is that touch screens generally suffer from scaling, translation, and rotation errors. In the general case, none of the three error types is negligible; errors may be small but not always negligible. The assumption that errors due to rotation can be small and negligible is increasingly invalid as the screen and/or its resolution grow. Manufacturing processes minimize all errors, but the solution proposed allows for looser manufacturing tolerances in all cases.
The problem can be simplified somewhat as Phil suggests. For example, two points are sufficient when only two sources of error exist. In that case, let those two points be at opposite extremes for the highest accuracy. It's up to the engineer to determine what simplifications of the general design are reasonable.
A for Ada?
I am writing in response to “Is C Passing,” (June 2002, p. 7) by Michael Barr. It is instructive to note that for really safety-critical applications, two major corporations made the decision, based solely on business criteria, to use Ada. The companies are Boeing and Airbus, and the applications involve fly-by-wire software for commercial airliners. It is also instructive to note that the MISRA C guidelines recommend the use of Ada or Modula-2 when possible.
Additional information about the advantages of Ada over C are available from www.AdaIC.org. Of particular interest might be a paper by Rational comparing the use of Ada and C to produce Ada compilers and associated tools, which is based on extensive data collected from similar long-term projects in the two languages.
I agree with the assessment that language is a small part of what is needed to develop high quality software. It has been shown repeatedly that developers vary in effectiveness by more than an order of magnitude. The only real solution to poor quality software is to identify the highly effective developers and give them the authority, responsibility, resources, and freedom to design software systems. This has the unfortunate effect of relegating the rest of the developers to coding well-specified subprograms. Given that managers tend to behave as if they believe that anyone who can write a “Hello World” program is qualified to design major software systems, this seems unlikely to happen.
PragmAda Software Engineering
What's on your mind?
Embedded Systems Programming welcomes feedback. Please send any comments to editor-in-chief Michael Barr at . Letters to the editor will be considered for publication in any and all media unless the writer requests otherwise. They may be edited for clarity and length.