Optimizing interconnected HMI system designs - Embedded.com

Optimizing interconnected HMI system designs


There are billions of intelligent interconnected devices today populating what has become known as the Internet of Things (IoT). Since these IoT devices are all embedded systems, they need to be developed with the same rigor, design considerations, and device selection criteria as any other embedded application. Product requirements vary dramatically and can quickly become complex, demanding the real-time responsiveness, scheduling, and interrupt support of a Real-Time Operating System (RTOS). Some specifications call for the flexibility and usability of consumer-friendly user interfaces (UI) on products in industrial, automotive, and even medical segments. To successfully bring a system with these capabilities to market, it behooves the designer to use a software design ecosystem and microcontroller (MCU) or microprocessor (MPU) that are highly integrated and optimized for human-machine interface (HMI) functionality.

Choosing a Software Design Framework
Quite often, the first question the software team faces when approaching a new project is whether to use an operating system or not. There are pros and cons to each approach. The cons include: a somewhat larger software footprint; having to learn a new event control mechanism and API; the cost of the RTOS; and, depending on the use-case; more CPU overhead (although an RTOS may actually reduce footprint and/or overhead in cases where a complicated polling loop is required). For systems with even moderately complex graphical interfaces, however, the pros generally far outweigh the cons. RTOSs provide a completely validated and integrated code base with hooks to all kinds of middleware for communication and storage plus graphics libraries. This reduces design risk considerably. Using an RTOS can also make it easier to achieve compliance with regulations for functional safety, among others, because the vendor takes care of certifying large parts of the code base.

Programs with RTOSs also scale well with complexity; whereas programs that use a “polling loop” do not. Put another way, as you add or remove code within the polling (i.e. “while {}”) loop, the round-trip time of the main program changes, and this alters the entire system’s performance profile. RTOS-based systems, by contrast, are partitioned around multiple tasks (or “threads”) – each of which provides event-driven responsiveness, pre-emptive capability, and deterministic latency – and are scalable by design. If you want to add or remove functionality, simply add or remove another task from the program; the program timing should remain the same. Thus, an RTOS actually has the potential to reduce CPU overhead.

RTOSs are also well suited to implementing the model-view-controller (MVC) HMI design pattern. The MVC approach separates the display logic from the application logic, which improves collaboration within teams. Non-HMI sections of code, like complex communications streams – TCP/IP, USB, file systems, etc., can be encapsulated away from the main application in separate program threads. This keeps the code clean and organized. The interfaces between the threads can be formally defined using standard RTOS constructs such as messaging, event flags, and semaphores. Not only does this enable a highly systematic design flow, which allows the designer to quickly converge to working software on his or her own block, but it makes it easy to prioritize events and to manage shared resources. 

To develop attractive graphical user interfaces (GUIs), especially within a tight timeframe, it is also immensely helpful to use tools and software that simplify the design and debug process. There are several high-level GUI design tools available today. Some come with a PC-based design tool that lets you drag and drop objects directly onto a digital “canvas” and quickly “wire them up” to sections of your code. Compared to a purely ”hand-coded” approach, where graphical objects have to be manually instantiated and manipulated through low-level API calls, this methodology makes it easy to implement functions like buttons, sliders, etc. A GUI emulator is also a highly recommended option as it allows designers to move forward their prototyping efforts without needing to plug in target hardware until the final project integration phase. This provides the designer with real-time, ongoing feedback on the UI, even when hardware development platforms are scarce.

Figure 1. Modern embedded HMI design flow paradigm (Source: Renesas Electronics America Inc.)

There are a number of different embedded HMI software frameworks to choose from today. One such example is Express Logic’s GUIX contained within their X-Ware Platform, which includes a high-level GUI design tool, operating system, networking stack, graphics library, and other middleware components. Working GUIs can be put together much like a graphic designer would create a drawing except that the graphical objects can be parameterized and linked directly to functions inside the application to quickly bring the images to life. Using a “what you see is what you get” (WYSIWYG) approach, C code is automatically generated to realize the exact GUI assembled on the tool’s canvas. The pixel-accurate GUI can be tested on the PC in Visual Studio, with GUIX and ThreadX running as if the PC were the embedded target. In addition, the GUI can instrumented on the development board to measure performance using a graphical event viewer, called TraceX. Moreover, networking API provided in the TCP/IP stack allows designers to connect their device to the net via IPv4 or to the burgeoning IoT universe via IPv6.

