Development of 32-bit Processor Embedded System Based on LabVIEW

As 32-bit multi-core processor applications become increasingly popular, designers are facing new challenges. Industry experts point out that actor-oriented graphical methods are more suitable tools for embedded software design. NI's LabVIEW Embedded Development Module is a new add-on module for the LabVIEW graphical programming environment. Through this software and the concept of graphical system design, engineers who were previously unable to use embedded programming can enter the field of 32-bit microprocessors. Design their applications through a complete tool such as state diagrams, control charts, and signal processing library functions added to LabVIEW to solve various problems. This article introduces the development tool.

As embedded systems become more and more complex, designers are facing new challenges: As the cost of embedded systems based on 32-bit microcontrollers (MCUs) approaches that of 16-bit systems, 8-bit and 16-bit microcontrollers are gradually giving way to 32-bit systems on chip (SoCs) with better scalability and performance in many advanced applications. In addition, since increasing the performance of the entire system simply by improving the performance of the CPU is no longer a sustainable development trend, major processor manufacturers have turned to multi-core architectures. This trend can be seen in the multi-processor core desktop computer launched by Dell a few months ago. From the perspective of consumers and users, the processing performance improvement is the same. However, from the perspective of an embedded system developer, the design will become more complex because you must understand how to develop and partition your application in a multi-processor environment. According to estimates ten years ago, the average code size of an embedded system was 100,000 lines. By 2001, this number actually exceeded 1 million, and the current number is estimated to be 5 million.

Now we turn our attention to the current development tools for embedded systems. As the complexity gradually increases, it is difficult for traditional tools to reduce the complexity of programming work. The embedded field needs another approach to meet these challenges. The challenge is not only in terms of tools, but also in the way to solve the problem: text-based programming embedded application development will not be able to solve these problems in the future. This is already the consensus of many experts in the industry; Dr. Edward Lee is a leader in embedded research at the University of California, Berkeley. He pointed out that current embedded system development methods such as text-based programming and object-oriented tools are difficult to use to build embedded real-time systems, because object-oriented tools are difficult to intuitively express time and parallelism, while time or concurrency is essential in today's embedded systems. Dr. Lee proposed that actor-oriented graphical methods are more suitable tools for embedded software design.

Although the challenges of embedded systems are becoming more and more severe, there are now many directions for solving them. Many vendors have taken the approach of abstracting the design of underlying tools. Every step forward in this approach will attract more users. Another direction is to solve the challenges more thoroughly, that is, to move to platform-based tools, which can better express the entire system and reduce the correlation with specific hardware, making more software designs easy to understand and reuse, and the shift from text-based tools to graphical tools can intuitively express the system and solve the challenges of the system. The concept of Graphical System Design is derived from these trends. By simplifying the complexity of embedded programming, it reduces the requirements for domain experts at each step of the embedded design process; at the same time, it provides a shortcut from design, prototype to deployment, allowing engineers and scientists to iterate designs more quickly.

Although the tools on the market are moving towards graphics, they are still limited by their own limitations because they are tools for specific fields and specific applications, which is not enough to solve the challenges that the industry will face. In fact, the current embedded system market has many similarities with the desktop computer market in the early 1980s, one of which is that it is very fragmented. What the market needs now is a fully graphical programming language that provides sufficient flexibility and functionality to meet the needs of a wider range of applications. Therefore, the key factor in graphical system design is graphical programming.

Applying design methodology directly to implementation

Since its birth in 1986, the LabVIEW graphical programming language has begun to simplify the complexity of the system and provide acquisition, analysis and display functions on the same platform. While automating the processing process using computing power, it allows the reuse of software and hardware in the process of prototyping, manufacturing and testing, making up for the gap caused by different tools between the three steps of prototyping, manufacturing and testing. LabVIEW graphical programming has become the standard for development in all areas involving data acquisition and control. Since then, we have continued to add functional improvements to the programming environment, and now LabVIEW has added hardware timing, which is a semantic representation of time and parallelism, to the existing timed loop structure. Now, we can set operating system priorities, delays, loop rates, etc. with a click; and thinking back to the trend towards multiprocessors mentioned earlier in this article, we can now look forward to using scalable and intuitive graphical programming to develop applications and distribute processing to different processors. The

new NI LabVIEW Embedded Development Module, a new add-on module for the LabVIEW graphical programming environment, uses this software and the concept of graphical system design to enable engineers who were previously unable to use embedded programming to enter the world of 32-bit microprocessors. They design their applications to solve a variety of problems using the complete tool set of LabVIEW state diagrams, control charts, signal processing library functions, etc.

Domain experts—experts in a certain scientific or engineering field, but not necessarily embedded programmers—generally use different models or tools to solve their academic or engineering problems. For example, an engineer developing an engine control unit (ECU) might use a state diagram to graphically describe the functionality of the ECU. This engineer might be an expert in control theory but may not have any experience with embedded or C programming. Until now, the implementation of embedded applications has required in-depth knowledge of embedded programming tools, such as C. As a result, many domain experts have relied on dedicated embedded developers to implement their solutions or even simply prove a concept. This gap between domain experts and embedded programmers increases development time and easily introduces errors into the system.

The LabVIEW Embedded Development Module bridges the gap between design and implementation. Domain experts can now use the same environment to quickly design algorithms, prototype custom designs, implement their solutions on the target of their choice, and debug—all graphically.

Developing Target-Independent Code

Embedded targets inherently require programmers to have in-depth knowledge of the target before writing code. Programs need to know a variety of information about the memory map and registers on the board to execute their code on the board. In addition, most code is written specifically for a specific target. Thus, using a different microprocessor or different peripherals on a board may require rewriting most of the existing code, or starting from scratch. This means that the final product is imperfect in terms of scalability.

