[Editor's Note: This was originally posted on Low-Power Design] 

To avoid confusion or the need for repetitious information in later posts, I will now describe the test bench and process I am using for these touch development kit projects. This process is something I have refined over a number of previous hands-on projects that involved using embedded resources from multiple vendors. The goal of the process is to extract the most value from the effort while minimizing the time spent dealing with the inevitable usability issues that arise when working with so many different kits.

I have several goals when I perform this kind of hands-on project. First and foremost, I want to understand the state-of-the-art for touch development kits. Each company is serving this market from a slightly different angle, and their board and software support reflects different design trade-offs. I believe uncovering those trade-offs will provide you with better insight into how each kit can best meet your needs in your own touch projects.

Additionally, each company is at a different point of maturity in supporting touch. Some companies are focusing on providing the best signal-to-noise ratio at the sensor level and the supported software abstractions may require you to become an expert in the sensor’s idiosyncrasies to extract that next new differentiating feature. Likewise, the company may focus on simplifying the learning curve to implement touch in your design; the software may abstract more of the noise filtering and allow/limit you to treating touch as a simple on/off switch or an abstracted mouse pointer. Or the company’s development kit may focus on providing rich filtering capabilities while still allowing you to work with the raw signals for truly innovative features. My experience suggests the kits will run the entire gamut of maturity and abstraction levels.

Another goal is to help each company that participates in this project to improve their offering. One way to do this is to work with an application engineer from the company that understands the development kit we will be working with. Working with the application engineer not only permits the company to present their development kit’s capabilities in the best possible light and enables me to complete the project more quickly, but it puts the kit through a set of paces that invariably causes something to not work as expected. This helps the application engineer to gain a new understanding of how the touch kit can be used by a developer and that results in direct feedback to the development team and spawns a refinement that improves the kit for the entire community. This is especially relevant because many of the kits will have early adopter components – software modules that are “hot off the press” and may not have completely gone through the field validation process yet. This exercise becomes a classic developer and user integration effort that is the embedded equivalent to dogfooding (using you own product).

In addition to the development boards and software that is included in each touch development kit, I will be using a Dell Inspiron 15 laptop computer running Windows 7 Home Premium (64-bit) for the host development system. One reason I am using this laptop is to see how well these development kits support the Windows 7 environment. Experience suggests that at least one kit will have issues that will be solved by downloading or editing a file that is missing from the production installation files.

So in short, I will be installing the development software on a clean host system that is running Windows 7. I will be spending a few hours with an application engineer, either over the phone or face-to-face, as we step through installing the development software, bringing-up and verifying the board is operating properly from the factory, loading a known example test program, building a demonstration application, and doing some impromptu tweaks to the demonstration application to find the edges of the system’s capabilities. From there, I will post about the experience with a focus on what types of problem spaces the development kit is best suited for, and what opportunities you may have to add new differentiating capabilities to your own touch applications.

If you would like to participate in this project post here or email me at Embedded Insights.

Tags: Speech Recognition, Touch Screens

This entry was posted on Tuesday, May 11th, 2010 at 11:41 am and is filed under User Interfaces. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.