Author: John Carbone, Express Logic
Source: www.eetimes.com
Embedded systems employing ARM 32-bit processors support application software that can deliver excellent product functionality and benefits. Faced with the challenge of developing such applications, developers seek robust, powerful development tools to help them bring complex products to market faster that are optimized to perform better than the competition.Rather than settling for "free" or "cheap" tools, commercial developers recognize the benefits of paying more for quality tools and achieving quality results. In this rapidly evolving and competitive market, only the strongest will survive. Manufacturers are well advised to consider the ROI from the best tools available, rather than to seek the lowest cost tools that might leave their product with a competitive handicap in time-to-market and performance.
Developers today need a comprehensive development environment (IDE) and a real-time operating system (RTOS) to help them develop and achieve optimal performance for their application. But not only do developers need the best IDE and RTOS they can find, they need them to operate together to achieve maximum benefits. Each must be of high quality in its own right, but beyond that, they must be engineered to work together and to support each other’s strengths.The steps involved in the development of an embedded application are similar across the spectrum from small to large. A simple example can therefore be used to illustrate how the capabilities of an integrated IDE and RTOS make real product development easier and more effective. The Host-Target configuration might look something like this:
Developing an embedded application involves many steps, including:
Application design
Write source code
Compile code
Link libraries
Download executable to a target board
Run the program on the target
Set breakpoints
Stop the program
Analyze data from the running application
Each of these steps can be handled by an IDE, with its component editor, compiler, linker, and debugger.Especially in the more complex applications, the developer might elect to use an RTOS to schedule application threads, pass messages, and use semaphores and mutexes. The RTOS also should be able to capture event trace information in real time, and enable those events to be viewed graphically on the host. This is critical in a real-time system, since so much happens so quickly that a “big picture” view helps sort things out. An event trace display shows exactly what RTOS services and application-defined events each thread has performed. It also can collect and summarize performance statistics including a complete execution profile, a summary and individual display of all context switches, and a wealth of other useful information.An example application
To illustrate how these RTOS/IDE capabilities can work together to help the developer, consider a simple application. The application consists of 8 threads, "thread_0" through "thread_7." These threads each perform a particular function in an endless loop. The threads are each assigned a priority, from 0 (the highest) to 1024 (the lowest). At any point in time, the RTOS runs the highest priority thread that is “READY” to run. A thread is READY when it is not waiting for anything outside of its own code – for example, waiting for a message to arrive from another thread. In such instances of waiting, a thread is "SUSPENDED" and is not READY to run. Here is a summary of what each thread does:The RTOSA priority-based, preemptive scheduling RTOS, ThreadEx, is used in this demo to manage the eight application threads. Using this example, developers can also understand several services, including messaging, semaphores, mutexes, and sleep and experiment with them in code of their own.To follow the application’s flow and specific actions, the RTOS time-stamps each event and stores related information regarding the event in a circular buffer on the target. This buffer is uploaded to the host and displayed there to reveal the time-based flow of events.The IDEIAR Embedded Workbench for ARM is the development IDE for this demo. This IDE has been tightly integrated with the RTOS, and 4 areas of integration are noteworthy:Project Compatibility. The RTOS is provided in a format that enables it to be used from within the IDE’s project structure. All source code is syntax compatible with the IDE’s compilers and assemblers, making the RTOS ready to use right out-of-the-box.RTOS Awareness. This IDE plug-in captures and displays a wealth of information for all application threads and other defined objects, each time the system is stopped (at a breakpoint or a HALT command).One such display, shown above, is the “Execution Profile.” This is a unique information capture and display that shows profiling information for the application’s threads, interrupt system, and idle time, with a separate breakdown by thread. Note the overall application profile, showing the breakdown of execution time by Idle, Interrupt, and Application. Also, note the individual thread performance profile. As you can see, threads 1 and 2 indeed dominate performance, as described earlier.Macro Operations. Using the IDE’s Macro capability, the IDE can automatically and optionally upload the trace buffer to the Host at a breakpoint. This simplifies and speeds up the process of running the program and then viewing the event trace to see what happened.Launch an External Tool. Another convenient capability enables the launch of an external tool through the “Tools” menu. This can be used to quickly and easily launch a software systems event analyzer—from the IDE.
The Application BuildNormally, to build an application, the developer would have to go through the following steps:Create a new projectAdd a source file to the projectType in the source codeBuild the RTOS libraryAdd the necessary board initialization filesSet compiler, linker, library, and other configuration settingsBuild the application In an IDE with tight RTOS integration, the task becomes much simpler and less error-prone. The RTOS is provided with a sample application, which includes a pre-built RTOS library, application source code, header files, initialization code, and linker directives. It is intended for debugging, with all profiling and trace operations activated, and minimal optimization.This enables the developer to immediately scan the demo code, study the project settings, and only make changes where desired.Breakpoints and MacrosBefore running the application, the developer might set a breakpoint in the code for “thread_0.” Since this thread runs every 10ms, it provides a predictable point at which to examine the events that have transpired over that period of time.Each time this breakpoint is reached, the value of thread_0_counter increments by one, as shown in the debugger’s Watch Window, where expressions can be viewed. But also, the trace buffer can be uploaded automatically from target memory to the Host. This is helpful in case the developer decides to view the events. This is where the IDE’s macro capability can be used. A macro can be performed by the debugger by listing the macro in the breakpoint edit window, as shown below.This is a powerful capability that has many uses. In addition to executing a macro, developers can instruct the program to “continue” after encountering the breakpoint or remain stopped at the breakpoint. We also can tell the debugger not to stop for the first “n” occurrences of the breakpoint, and stop on the “n+1”. Also, a Boolean expression or condition can be evaluated and used to determine whether to stop at the breakpoint. These features give the developer tools to use to help examine what is happening at a particular point in the programRTOS AwarenessMany IDEs offer RTOS Awareness, but all RTOS Awareness implementations are not the same. In addition to tracking all application threads and kernel objects (semaphores, mutexes, queues, etc.), IAR Embedded Workbench for ARM also displays the RTOS Execution Profiling information. In our example, it provides a view of all threads. This is just one of several views available. Note the tabs for other views.Event TraceAn event trace can be a most useful tool for understanding the behavior of a real-time system. While stopped at a breakpoint, we can easily view the events with a single mouse-click, thanks to another IDE capability – the ability to launch an external tool.In this case, the external tool we launch is TraceX, which runs on the Host and provides a timescale view of system events and it can be used to measure the time between events. This provides a valuable measurement tool for determining the time taken to progress from one point of a program to another. As shown below, the highlighted span is 172.5 microseconds. By highlighting the start and stop events of interest, developers have a handy means of examining not just what was done, but how long it took.
Summary: An IDE that is tightly integrated with an RTOS can simplify many of the otherwise tedious operations that a developer must perform in order to run and debug an application. Beyond assuring correctness, this information enables developers to optimize the performance of the application, and to make tradeoffs between responsiveness and throughput, which are often opposing goals.
No comments:
Post a Comment