Figure 2. Example embedded design tool (GUIX Studio) (Source: Express Logic, Inc.)

Next Page >

What About Hardware?
There are numerous MCU andMPU options to choose from when designing an HMI system. Some designerswant the ubiquity of an ARM-based CPU architecture, while others preferthe benefits of vendor-specific CPUs. For example, some vendor’s MCUssuch as the Renesas RX100 and RX600 series microcontrollers have theability to execute software instructions in a single clock cycle via anoptimized on-chip flash memory and flash memory controller. Whateveryour own particular design criteria, the processor you choose should bepowerful enough to plow through your heftiest algorithms, yet not withso much overhead as to blow your power budget. Another consideration tokeep in mind when choosing a device is to find one for which there isplenty of relevant sample code available and for which you can getsupport from the vendor.

Ideally, your chosen MCU or MPU will offer an array of integratedintellectual property (IP) to off-load the CPU and remove external logicfrom the printed circuit board (PCB). Such integration helps keepsystem performance high, can reduce PCB size and complexity, and lowerbill of materials (BOM) cost. IP blocks like graphics accelerators,analog to digital (A/D) converters, and LCD controllers are typicalexamples of functions that can be pulled into a silicon chip. Certainmicroprocessors also offer large amounts of on-chip SRAM and the abilityto efficiently execute code in place (XIP) from quad serial peripheralinterconnect (QSPI) flash memory, which eliminates the need for externalDDR SDRAM. This is a boon to many designers for whom the time, effortand PCB real estate consumed by placing and routing a DDR memory issimply not practical. By removing DDR SRAM from the PCB, designers canpotentially get away with using four or fewer PCB layer as well asthicker traces (>5 mils), which lowers manufacturing cost evenfurther.

In terms of performance, the primary advantage of using on-chipmemory over external DDR SDRAM is that it has significantly lowerlatency. From an HMI perspective, lower memory latency means fasteraccess to buffered images and thus smoother graphics. Depending on thefootprint of the code, on-chip SRAM can also be used for executing afull-blown software stack. The Renesas Electronics’ RZ/A1 MPU is anexample of an MPU with up to 10 MB of on-chip SRAM. By means ofcomparison, one 640×480 (VGA) screen at 32 bits per pixel consumes 1.2MB (i.e. 640 x 480 pixels x 32 bits per pixel / 8 bits per byte / 2^20bytes per megabyte) of memory, and one 1280×800 (WXGA) screen consumes3.9 MB. Thus, 10MB is enough memory to double-buffer up to a WXGA LCDtouchscreen when executing in place from QSPI flash. For higherresolutions than this, it makes sense to consider higher performancedevices that employ a more traditional memory architecture that usesexternal DDR3 memory for code execution and frame buffering.

Figure3. Typical memory layout in an XIP embedded system for human-machineinterface applications, running code from QSPI flash (Example: RenesasRZ/A1 MPU) (Source: Renesas Electronics America Inc.)

Pulling It All Together
Software and hardwareselection impacts your time to market as well as the ease with which younavigate your design flow. It pays to use design tools and softwarecomponents that work seamlessly together with your chosen processor andfor which there is plenty of sample code. This is true whether yourapplication will be used for machine-to-machine communication in the IoTor to provide a simple UI on a stand-alone home appliance.

There are a number of different hardware options available – fromlow-end microcontrollers that support limited screen resolution all theway to ultra-high end MPUs that pave the way to 4K video. Within thispool of devices, it pays to consider an XIP architecture in your deviceselection process, as it gives designers a potent option tosimultaneously increases performance, simplify the design process, andminimize BOM cost. Whatever part you end up choosing, look for a highlyintegrated software and hardware design framework that lets you focus oncreating the best application possible for your target markets insteadof burning time stitching together disparate software components.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.