Innovative Interfacing
Even simple MCU-based projects often require some sort of front panel interface. Traditionally such systems had to rely on LEDs and switches for such simple interfaces. These days however, you can buy small, inexpensive computing devices such as mini PCs and tablet computers and adapt them to fill those interfacing roles. In this article, Wolfgang steps you through the options and issues involved in connecting such PC-based devices to an MCU-based environment.
More often than not, even a humble project—done for educational, tinkering or just for fun—needs some way to display something and to allow for operator interaction. That means contemplating how best to craft an operator console, a control panel, a display assembly or how to set up a testbed and the like. Solderless breadboards, jumper wire and the ubiquitous small modules were the traditional tools for such efforts—in the past there was no other way than to build real hardware from scratch.
It goes without saying that today’s state-of-the-art technology is characterized by computers with touchscreens and the like. Simply run your favorite flight simulator and compare the cockpits of an old Super Constellation or F-86 aircraft to the cockpits of a Boeing 777 or an F-22. In down-to- earth projects, it is quite natural to think of industrial-grade hardware—industrial PCs, embedded PCs and so on. But those can be way too expensive for our low-budget projects. That’s why we think about using small, inexpensive personal computers (PCs). This topic is best clarified through photos. With that in mind, besides what’s in this article, more photos can be found on Circuit Cellar’s article materials webpage appendix.
Figure 1 shows some devices that are essentially basic display and control panels. In most educational, tinkering or fun projects, it’s not practical to spend a lot of time and money to design and build impressive assemblies and panels. More often than not, the problem is solved by more or less sloppy tinkering. In contrast, the devices shown here are somewhat more advanced. They are still jerry-built, but they are crafted with sturdiness as a main objective.
Figure 2 shows three boxes that are basic control panels, each supporting eight inputs and eight outputs. While the device to the left is clearly jerry-built, the two other devices are the result of meticulous mechanical design—they were conducted as experiments (and student assignments) with an intentional disregard of cost. Figure 3 shows the interior of the most sophisticated of the control panels. It supports signal levels between 2.5 V and 24 V, remote operation via the USB and an LCD display. Under program control, it can be operated as a small quasi-static digital tester. When you need more than eight inputs or outputs, attach two or more panels via a USB or serial hub.
It goes without saying that such a device is not that cheap. The bill-of-materials (BOM) cost alone could pay for more than one small tablet PC running Windows. Figure 4 shows an 8″ tablet in a purpose-built frame, attached to a test rig and two 7″ tablets in a 19″, 3U subrack. In contrast, those devices are considerably less expensive than the apparatus shown in Figure 3.
Employing a PC requires programming skills, but no special craftsmanship or a workshop full of tools. Yes, writing and debugging programs may be challenging. But it’s a lot more forgiving than a mechanical interface where you could accidently turn a front panel into scrap metal, simply due to a misplaced hole or dealing with mismatched connections that only show up when you’re fitting the parts together.
— ADVERTISMENT—
—Advertise Here—
SMALL AND INEXPENSIVE PCS
Figure 5 shows different types of small, affordable PCs. Table 1 gives an overview of the dimensions and screen resolutions. Architecturally, these are all compatible PCs. Many are delivered with a pre-installed Windows operating system. That said, they are not intended to be used as fully-fledged desktop PCs, but rather just to connect to the Internet, provide video content and to run a plethora of small application programs (apps). To use them as a console, operator panel or testbed controller in a microcontroller (MCU)-based environment is no more demanding than the applications for which they are destined. On the other hand—unlike typical small embedded or industrial PCs—they have not been designed with these kinds of applications in mind. Therefore, occasionally we’ll have to come up with something special.
Let’s look at each of these devices:
(a) Netbooks: Netbooks are small portable PCs with a screen and a keyboard. The keyboard is typically supplemented by a touchpad. The screen of newer netbooks is a touchscreen. Screen and keyboard are either hinged (like conventional laptops or notebooks), or they can be separated into a tablet and a wireless keyboard.
(b) Mini PCs: Mini PCs are PCs with particularly small dimensions. Screen, keyboard and so forth are external devices. Compared to the other form factors, mini PCs are more lavishly equipped with interfaces.
(c) PC sticks: PC sticks are very small mini PCs with only a few I/O interfaces (Bluetooth, WLAN, USB). Above all, they are intended to directly connect to the HDMI input of a TV set. In this way, nearly any modern TV can be turned into a Windows computer.
(d) TV boxes: Computers referred to as TV boxes or similar are essentially mini PCs with a built-in screen—in other words, they are small all-in-one computers.
(e) Tablets: Tablets are complete computers with a touchscreen. They are meant as mobile communication devices—basically as somewhat larger smartphones. The touchscreen is the only operating and display device. Tablets have only a few I/O interfaces (Bluetooth, WLAN, USB).
It goes without saying that there is no impediment to using older, hand-me-down or refurbished equipment. When used as a single-purpose device, the release number of the operating system does not matter. What does matter is whether the application can be programmed or not. It’s not even necessary to connect the machine to the Internet. The basic idea is to make good use of such small PCs. The key points are the form factor, the interfaces, the power supply, the display and the programming. Here, we will limit ourselves to an overview—a first impression. Details can be found on the Internet.
INTERFACING
So, our goal is to connect a PC to an MCU-based environment. Keep in mind that the PC is merely a human-machine interface (HMI) device. More often than not, when an embedded system is to be brought up and debugged, we have to get along without the real application environment. As a substitute, the peripheral interfaces are typically connected to some kind of adapting circuitry, dubbed here the diagnostic front-end. As shown in Figure 6 and Figure 7, it is controlled by an MCU too. A second small PC serves as its HMI device. With more elaborate programming, such a configuration could be developed into a more or less automated test system. Figure 8 and Figure 9 show some more examples of PCs replacing various types of interfaces.
We’re talking here about a command and control interface, not a real-time processing interface. The computer is merely an HMI device. Therefore, real-time performance—with respect to data rates and latencies—is not that important. The smallest computers have only USB, Bluetooth and WLAN interfaces. The easiest way to solve the interfacing problem is world’s most ubiquitous serial interface, often referred to as RS-232. For the all of interface technologies mentioned earlier, converters to RS-232 are readily available. The most straightforward application interfaces—in terms of cost and ease of programming—are USB, Bluetooth or WLAN with conversion to RS-232.
POWER SUPPLY
Mini PCs, PC Sticks and video-boxes are operated from grid power. Netbooks and tablets are battery-operated with the option to attach an AC power adapter. In this respect, it is not rocket science to choose the computer that is suited for the particular requirements. However, there is one kind of computers, which may pose a problem. It is the small tablets with only one combined USB and power connector. There are two varieties: one according to USB 2.0 OTG and a newer according to USB 3.x and Type-C.
USB 2.0 OTG: The tablet has a micro-AB socket. It is operated according to the OTG specification (OTG is USB On-The-Go). The micro-AB socket has an identification contact (ID pin). OTG-compliant cables have a micro-A plug, connecting the ID pin to ground. Other cables have a micro-B plug, leaving the ID pin open. Table 2 gives an overview of the behavior of such tablets.
If ID = Low, then the tablet recognizes an OTG cable. In this way it acts as a USB host, supporting attached devices. It also delivers the 5 V supply voltage. That is, in the operating mode as a USB host, the battery cannot be charged. Instead, it must also supply the connected facilities, unless they are otherwise fed.
— ADVERTISMENT—
—Advertise Here—
If ID = High, then a standard USB cable or a power supply/charging cable may be plugged in. The tablet could be connected to the USB of another computer as a device and act, for example, as an external drive. However, this is not implemented in all tablets.
The question is whether or not we are content with these operating conditions. If not, we could avoid using the USB so that the connector is available to plug in a charging cable, thus providing for grid power operation. However, then we are restricted to the tablet’s wireless interfaces. MCU modules could be attached via a Bluetooth serial adapter or a Wi-Fi device server. This solution is surely adequate for a pure HMI device or console. The unpredictable latencies of wireless communication, however, may impede employing the tablet as a periphery emulator or testbed controller. A radical alternative would be to open the tablet, remove the battery and attach an external power supply.
USB 3.x and Type-C: Type-C is a universal USB connector that supports all current USB standards and allows both orientations of the connector when plugged in. There is no top and bottom—you can also insert the plug rotated 180 degrees. How the supply current flows in the USB cable is controlled via a special signal CC (Configuration Channel). If a power source is attached—for example a standards-compliant charger—the USB port is configured for external power supply.
If a device or hub to be powered via USB is attached, the USB port is configured as the supply voltage source. The tablet then feeds the connected devices. If nothing is connected, there is no supply voltage at the USB socket. The signaling is based on the connected device pulling the CC signal via a resistor to either +5 V (if it acts as the source) or to the ground (if it acts as the load). Power grid operation with USB devices attached requires an appropriate adapter.
USB Cabling: Beware. In most cases, USB wiring must be based on ready-made cables and adapters. While USB1 is extremely forgiving, USB2 and USB3 (which is still more demanding) require strict compliance to the USB standards. If the data lines are not properly twisted right up to the connector, the interface will not work.
MECHANICAL DESIGN
Netbooks and TV-boxes are all-in-one computers. As a result, we can simply place them next to the MCU modules and connect them via the USB.
Some mini PCs come with a so-called VESA mount, allowing to mount them behind the TV or monitor. Such mount adapter kits can be used also to attach the mini PC in a subrack or another casing. Mini PCs without such provisions may require some tinkering. PC sticks require some tinkering as well. A PC stick plugged into the HDMI socket of the TV or monitor is occasionally shown in advertisements. In practice, however, cantilevering the stick is somewhat unwieldy.
Consider that the power supply and the USB devices also need to be attached. Besides, not all TV sets or monitors provide for the clearance necessary to plug in the stick. A quick-and-dirty solution could be placing the stick and the accompanying devices—like a USB hub or an external drive—loosely in a box-like enclosure. If necessary, you may fix them with Velcro tape. All that said, providing power to more than one device may require some ingenuity if you want to avoid using a separate wall adapter for each device.
Small tablets are particularly attractive because they already exemplify the idea of a cost-effective control panel at first glance. You can easily afford more than one. Therefore, it makes sense to use them as HMI devices and testbed controllers. Obviously, it would be very inconvenient to simply leave them on the table or to hold them in the hand.
Some innovative thinking is required to figure out how to accommodate the various supplementary pieces of hardware, like the power supply, USB hubs, switches, additional control elements and the like. Our examples (Figure 10 and Figure 11) rely heavily on 19″ subracks, plug-in units, and front panels. An alternative to a small tablet could be a mini-PC or a PC-stick together with a small monitor (Figure 12).
PROGRAMMING
What we need is an integrated development environment (IDE) to write application programs. With such programming tools, it’s not difficult to program impressive presentations and to support various kinds of operator interfacing using command lines, graphically displayed switches and indicators, protocol windows, selection menus, animations and the like. It’s even possible to provide for operation via the Internet or smartphone.
The IDE should be easy to use and not overly expensive. Programs to emulate keys and LED displays or to send stimuli to devices under test (DUTs) and to make decisions based on test results will surely be neither very large nor very complicated. Such programming projects are well-suited for beginners or casual programmers. Conventional, procedural programming will suffice—at least if the project is not too ambitious.
Even Windows derivatives of the venerable Basic programming language have been found to be sufficient. The examples shown here have been programmed with the PowerBasic IDE. Some suitable low-cost or even free IDEs are available. More ambitious programmers may choose more advanced IDEs, like Embarcadero’s RAD Studio or Microsoft’s Visual Studio. Those are also, under some prerequisites, freely available too.
If only HMI functions are to be implemented, latencies will be short enough. But latencies may be of concern if real peripheral devices are to be emulated. A real LED reacts instantly. In contrast, its replica on the screen will be noticeably slower (compare Figure 7 and Figure 8). On the other hand, you don’t need to buy or build any hardware, and you can program in as much comfort and gadgetry as you like. So, you can label control elements on the screen and change their number and shapes as desired.
USER INTERFACE DESIGN
Screen resolution: This determines what can be displayed on the screen. Table 3 gives an overview of typical resolutions.
— ADVERTISMENT—
—Advertise Here—
Screen size: This determines the recognizability of the details and the usability on the touchscreen. Table 4 contains typical screen dimensions.
Screen diagonal and screen size: From the screen diagonal d (in inches) and the aspect ratio h:v (for example, 16:10), the screen dimensions av, ah (in inches or mm) are as follows (Figure 13):
The screen’s aspect ratio is a given value. As a result, the square root will be constant. For practical calculation see Table 5. The actual dimensions may differ slightly.
Programming for small screens: The small screen requires a special design of the user interface. The graphical representation is clearly recognizable. Small fonts are easy to read. The control elements are acceptable too. Whether they are considered somewhat nice or not is a matter of taste. The problem is not viewing, but operation.
Figure 14 shows an application-specific operating window designed for a full-fledged PC. It can also be displayed on small screens. The details are still clearly visible (Figure 15). However, the problem is the operator’s input. You can hardly do it without a mouse. Buttons can still be operated with a finger, while in contrast, sliders, scrollbars and spin boxes are obviously too tiny. If the screen is too small, not everything will fit on it (Figure 16).
Maybe you’ll have to design two variants: one for the tablet and one for “big” PCs with larger screens. If touch operation is desired, the touchable control elements must be large enough. Because the screen is small, the entire surface must be exploited. However, controls and windows that are the right size on the tablet are often much too large on standard PC screens.
Touch operation only or additional controls? This depends on the application. If the tablet serves only to replace toggle switches and LEDs, touch operation will suffice. After all, we want to get rid of expensive components and mechanical work. It may require several attempts until we will consider our user interface satisfying. In contrast to mechanical interfaces however, nothing can really go wrong here.
Mouse operation instead of touch operation? If control elements are to be selected by a mouse, they may be small. Their minimal size is essentially determined by the requirement to be easily recognized and read (labeling, texts). The mouse can be used to do everything that could be done by clicking and dragging. A mouse is inexpensive, handy and easy to connect (via Bluetooth or USB). All that said, it is an additional device that also needs a dedicated surface to be moved around.
On-screen keyboards: The system’s on-screen keyboard takes up a large amount of the screen’s surface (Figure 17). Input fields should be arranged in such a way that they are not obscured by the on-screen keyboard. That doesn’t always look nice.
Solving the on-screen keyboard problem in the application: The computer in this case is not intended for surfing the Internet. Rather, it is to be programmed as a kind of special-purpose machine (control panel, testbed controller and so on). That means you have the whole screen to your disposal. If the key actuation is valid only with respect to the particular application, there is no need to rely on the system’s on-screen keyboard. You may roll your own and place it wherever you see fit. The keys are Windows control elements (buttons) sending messages to the application program.
The decimal and hexadecimal keypads shown in the photos may serve as examples. Besides, they could be extended to enter letters similar to how well-known smartphone keypads operate. If the on-screen keyboard is programmed as a graphics window, it may be dragged around freely. If the computer is equipped with a mouse, you may provide a small on-screen keyboard that sits in a corner where it’s not in the way. The keys can be tiny because you do not have to touch them with your finger.
Keyboard input: A real “hard” keyboard eliminates the need for an on-screen keyboard, so no screen area is lost. It can be connected easily (Bluetooth or USB). Typing will be much more convenient. However, except for netbooks, it is an additional device to deal with.
Keyboard-only operation: The netbook—with its attached keyboard—leads quite naturally to this idea. The keyboard is the only input device. The most basic implementation of this principle is to use the PC as some kind of dumb terminal (Figure 18). To provide something more sophisticated, you could implement a menu system—somewhat similar to the menus used in conventional data processing. The input options are offered on the screen, either as text or as graphical elements. Selection is made by pressing the appropriate key or by moving the cursor to the menu item to be selected.
That’s not so old-fashioned and has advantages. There’s a reason that even the most advanced operating systems still have character-oriented user interfaces that use the screen only for command input and protocol output—similar to a teletype or a Selectric typewriter. Menus are merely an extension to facilitate ease of use.
Examples along those lines are debugging and testing. Think of an MCU-based application to be operated via an attached PC and consider that at least two programs are to be written and debugged: the MCU’s application and the operating routines. Simple character-oriented protocols require much less effort than a sophisticated GUI. A dumb terminal requires no application-specific programming of the PC at all.
When the HMI between the PC and the MCU is based on simple ASCII character strings, the interactions can be easily automated. Command strings could be repeatedly sent, could be stored in files and so on. That’s the basic notion of a scripting language. It goes without saying that you may adopt one of the well-established scripting languages, instead of rolling your own. This comes, however, with a price: you have to master the language, obey the standards, make your solution compatible and so on.
Additional controls? Sometimes it is worth considering. Specialized operating and display devices could be supported, like incremental encoders, selector switches, small LCD or OLED displays and so on. The question is, how to connect such extensions to the system? They can be attached to an MCU connected to the PC via the serial interface and the USB. However, it’s completely on you write all the programs—for the MCU as well as for the PC. Alternatively, input devices could be made to appear like a standard keyboard. There are USB controller ICs available that convert externally delivered bit patterns into keyboard codes to be transmitted to the PC. As a result, you can rely on the system’s message queue to program the operating functions.
SUMMARY AND SUGGESTIONS
Clearly small PCs are so inexpensive that they could be used reasonably as some kind of OEM components even in low-budget projects. Connected to MCUs acting as a front end, they may serve, for example, as operator consoles, debugging aids or testbed controllers. In this way, they take the place—more or less—of improvised contraptions made of LEDs, switches, LCD displays and the like. Programming doesn’t require either expensive tools nor any advanced craftsmanship. You may change and modify a program as often as you see fit.
Unlike a mechanical user interface, a virtual front panel will show no scratches, misplaced holes or unsightly cut-outs. It will always look neat, laid out, colored and labeled—more than the proverbial kitchen table hobbyist could ever dream to achieve with a piece of sheet metal. Further possibilities are nearly limitless, depending only on an appropriate IDE and well-honed programming skills. Some obvious next steps could be supporting both operation and display functions via the Internet or a smartphone. 
RESOURCES
The author’s project homepages:
https://www.realcomputerprojects.dev
https://www.controllersandpcs.de/projects.htm
VESA (Video Electronics Standards Association):
https://vesa.org
We may need two standards:
1) DMT (VESA and Industry Standards and Guidelines for Computer Display Monitor Timing) for an overview over the screen resolutions,
2) FDMI (VESA Flat Display Mounting Interface Standard) if we want to make use of the VESA mount. for example, to fasten a mini-PC in our casing, frame, or test rig.
Both standards are freely available for download.
USB standards:
https://www.usb.org
The standards are freely available for download. Of particular interest are the following items:
USB Power Delivery
USB Type-C(TM) Cable and Connector Specification
USB Type-C(TM) Port Controller Interface Specification
USB 2.0 Specification (also contains the OTG specifications)
IDEs (Integrated Development Environments):
PowerBASIC: https://www.powerbasic.com
PureBasic: https://www.purebasic.com
Liberty Basic: http://www.libertybasic.com
Multi-platform Development:
RAD Studio (Delphi and C++):
https://www.embarcadero.com
Visual Studio (C#, C++, Visual Basic, JavaScript):
https://visualstudio.microsoft.com
Embarcadero | www.embarcadero.com
Microsoft | www.microsoft.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • SEPTEMBER 2019 #350 – Get a PDF of the issue
Sponsor this Article
Wolfgang Matthes has developed peripheral subsystems for mainframe computers and conducted research related to special-purpose and universal computer architectures for more than 20 years. He has also taught Microcontroller Design, Computer Architecture and Electronics (both digital and analog) at the University of Applied Sciences in Dortmund, Germany, since 1992. Wolfgang’s research interests include advanced computer architecture and embedded systems design. He has filed over 50 patent applications and written seven books. (www.realcomputerprojects.dev and
www.controllersandpcs.de/projects).