Figure 1: LabVIEW development interface

However, with the LabVIEW Embedded Development Module, engineers and scientists can develop code without knowing the ultimate target because the software generates ANSI C code for LabVIEW applications rather than binary code for a specific target. LabVIEW Embedded is an open framework that can integrate any third-party tool chain to compile the generated C code, LabVIEW Real-Time Library functions, and Board Support Package (BSP) into binary code that targets and runs on a specific target. BSP is a low-level code that interfaces with the peripheral hardware on the board as C code. Therefore, if the board needs to be upgraded, engineers can simply link a different BSP into LabVIEW and make a small change to the existing graphical code.

Target-independent code development means that engineers and scientists no longer have to wait for hardware to be determined before starting to design algorithms. This parallel work and efficiency improvement greatly shortens the development cycle and time to market. Finally, the generated LabVIEW code is not platform-specific, so you can easily upgrade to new hardware.

Reduce Development Time Using LabVIEW Embedded Features

The LabVIEW Embedded Development Module builds on the nearly 20 years of innovation since the birth of LabVIEW, helping engineers and scientists take advantage of hundreds of built-in library functions covering advanced algorithms, file I/O, logic, and signal processing. With LabVIEW Embedded, engineers and scientists can use a new feature called Inline C Node to integrate existing embedded code to maintain the open architecture of LabVIEW.

In addition to built-in graphical user interface displays, probes, breakpoints, and function stepping for fast debugging, the LabVIEW Embedded Development Module provides two other seamless interfaces for code debugging. On embedded target platforms, engineers can use "instrumented debugging" to facilitate debugging over TCP/IP, RS232, or CAN. Using the built-in on-chip debugging interface, engineers can debug through industry standard protocols such as JTAG, BDI, and Nexus without affecting program performance. The

LabVIEW Embedded Development Module enables domain experts to use existing technologies for more applications, use the same environment for algorithm design, prototype, and implement their solutions, and greatly reduce development time and time to market.
NI provides a variety of hardware platforms that integrate with LabVIEW to complete the entire process from design, prototype to deployment. For example, using LabVIEW and NI reconfigurable I/O (RIO) devices or NI CompactRIO platforms, they can quickly and easily create prototypes of embedded systems. One of NI's existing success stories is helping Drivven, a provider of automotive control and data acquisition solutions, prototype the FPGA-based 2004 Yamaha YZF-R6 motorcycle engine control system through NI CompactRIO. Their goal is to provide a seamless path from prototyping to production for FPGA-based transmission controllers. For this project, Drivven used LabVIEW on software; on hardware, they chose a 4-slot NI CompactRIO embedded system because of its flexibility, small size, and stable form factor. With this system, they can quickly and easily observe data while easily adding sensors and actuators. In addition, they can place the controller in the extremely limited space on a super sports motorcycle. This project includes three main stages: 1. Through the development of custom I/O modules. Three custom I/O modules monitor all of the motorcycle's sensors and control its actuators, and additional CompactRIO modules are being developed for transmission control applications, including modules for driving the electronic throttle and for interfacing with a common exhaust gas oxygen sensor. 2. Mapping the Factory ECU. The performance of the Factory ECU was fully mapped by logging ECU data to 1MB files (up to 20 files at a rate of one file per minute) while the motorcycle was driven at many different combinations of throttle positions and engine speeds (nearly 700 operating points). The driver carefully steered the motorcycle to minimize transients. An engineer in a following car periodically received the data files wirelessly from the CompactRIO, transferred them to a laptop, and immediately analyzed the data to cover all operating points. A laptop-based NI LabVIEW application quickly sorted the data into speed/load operating tables while filtering out transients. The mean and standard deviation were calculated from the data for each operating point. In two hours, the team collected data for 90 percent of the bike’s operating points, which was sufficient coverage to fully understand the mapping of the factory ECU. Later, in the lab, engineers processed the data using LabVIEW, providing 3D and 2D visualizations while graphically modifying the raw data to fill in missing operating points. 3. Engine Control. In the final stage, Drivven used CompactRIO to prototype a research ECU that would have performance comparable to the factory ECU, but with the capabilities to implement future control algorithm research and development (which would not be possible with production electronics). Using CompactRIO, Drivven implemented a number of engine management FPGA cores, all with configurable LabVIEW FPGA diagrams and placed in a block diagram. Using the LabVIEW Real-Time Module, a combination of speed-density and alpha-N engine control strategies (often used in high-performance racing applications) was achieved. Thus, CompactRIO and LabVIEW provided the required reliability and precise timing resources, and the system was robust enough to withstand the high temperatures and vibrations of the operating environment. If readers want to read the complete solution, please visit ni.com/china and enter the information code (info code) cn5k8t.

In addition, using the LabVIEW Embedded Development Module, you can also create embedded boards and deploy them to any 32-bit microprocessor. Just as LabVIEW enables engineers to develop customized virtual instruments instead of relying on vendor-defined benchtop instruments, thus revolutionizing the test and measurement field, the LabVIEW Embedded Development Module enables industry experts to use their expertise to develop embedded applications without relying on embedded experts.

NI Embedded Development Module Diagram

As the complexity of embedded system design increases, graphical methods are an inevitable trend. It is redefining embedded design and enabling more engineers to use embedded development in an unprecedented way, thereby improving the speed and quality of design. Integrating the fragmented market, adopting standard and readily available technologies, and releasing integrated, easy-to-use hardware and software platforms - this is the operating model that NI has been adhering to for many years. Graphical system design is a platform that pushes embedded design to a wider audience. We provide this function through a unified graphical tool that can free domain experts from increasingly complex embedded design. From design, prototyping to implementation, using unified design tools will undoubtedly greatly improve the efficiency of the entire design process.