# Touch Screen 101

When looking at the mikromedia for PIC32 development board, the most striking feature is the QVGA display. Programming the display will be the topic of many posts I’m sure. The second most prominent thing is the fact that it’s a touch screen display. The touch screen is the sole user input device provided, so getting it working is vital.

I had originally intended to go directly to the subject of touch screen calibration, but I figured it would be wise to take a look at the basics of the touch screen we’ll be working with. The provided touch screen is one of the simpler types. It’s known as a four wire resistive touch sensor. This sensor overlays the display with two clear conductive films separated by an air gap. When the screen is touched, the two layers are brought together and a position can be determined. The general hookup is as follows:

In typical operation, the sensor toggles between two states: measure Y and measure X. These are shown below:

In measure Y mode, the PIC port pins are used to generate a voltage gradient across one surface while the analog to digital converter is used to read the voltage present on the other surface. In measure X mode, the roles of the surfaces are reversed. Now assume for now that the sensor is currently in measure Y mode and it is being touched. What sort of voltage are we going to measure? Let’s take a look at the equivalent circuit for a moment:

Under ideal circumstances, Y1 and Y2 form a voltage divider and the output can be computed simply as :

$V_O = 3.3_V \frac{Y_2}{Y_1+Y_2}$

Alas, things are not ideal. Parasitic resistances and leakage currents all conspire to make it very difficult to predict the output voltage ahead of time. Consider the following more complete equation but still highly simplified:

$V_O = 3.3_V \frac{Y_2+P_2}{Y_1+P_1+Y_2+P_2}+I_L(X_1+P_3)$

Most of the values (eg: $P_n, I_L$) in the equation are unknown, uncontrolled, or parasitic values. Without some way for taking these terms into account, there is simply no way to make the touch sensor accurate enough to be useful. That is why it is so important that resistive touch screens be calibrated. The calibration process is used to determine the macro system behavior of all the unknown, manufacturing, and batch sensitive parameters. And that is our next topic!

Peter Camilleri (aka Squidly Jones)

# Errata errata!

To paraphrase (poorly): A funny thing happened on the way to the blog! This article was to have been about the interesting (really!) topic of calibrating a touch screen and some of the unusual twists and subtleties involved with that process. Along the way though, something came up: Errata!

In working on my code, it occurred to me to check to see if there were any errata outstanding on the PIC32MX460F512L processor I was using. I was a little alarmed to find no less than 68 errata items for this chip. I really should not have been. Given the incredible complexity of the part, it should be off no surprise that 68 defects could be found, and most of them were very obscure. One point did catch my eye however. Here it is from the Microchip docs:

Not to get too detailed at this point, but my code fell exactly into the above scenario. I constantly switch between 2 pins to output to generate a voltage slope while the other 2 pins are analog inputs to read the voltage. Since the issue and its fix were from the maker of the chip, I felt safe adding it to my code, even though it seemed to be working fine already. As instructed, I added code to set the pins to “0” before setting them as inputs and patted myself on the back and went on to other parts of the code.

Until it came time for testing… Suddenly, my well behaved code was totally flaky! While touching the screen solidly, the code was reporting numerous make and break events that were not real. To make matters worse, I had made a lot of changes and due to a re-install of MPLAB-X, I had lost my backup history. Debugging did reveal real bugs in the logic which were soon fixed, but the phantom makes and breaks still persisted.

I eventually tracked it down to a puzzling observation. Most of the time, everything worked fine, but sometimes, the sense input pins were jammed in output mode with a value of “0”. The results of my analysis was that the recommended fix for issue 62 actually causes a problem! I removed the errata #62 fix and the problems went away. What a relief; And that’s why my blog post was delayed 😉 Some lessons (re)learned:

1. Errata recommendations can be wrong too.
2. Test often and test fully. Repeat old tests! Especially after unusual changes.
3. Use a version control system separate from your IDE and keep backups.
4. If it ain’t broke, be really careful before you “fix” it!

Peter Camilleri (aka Squidly Jones)

# About the MMB-32 development project.

