# MPLAB-X Impressions

This post is a change of pace from the previous ones. We’re going to step back and take a look at the development environment that I use in my current work. I speak of the  Microchip MPLAB-X (V1.00) IDE. I will cover the compiler I currently use, C32 (V2.01) at another time. MPLAB-X is Microchip’s new flagship IDE for PIC development tasks of all sorts. I first learned of MPLAB-X about a year ago while it was still in early beta. I confess that Betaphobia (not to be confused with Cetaphobia) ruled and I stayed away from it. However, all was not lost; I got to use MPLAB-X at last years Master’s Conference where I have to admit I was most impressed. After the conference, I switched to it, in spite of the fact that it was still in beta.

So some basics first: It’s free! Just download V1.00 and install. Yes, it’s a dreaded V1.00, but more on that later. I have long since taken advantage of the extensive customization capability, so while my MPLAB-X looks like this, your’s won’t unless you share my need to see as many lines of source code at once as possible:

The MPLAB-X IDE as configured by me.

MPLAB-X is a full featured IDE designed to integrate with a wide variety of compilers and development tools for the full line of Microchip products. There is so much much ground to cover that this is not so much a review as my impressions. One really good bit of news is that MPLAB-X is based on the open Net Beans IDE. I look forward to being able to develop and make available my own special pluggins. As with most IDEs it comes with project management, source code editing, project building, and debugging capabilities. Nice extras are even though it supports popular source code control systems, it also supports revision tracking on the local machine. Right out of the “box” when started, MPLAB-X displays a most helpful start-up page:

The Start Up page. Not just a nuisance!

In the Learn and Discover Tab you find Getting Started  material, Tutorials, a number of helpful Wizards, and links to community and support. While there is a tendency to skip over this page, You shouldn’t as it contains valuable information. I like to at least glance at it before moving on to my code.

Once into the development environment it is pleasant and easy to use. The editor includes many of the conveniences of modern editors such as color syntax, symbol and error highlighting, auto look up and completion of symbol names, code re-factoring, code navigation, and text formatting. The editing environment is a joy to use and I won’t go back to the old MPLAB, however I did run into one glitch here though. I noticed that sometimes when I entered a symbol, the editor would add a redundant include directive to the code. Apparently, the editor had lost track of the fact that the file was already included elsewhere.

To fix this, I unchecked the “Auto Insert #include Directives for Completed Identifiers: option under Tools -> Options -> Editor Tab -> Language Selection -> C++. See the illustration for the view at the end of this rather laborious menu navigation challenge. Once unchecked, the phantom include directives ended, but I was again responsible for adding them myself, which suits me just fine.

.

A sample call tree from my Trivial File System module.

Also present in MPLAB-X are some superb features to enhance code understanding.The call tree graph is especially useful in studying code that you did not write. What does this function call and where do the calls go is usually a very tiresome exercise. With the call tree, it’s simple to get great looking graphs like the sample to the left. These graphs also make great documentation for internal system specifications or for impressing peers, managers and pets. Well maybe not pets, they’re much more difficult to impress.

A major area where MPLAB-X shines is that of build management. The old MPLAB had only one build configuration per project.

Under MPLAB-X a single project can command multiple build configurations with different source files selected, preprocessor symbols defined and different compile and link options. All of this being very customizable in this easy to use dialog shown to the left:

In addition, if you select a file in the project tab, and right click for the menu and select properties, you are given a dialog that allows you exclude that file from the build or use build options different from the other files.

This is shown to the left. There is one fly in the ointment here. If you have set a great many paths and other options up, you will have to redo all of that effort for the exception file. It would be nice and save a lot of time, if the exception file started off with the same options it would have had as a regular file.

The final major area I want to touch upon is the debugger. MPLAB-X comes with an integrated debugger with all the usual features we’ve come to expect: The call stack, watch windows, breakpoints, memory and register windows, plus single stepping of all kinds and flavors. Now my experiences are based on my use of MPLAB-X with my ICD-3, and I must say that this is the weakest link of the MPLAB-X package.

For starters, the ICD-3 drivers seems to get lost every once in a while. Once lost, the only answer is to use the little MPLAB-X driver switcher utility to bring the ICD-3 back as an MPLAB-X device. This also happens if you are debugging and walk away in debug mode for a long while. On return the debugger will not exit. Again to recover, exit MPLAB-X and run the driver switcher to correct this. I suspect that Windows 7 maybe interfering and reverting to old drivers because it feels like it, but I can’t say one way other the other. Anyway you look at it, this does not auger well for long debug testing.

Earlier betas of MPLAB-X had severe problems with watch windows being unable to locate local variables, but those issues seem to have been sorted out in V1.00. A constant problem with advanced processors such as the PIC32 is the need to remember to turn off the optimizer for debugging. The optimizer completely scrambles the relationship between source code lines and machine language instructions to the point that single stepping seems to jump around the code randomly. This can be a problem if code space is tight, because unoptimized code is much bulkier. The answer is to compile most of the files optimized with only the file under test unoptimized.

