PiXCLe White Paper (public)

Issues in creating a Smart USB Touch Screen Gadget

25-May-2012

Touch screens are appearing everywhere, and this is way more than just iPhones, iPads and Android Tablets. Just about anything that has controls can be reengineered with a touch screen. This might be a hand held test and measurement device for automotive service, a piece of lab equipment that needs to run stand-alone and control a process while logging data, or something as simple and enjoyable as a model train layout control system.

So ... you have a clever idea for a touch screen device. How do you proceed?

Fast 32-bit hardware with an LCD screen of various sizes is very inexpensive, so how hard could it be to get some software to run this? It turns out that this is a lot harder and more expensive than you might expect.

We've been building software and systems to deploy USB sensor and control devices for some time, with a Windows PC as the host, but when we looked into mobile/embedded applications, we found there were three big problems.

Firstly, there's multiple knowledge gaps . While we know Windows and the desktop inside out, this is of little use for an embedded device with limited resources. It's necessary to have a detailed knowledge of the micro Controller (ARM Cortex-M3 in this case) and the board design to create what's known as the Board Support Package, or BSP . You might have seen references to "bringing up new hardware" in job postings for embedded systems engineers. This refers in part to creating, testing and debugging a BSP.

The next knowledge gap is learning to use the development tools, often referred to in general as the tool chain. This is the code development software (the equivalent of Microsoft Visual Studio) for the chosen embedded hardware, and the compiler / linker / downloader that creates the ARM binary on the Windows host. There are many options available.

Secondly , there's the cost of the development tools (software and hardware) that are required to create embedded software. Keil Software Ltd. is one of the biggest tool chain providers, and their uVision IDE is available as a free evaluation version that can build 32KB binaries, a $3000 version that can build 256KB binaries, and a $5000 version that can build binaries of any size for a wide variety of chip sets. Their compilers and linker tools are highly optimized and produce very compact code. Similar IDE products from other vendors like IAR and Raisonance are available for similar prices. Rowley (UK) has its excellent $1500 Crosstalk IDE that makes use of the Gnu Tool Chain (a.k.a. gcc).

Getting a developed application from Windows into an embedded board is best done with a JTAG programmer unit. These can be quite expensive: $300-400 for a commercial device with the minimum functionality. There are workable devices using OpenOCD in the $60 range, and Chinese-made illegally cloned versions can be found on Ebay for $30-40.

There's also the numerous so-called middleware software providers. These companies provide real-time operating systems (RTOS) with graphics, user interface, USB and TCP/IP driver code stacks. If you want to build a commercial product with any of these, license fees are in the order of $16-20K, and for this you can build an unlimited number of devices.

Most of the required tool chain software can be obtained from the Open Source community. To be fair, a lot of it is pretty good, but it's also often difficult to decide what products work well with others without a lot of trial and error. All the Open Source IDE's we looked at use the gcc tool chains in one way or another. Some of the better known packages have support forums, but it's not always easy to get answers quickly and accurately, and so you get back to the knowledge gap problem.

Thirdly, since we wanted to build a set of USB devices, there's a number of dirty little secrets that can trip the unwary. All USB devices have a Vendor ID (VID#) and a Product ID (PID#). The USB organization requires a $2000 fee for a three year licence, and issues a unique VID# with 65536 PID#s, and with it the right to display any of the official USB logos.

Most of the commercial tool chain and middleware providers are targeting the large manufacturer that intends to make 100's or 1000's of a touch screen gadget: smart phones are the perfect example. The license per device cost is very low, but the up-front license fees are high. For example, the Micrium uCOS-3 license fee for a dual core ARM cpu is $53K, and for a Cortex-M3, about $20K.

What about using an iPhone or iPad as the host system and adding your own hardware and an app?

This is a valid idea, but again it's not as simple as it might first appear. How many iPhone or iPad add-on hardware devices can you think of, right now? Not many, right? Apple understandably requires a high minimum technical standard for devices that attach to their products. You have to submit your company information including financial details, your project, get accepted, and then purchase from Apple the connectors, communications protocol encoder chips, test equipment and be able to test your device on every compatible Apple product. At the same time you have to develop your app, so you get back to the knowledge gap issue. In effect this limits the builder community to established companies with project funding.

