In embedded software development process, in general, spent testing and spent time coding ratio of 3: 1 (actually probably more). With this ratio to improve your programming and testing levels and declining, but no matter what software testing is very important to the average person. Many years ago, a developer in order to have a deeper understanding of embedded, to the Oracle asked such a question: how can I know and understand my system in the end in doing it Oracle Faced with this problem a bit surprised? , because at the time so no one asked, and contemporary embedded developers around most of the most-asked "how can I make the program run faster", "what the compiler is best" and other superficial issues. So, faced with this unusual problem was egregious mature, Oracle, and delighted his reply carefully: Your question is very deep very mature, because only continue to go in-depth understanding it possible to continuously improve the level. And Oracle in order to encourage the dedication of the programmers, the 10 tips on embedded software development and testing, told him:
1. know how to use tools
2. discover memory problems early
3. In-depth understanding of code optimization
4. Do not let yourself needle in a haystack
5. reproduce and isolate problems
6. to retreat
7. Determine the integrity test
8. improve code quality means to save time
9. find it, analyze it, solve it
10. Using thinking beginners
These ten tips widespread in the industry, many people benefit. This paper focuses on these ten tips to start on.
1. know how to use tools
Embedded systems are usually relatively high demands on reliability. Embedded system security failure could lead to disastrous consequences, even non-security system, due to the mass production can lead to serious economic losses. This requires embedded systems, including embedded software to rigorous testing, validation and verification. As more and more areas of use of the software and microprocessor control various embedded devices, door increasingly complex embedded software become more rapid and effective testing more important.
As required repair tools, a good programmer should be able to skillfully use a variety of software tools. Different tools have different scope, have different functions. Using these tools, you can see your systems are doing, what resources it occupied it in the end what the outside world and deal with things. Let your problem may be depressed for several days can easily get through a tool, but unfortunately you just do not know. So why are so many people always think after tossing half to death to use testing tool was it? Many reasons, there are two. One is fear, and the other is inert. Fear because the test harness or test module added to the code requires skill with the possibility of introducing new errors, so they always like to hope to eliminate the bug by constantly modifying recompile the code, only to no avail. Laziness is because they are accustomed to using printf simple test methods and the like. Here are some embedded commonly used test tools.
. Source-level debugger [Source-level Debugger]
This generally provides a single-step debugger or stepping, setting breakpoints, memory testing, variable view and other functions, is the most fundamental and effective embedded debug debugging method. Such as VxWorks TornadoII provided gdb to belong to this one.
Simple and practical tool for the print show [printf]
printf print or other similar display tools estimated to be the most flexible and simple debugging tool. Variables During the print code can let you know the situation in code execution. However, normal code execution printf interference is relatively large (typically longer printf CPU-time), should be carefully used, it is preferable to set the print switch to control printing.
.ICE or JTAG debugger [In-circuit Emulator]
ICE is a device used to simulate the core CPU, it can not interfere with the normal operation of the arithmetic unit, the internal operation of the CPU real-time detection. Complex conditional breakpoints, advanced real-time tracking, performance analysis, and port analysis of these functions, it can provide: like a desktop debugging software provided. ICE generally have a special CPU, a co-called external (bond-out) CPU. This is a CPU of the package was opened, and by special connection, CPU can access to the internal signals, and these signals are encapsulated in the CPU, is not "seen". When and powerful debugging software on the workstation used in combination, ICE can provide the most comprehensive debug features you can find. However, ICE also has some drawbacks: expensive; can not work at full speed; Similarly, not all of the CPU can be combined as a CPU outside of, say, these foreign joint CPU is unlikely to be timely by the new CPU out from another angle replace. JTAG (Joint Test Action Group) Although it was originally developed to monitor the IC and circuit connections, but the use of this extended serial interface, including support for debugging. AD Blackfin company Visual Dsp ++ designed to support high-speed JTAG debugging.
.ROM Monitor [ROM Monitor]
The ROM monitor is a small program embedded systems residing in the ROM, and run by a serial connection or a communication network debugging software on the workstation. This is a cheaper way, of course, most low-end technology. It requires in addition to a communication port and a small amount of memory space, the other does not require any special hardware. And provides the following functions: downloading code, run control, breakpoints, single step forward, and observe, modify registers and memory. Because the ROM monitor part of the operating software only when your application is running, it will work. If you want to check the status of CPU and applications, you must stop the application, enter the ROM monitor again.
.Data Monitor [Data Monitor]
This monitor without stopping the operation of the CPU may display only specified contents of the variable, changes may also collect and display process of each variable in graphical form.
.OS Monitor [Operating System Monitor]
OS monitor can display, such as task switching, transceiver semaphore, event interrupts. On the one hand, these monitors can show the relationship between the event and the time to contact you; on the other hand, can also provide diagnostic priority inversion of semaphores, deadlock, and interrupt latency and other issues.
Performance analysis tools [Profiler]
It can be used to test the CPU in the end consumption there. profiler tool lets you know where the bottleneck of the system, CPU utilization and optimization of local needs.
Memory testing tool [Memory Teseter]
Memory usage can be found in the problem, such as memory leaks, memory fragmentation, memory corruption and other issues. If you find some unpredictable system of intermittent problems or, you should use memory testing tool Cece see.
Run Tracker [Execution Tracer]
Which you can display CPU perform the function, who is calling, what the parameters are, when to call and so on. This tool is mainly used for test code logic, those exceptions can be found in a large number of events.
Overlay tool [Coverage Tester]
The main display those CPU specific implementation of the code, and let you know that the code is not executed to branch. This helps improve code quality and the elimination of useless code.
.GUI testing tool [GUI Tester]
Many embedded applications with some form of graphical user interface to interact, some of the root system performance testing enough time to dig in response to user input. GUI test tools development environment can run test cases as a scripting tool, its features include recording and playback operations, grab the screen for later analysis and comparison, set up and manage the testing process (Rational's tools robot and Mercury's Loadrunner It is an outstanding representative). Many embedded devices do not have GUI, but often can be instrumented for embedded devices to run GUI test scripts, although this way may require changes to the code under test, but save time functional testing and regression testing.
Homemade tools [Home-made tester]
In embedded applications, sometimes for a specific purpose, we need to write some of their own tools to achieve some testing purposes. I had prepared a video stream recorded significant tool in the data flow and changes in the test video conferencing a big help, to help the company find a few hidden deep in the bug.
2. discover memory problems early
Memory Problems great harm, not easy to troubleshoot, there are three types: memory leaks, memory fragmentation and memory corruption. For Memory Problems attitude must be clear, that is, early detection and "treatment." In software design, memory leaks, "fame" the largest, mainly due to the continued allocation of memory can not be released in a timely manner, over time, the system runs out of memory. Sometimes even after careful programming will face veteran memory leak. Have tested the memory leak has profound experience of friends is estimated that the general hidden deep memory leaks, it is difficult to find reading through the code. Some memory leaks may occur even among libraries. This in itself is likely to library bug, it could also be because the programmer did not properly understand their interface documentation caused by misuse.
In many cases, most of the memory leaks can not be detected, but may appear as random failures. Programmers tend to put the blame on this phenomenon a hardware problem. If the user is not very high stability of the system, then reboot the system the problem is not large; however, if a user on the system stability is high, then this failure is likely to cause users to lose confidence in the product, but also means that your project is a failure of the project. Due to the huge memory leaks harm, now there are many tools to solve this problem. These tools are not referenced by looking up or re-use of code blocks, memory garbage collection, libraries, tracking and other techniques to find memory leak problem. Each tool pros and cons, but in general, with better than no good. In short, the developers should be responsible to test the memory leak problem, possible trouble.
Memory fragmentation deeper than memory leaks hidden. With the continuous memory allocation and release, memory constantly broken down into small chunks of memory, forming debris, over time, when the need to apply for large chunks of memory is likely to fail. If the system memory is large enough, then the stick will take longer, but eventually escape the allocation failure doom. In a system using dynamic allocation, memory fragmentation often occur. At present the solution to this problem is to use the most effective tools display system memory usage to find out who is the culprit cause memory fragmentation and improve the corresponding parts.
Because dynamic memory management problems in embedded applications, many companies simply to disable malloc / free is to never troubles.
RAM memory corruption is the most serious result, the main reason there are out of bounds array access, write the memory has been released, the pointer calculation error, the stack address cross-border access and so on. This memory corruption caused by system failures are random and hard to find, now offers tools for the investigation of the few.
In short, if you want to use the memory management unit, you must be careful and strict adherence to the rules of their use, such as who is assigned who is released.
3. In-depth understanding of code optimization
Talked about system stability, people will think of more real-time and speed, because the code efficiency of embedded systems is too important. You know how each optimized code is embedded software developers must have the skills. Like the girls, like weight loss, at least you know which place she was most in need of reduction, in order to buy medicine or equipment to lose weight lose it. Visible, code optimization on the premise that the real need to optimize the place to find, and then prescribe the right medicine to optimize the corresponding part of the code. The aforementioned profile (performance analysis tools, some of which provide full-featured IDE built-in tool) capable of recording various conditions such as CPU usage for each task, each task priority is assigned if appropriate, a copy of the data is how many times, how many times to access the disk, whether the program is called the network transceivers, test code is already closed, and so on.
However, profile analysis tool in real-time system performance where there are not enough. On the one hand, people use the profile tool is often a problem that is depleted in the system after the CPU, while the profile tool itself takes on a larger CPU, so the profile is likely to have no effect on this situation. According to Heisenberg effect, more or less any means to change the system test run, this also applies to profiler!
In short, improve operating efficiency on the premise that you need to know what CPU did in the end how to dry.
4. Do not let yourself needle in a haystack
Needle in a haystack is just a vivid metaphor for one debugging.
Group often hear someone say to yourself you are debugging code that shit! Understandable, because the code is not written by him, he has enough reason to shit bug ridden code as long as he do not write this kind of code, otherwise one day others in the same group may be the same shit his code. ? Why is there a haystack it certainly fell into the sea was slightly the needle;? Why is that needle will fall into the sea it is certainly careless or hasty chant. So when you complain about the needle so hard to find, do you think is your own hastily throw away. Similarly, when you debug a half to death when you thought you had to be a good reflection to seek shortcuts might not strictly comply with good coding design specifications, did not detect some of the assumptions or the correctness of the algorithm, some may not exist code issues marked with the marks? Please refer to on how to write high quality Lam "high-quality c ++ / c programming Guide" or "0x8 of this on C" by the book "."
If you really have to pin drop in the sea, in order to prevent before finding stab yourself, you have to do some preventive work, such as wear safety gloves. Similarly, in order to be able to expose and capture the best source of the problem, we can design a more comprehensive error tracking code. How to do it? Possible to deal with each function call fails to detect each parameter input and output as well as the effectiveness of including pointers to detect whether too much or too little to call a procedure. Bug Tracking lets you know you are probably the location at which the needle out.
5. reproduce and isolate problems
If you do not put a pin drop in the ocean, but lost in the haystack, it should be easier to write. Because at least we can put the straw into many pieces, piece by piece to find. For large projects module independent of the use of isolation method is often hidden deep against those final method of bug. If the problem occurs is intermittent, we need to find a way to reproduce the whole process to reproduce it and record it to prepare for the next time you can take advantage of these conditions to reproduce the problem. If you are convinced that those conditions can be used to reproduce the recorded question, then we can begin to isolate the problem. How isolated it? We can use #ifdef some possible problems and shut down independent code, the system is minimized to the point where still able to reproduce the problem. If you still can not locate the problem, then it is necessary to open the "toolbox" of. ICE can try to view or change data monitor a suspicious variable; you can use the tracking tool to get the case of function calls, including passing parameters; check whether the crash and the memory stack overflow problem.
6. to retreat
In order not to make himself a hunter lost in the woods, he often shed some of the tags on the trees to prepare to find a way out based on these marks when their own someday get lost. Code changes of the past track record of the future commissioning helpful after problems. If one day, the last time you modified program suddenly died after a long run, then you first reaction is that this time I change something in the end of it, for it is good before last modified. So how this modification detection with respect to the last of it? Yes, the code control system version control system called SCS or VCS (Concurrent Version Control, CVS is the evolution version of VCS). And compare the current test version of the previous version check in down. Comparison tools may be SCS / VCS / CVS diff carrying tools or other more powerful comparison tools, such BeyondCompare and ExamDiff. By comparison, a record of all changes to the code to analyze all suspicious code can cause problems.
7. Determine the integrity test
How do you know how full your test it? Coverage Test (coverage testing) can answer this question. Coverage testing tool can tell you the CPU in the end the implementation of those codes. Good coverage tools can usually tell you about 20% to 40% of the code is not the problem, but others may exist bug. Test coverage tools have different levels, the user can select a level according to their needs. Even if you are sure your unit tests have been very comprehensive and there is no dead code, coverage tools, or can point out some potential problems for you, look at the following code:
if (i >= 0 && (almostAlwaysZero == 0 || (last = i)))
If almostAlwaysZero non-zero, then the last = i assignment to be skipped, this may not be what you expect. This problem can easily be found by conditional test coverage tool functionality.
In short, the coverage test is helpful for improving the code quality.
8. improve code quality means to save time
Research has shown that software development for more than 80% is used in the following aspects:
Debug your code (unit testing)
. Debug their code and other relevant (inter-module testing)
Debug the entire system (system test)
Worse, you may need to spend 10 to 200 times the time to find a bug, and this bug at the beginning may be very easy to find. A small bug that might make you pay a heavy price, even if the bug is not much impact on the overall system performance, but is likely to affect the part you can make those visible. So we have to develop good coding and testing means higher code quality in order to shorten the code debugging.
9. find it, analyze it, solve it
This world is not a panacea plaster. profile also powerless again, when powerful; memory no matter how good the monitor, but also can not find the time; coverage tools then useful, but also a place not covered. Some of the problems hidden deep exhausted all means even if there may not be found in its roots, then we can do is through these issues demonstrated by the external phenomena or some of the data output to spot patterns or anomalies. Once any abnormality, be sure to thoroughly understand and back its roots, until resolved.
10. Using thinking beginners
Someone once said: "Some things may be a variety of situations in the beginner's mind, it is likely to be single in the minds of the experts in." Sometimes, some simple questions will be to the very complex, very complex and some other simple system design, it is because of your "expert thinking." When you are stumped by the problem, turn off the computer, get out, put your question and your friends or even your dog talk, perhaps they can give you an unexpected inspiration.
Summary: Embedded Debugging is an art. I wanted other arts, if you want to succeed, you must have the wisdom, experience and know how to use tools. As long as we can well comprehend these ten tips Oracle, I believe we can be successful in the embedded testing.
Reproduced in: https: //www.cnblogs.com/leaway/archive/2006/12/09/586900.html