I realize that my look at MPLAB-X has been far too brief to give any idea of the real flavor of the tool in use. I can say in summary that I am very glad I decided to make the leap of faith and give it a try. Even the little problems I encountered were opportunities to learn and improve my skills and for a V1.00 it’s pretty nice today. So my advice is to plunk down the \$0.00 (after getting budget approval of course) and give MPLAB-X a try. I’m pretty sure you’ll like it!

Peter Camilleri (aka Squidly Jones)

# Touch Screen Calibration

As promised, we’re going to take a look at the calibration of resistive touch screens. If you need to brush up on touch screen basics, take a look at Touch Screen 101 first. When configured correctly, the touch screen outputs a voltage that corresponds to the position the touch location in the X axis and another voltage that corresponds to the voltage in the Y axis. For the X axis this might look something like this:

Touch Screen Response

A lower voltage $X_L$ is output when the touch’s X location is near the left edge of the screen, and $X_U$ is output for the right edge. In between the edges, the voltage is  between $X_L$ and $X_U$ and linearly proportional to the touch position. Thus for a given voltage read, determining where the touch occurred is handled by the simple equation:

$X = 320\frac{(X_{Read}-X_L)}{(X_U-X_L)}$

Now for this all to work well, all we need to do is to establish the limits $X_L$ and $X_U$. It turns out that this is not as simple as you might think. I went through a number of iterations on this. Here’s a summary:

# Plan A

My first idea was to try to measure $X_L$ and $X_U$ directly. If the user sweeps their touch off of the four edges of the screen, then at some point, we should read $X_U$ and $X_L$ as the current touch point. $X_L$ should be the lowest voltage we detect while the screen is touched and $X_U$ should be the highest one. The same applies for $Y_L$ and $Y_U$. Initially, “safe” values are used as limits that are greater than the lower limits and less than the upper limits and avoids non-sense like dividing by zero. The basic idea here looked something like this:

$Initialization: X_U = X_{Upper Safe Value}, X_L = X_{Lower Safe Value}$

$X_U = max(X_U, X_{Read})$ and $X_L = min(X_L, X_{Read})$

With similar code for the Y axis. And the code worked! Or at least the code seemed to work. Then I began noticing some problems. Sometimes the calibration routine would produce a limit that was too small causing the X,Y coordinate to be in error one way and sometimes it be too large causing an error the other way. It soon became apparent what was causing the problem. It seemed that the resistive touch screen’s noise level increases quite dramatically near the edges. This was then used to generate the limits (with noisy data) causing all parts of the touch screen to be inaccurate.

At first I thought I could just filter out the noise but it proved to be more difficult to resolve than that. It seemed that the touch data near the edges of the screen were just plain unreliable. Finally I had to conclude that you can’t calibrate with this noisy data; the results will always be disappointing.

# Plan B

At this point I remembered that most touch screen calibration that I have seen place targets for the user to touch. These targets are not at the edge of the screen, but offset slightly in from the edge. In a flash, I saw what must be at work here. By retreating from the edge of the display, the quality of the data is greatly enhanced. The only problem is that the data is not the data we want.

This is shown in this diagram. Here the target has been inset 15 pixels from the left margin. The voltage we read in is $X_C$ and not what we want which is $X_L$. What we need here is to revisit the math classes of our youth and use some plain old linear algebra to do some linear extrapolation! We can see that the line from (0, $X_L$) to (319, $X_U$) has the same slope as the line from (15, $X_C$) to (319, $X_U$). The slope of a line is the rise over the run, so applying this to both lines we get:

$\frac{X_U-X_L}{320} = \frac{X_U-X_C}{305}$

So let’s solve for $X_L$

$X_U-X_L = \frac{320}{305}(X_U-X_C)$  – multiply by 320

$X_L-X_U = -\frac{320}{305}(X_U-X_C)$  – multiply by -1

$X_L = X_U-\frac{320}{305}(X_U-X_C)$  – add $X_U$ to both sides

$X_L = X_U-\frac{64}{61}(X_U-X_C)$  – reduce the fraction

Now there are a few loose ends in all this that you may have noticed. For starters, $X_U$ needs to be determined too. This approach deals with this in the following manner. Like Plan A above, all four limit values are given “safe” initial values. As the user press the various targets, the appropriate limits get updated. Even with poor limits, we can determine which corner the user touched and thus know which limit to update.

This approach gave much better and more accurate results than plan A ever did. Still there were lingering issues to be resolved:

1. A place was needed to store these parameters otherwise calibration would be needed every time the unit was powered up. Due to a design choice in the MMB32 hardware, going to “sleep” and keeping the results in RAM was not a real option.
2. The calibration is iterative. Updating one limits means that when the other limit is re-tested, a newer, better result is obtained. This means that the user must repeat each calibration point until “enough” accuracy can be obtained. How much is enough? Who can tell?

Issue 1 was handled by coming up with a way to utilize the M25P80 SPI flash device on the MMB32 in such a way as to NOT be hideously slow, or rapidly wear out the device and is the topic of a future article.

Issue 2 will be handled by a revamped calibration method “Plan C” coming soon!

Peter Camilleri (aka Squidly Jones)