Why not use an Android tablet as the host device, and add hardware and an app?

Again, this is a valid idea. Developing an app for Android is not all that difficult, but there is a significant learning curve, firstly in general app development (most commonly using Java and Eclipse), and then in adding and using the USB libraries. If your chosen USB device doesn't have a device driver, you will have to write one if the device information is available, and often it's not. If you want to use Android USB Accessories (special case USB devices, if what you need exists in the market) there's more to learn again. Older Android version devices may or may not be upgradable to newer versions of the software, and working in the USB driver stacks requires a significant level of experience. A final issue is that a commercial Android device is already packaged, and unpackaging or repackaging it may not be a workable option if the intent is to produce your own commercial product.

What about the device operating system?

We can answer this with "Who Cares?". iPhone, iPad and Android may not even be an option if the chosen hardware does not have the resources to run an operating system, and many embedded applications don't need a complete operating system at all. In fact, you may have noticed that for mobile devices, the operating system is irrelevent, as the devices connect to a network service that returns content (i.e. HTML) to a browser application. Embedded systems are moving ever faster in the same direction. Users expect to be able to read and write files to what looks like a disk drive, most commonly on an SD card or memory stick, without knowing or caring what operating system, if any, is actually controlling it.

So where does all this leave the individual or small company who wants to build a USB touch screen gadget in small volumes?

For the individual building a sensor and control gadget for his own use, there's no issue with copyrights or use of evaluation versions of software. He just spends whatever time and effort it takes to get the gadget to work.

The small company intending to build a low volume commercial product is another issue entirely. Development costs matter and copyright issues must usually be resolved by paying license fees. If the Open Source GPL or even the LGPL licenses are used, there can still be requirements that product source code be made available, and this usually will not be in the company's interests.

We wanted to access the market of creators and builders of laboratory, light industrial and environmental control equipment by providing affordable tools, components and software. These people are not well served by the large vendors.

Current 32 bit micro-controllers like the ARM Cortex-M3 run at 72MHz or more (we've seen some 400MHz boards), and have enough computing power to run a small RTOS and several applications. The main requirement was to provide a simplified way to program the board and LCD that could be learned by relatively unsophisticated users, thus largely removing the knowledge gap, tool cost and licensing issues.

The PiXCL language has been evolving for years, so we decided to port a subset of the language and interpreter to run directly in the ARM board.

The embedded application is developed and debugged in the PiXCL Code Studio, as a Windows simulation that includes dialogs that enable digital and analog input-output operations to be tested.

All commercial tool chain IDEs, and most of the Open Source IDEs are quite complex because they can be used to build and debug code for many types of micro controllers. Consequently, setting up a project can be quite daunting for the new developer.

We wanted to dramatically simplify the development process, by allowing the user to concentrate on the control application, and mostly ignore how the application has to interact with the hardware.

The PiXCL Code Studio is intentionally kept as simple as possible. Aside from the usual toolbar buttons to open and save files and edit code, testing and compiling an app are each started from a single button. A third button identifies the attached Decaf™ board, downloads the compiled app to the board and instructs the board to reset, which starts the app running.

We also wanted to make the firmware upgrade process as user friendly as possible. The traditional way of doing this with a tool chain IDE is to setup a JTAG device, attach it to the board, and use this to download the binaries. An appropriate JTAG device can also be used to debug code on the board, if the tool chain IDE supports it. On-board app debugging is quite tedious, and again, brings us back to the knowledge gap problem.

Consequently, we created a set of utilities to load firmware to the boards. The first requires only a serial cable, and downloads the core Device Firmware Update or DFU code. This code remains permanently resident on the board, and causes it to appear as a USB Device in DFU mode. This completely removes the need for a JTAG device.

The second utility is the DFU loader. All PiXCL software updates are provided as DFU binaries, and are downloaded to the board via the USB connection.

Since the PiXCLe interpreter is resident on the board, there is no firmware debugging required, as it is the PiXCL app code that defines the running application. Most, and often all, debugging is done in the simulation phase.

###

Thanks for reading this paper. Like us on Facebook

If you would like to see some detailed advance product information and provide some feedback, send us an email request and we'll provide you with a userID and password.