I have been experimenting and developing code for a cool little board made by a Serbian company called MikroElektronika. An absolute haven for embedded developers and hobbyists, they have a full range of development systems supporting Microchip’s PICs, dsPICs, PIC32s as well as 8051, ARM and other vendors chips. In addition, they support all of these processors with a full line of home-grown C, Basic and Pascal compilers that I hope to evaluate and write about soon.

The development system that I am currently using is the mikromedia for PIC32. This little gem of an SBC has a QVGA HiColor Touch Screen Display with a powerful PIC32MX460F512L processor. Also on board are a one megabyte SPI flash device, a micro-SD slot, a 3D Accelerometer, an MP3 decoder, access to unused processor pins, and many more features than I can possibly enumerate here.

Now this little wonder of a system is incredible, especially when compared to the typical development systems that were common in the bad old days. I mean it used to be that you got a couple of switches and an LED or two and that was it! Now we have this:

The only thing is that such a sophisticated little board requires a great deal of code to make it do anything useful. Consider something simple like the touch screen. The touch screen is read using the analog to digital converter. The thing is that converter is also needed for other things as well. An A2D manager was needed to manage that resource. The touch screen needs to be calibrated. That resulted in the creation of calibration code, and then there was the issue of storing the calibration data some place. All this while learning the new MPLAB-X programming environment and the latest C compiler from Microchip.

That’s why I started the emSystem project. This project aims to create a simple, frugal framework for embedded developments that will enable programmers to focus on application programming. emSystem will eventually be open-sourced, but it’s too incomplete to stand up to that sort of criticism just yet. In upcoming postings, I plan to review my progress and point out bits that you may find interesting.

A companion to the emSystem is the emGraphic program. Originally this was designed to be a tool for anyone doing embedded programming. As such it permits the programmer to create, import, and manipulate color palettes, bit-mapped images, fonts, Unicode strings, and Binary Large Objects (BLOBs) and have the results output as C source code for incorporation into an embedded system. As time went by, it became clear that these two components could not exist in isolation. So now I consider them to be two aspects of one whole system. emGraphic is currently written in C# under windows, but I am considering porting to Java to run under the Net Beans environment of MPLAB-X. Like emSystem, a fair bit more work is needed on emGraphic, so I think I better make up my mind before sinking too much more effort into C# and dot NET.

Peter Camilleri (aka Squidly Jones)

# Hello world!

Well actually: printf(“Hello World\n”);

Welcome to the Teuthida Technologies Web Site. I would like to start off by apologizing for how long this web site has been nothing more than a place holder consisting of some tacky shirts in a closet. I suppose it was better than the alternative of a browser error,  but not much better.

So! Here we are. I plan to use this space as a forum for discussing the discipline of embedded software engineering and its relationship to other engineering disciplines. While I occasionally will wax eloquently (I hope) on such esoteric topics, normally I will be sifting for pearls of wisdom from my own experiences in the embedded field.

A little about me first. My name is Peter Camilleri. I have been a software developer for my whole professional career. I got into the field because I enjoyed engineering computers long before I got paid to do it. I was designing computers many years before I had the ability to follow through, and I am still fascinated by the architecture of computers and the software infrastructure that makes them useful. I have done many types of programming in my day. C and C++ under DOS, OS/2 and Windows; Power Builder and PL/SQL in large client server applications; Java under Windows and Linux; and a fair bit of C# in the .NET environment.

Most recently (for the past fifteen years) I have been lucky to have have focused on embedded systems and their programming. I love embedded systems programming! If you ask me about my favorite operating system I will say “the bare metal” or at most a thin RTOS kernel. I actually think that while Linux is huge, sluggish, and bloated, Windows is much, much worse. Embedded programming has a directness and purity to it that these others lack. There is a real feeling of satisfaction I get in getting a piece of hardware to perform well; even if it’s just a chip smaller than a grain of rice!

So this is my first posting, hopefully of many. I have a large backlog of article ideas that I need to start working through, but first, I need to get the little elements of this web page under control. Hopefully WordPress will prove up to the task. So far it looks good. See ya soon!

Peter Camilleri (aka Squidly Jones)