The most common work of hardware designers is to test the hardware by writing code. These 10 C language skills (C language is still a common choice) can help designers avoid certain defects caused by basic errors and cause maintenance problems.
In order to successfully launch a product, the software development process itself needs to experience numerous practical risks and obstacles. The least desired thing for any engineer is the challenge of using the language or tool. Therefore, this requires the hardware designer to write code to test the working condition of the hardware. In the case of limited resources, it also needs to develop hardware and embedded software. Although there have been great advances in tools and structured programming, the choice is still usually made in C language. The constant occurrence of basic errors will still cause some defects and cause maintenance problems. In an effort to avoid these C programming traps, here are 10 C language tips for hardware engineers.
Tip 1: Do not use the "GOTO" statement
Two decades ago, when computer programming was still in its infancy, program flow was controlled by the "GOTO" statement. This type of statement allows the programmer to break the current line of code and go directly to a different piece of code. Listing 1 is a simple example.
List 1 uses the GOTO statement
Finally, programming languages ​​have introduced the concept of functions that allow programs to break code. If it is done, goto statements are no longer used to indicate line breaks. After the function is called, the function will return to the next instruction. Listing 2 is an example. This approach improves the program structure and improves readability. Since then, this is seen as the correct way to write programs. Just seeing or thinking about the goto statement will make the software engineer back down and instinctively hate it. One of the main reasons is that a program that is spread over goto statements can make it difficult to grasp the focus, and it is not easy to understand and maintain the program.
Listing 2 Controlling Processes with Functions
Tip 2: Use FOR(;;) or While(1)
If the goto statement is out of date, then how do you create an infinite loop for the program? This is a question that some hardware engineers may wonder. After all, it was all done by creating a goto statement and then returning to the main statement. The solution to this problem is to use the looping statements for and while (Listings 3 and 4) that already exist in the C language.
Listing 3 uses an infinite For loop
Listing 4 uses an infinite While Loop
The loop conditions in the list are relatively simple. A for loop is nothing more than using conditional statements without conditions. On the other hand, the while loop is executed when the statement is true, which is equivalent to a non-zero value for any condition.
Tip 3: Use the right conditional statement
In addition to the readability of the code, the execution time of the program mainly depends on the type of conditional structure selected when making the decision. Many hardware engineers are familiar with the use of simple if statements. However, sometimes engineers may not realize that if the first condition is incorrect, else or else if statements can be used. This saves processor time without having to evaluate another conditional statement. In the first half of the code shown in Listing 5, if the Var is 1, the code will still check if Var is 0. In the latter part of the code that uses the else statement, only the first statement is evaluated, and then the following code is continued. This saves clock cycles and makes the code clearer.
Listing 5 Replace Only If with If/Else
If/else if/else statements may not always apply. If you need to check several possible conditions, the switch statement may be more appropriate. In this way, the processor can evaluate the statement and then select the next action from a list of answers without continuously evaluating a bunch of conditions. Listing 6 shows the same example as Listing 5.
Listing 6 using the Switch statement
The moral of the above example is to make the choice of conditional statements more open in order to choose the most appropriate statement. This approach makes the program structure simpler, easier to understand the program flow, and shorten the processor's extra clock cycles.
Tip 4: Avoid Assembly Language
The natural language of microprocessors is assembly language instructions. Programming low-level machine language may provide more efficient code for the processor. However, humans are not born with this language, and experience has shown that writing assembly language can cause misunderstandings. Misunderstandings can lead to improper maintenance, and even worse, it can make the system full of bugs. It is generally recommended to avoid using assembly language. In fact, most compilers now compile very efficient code. The development of high-level languages ​​such as C or C++ can achieve a more orderly structure, facilitate understanding and maintenance, and make the overall effect of the code better. Listing 7 shows an example comparing assembly code and C code used to increment a 32-bit variable.
Listing 7 Incrementing a Variable in Assembler and C
compilation
C code
Of course, there are still some occasions where assembly language is suitable, but this is still relatively rare. The first recommended case is to develop a boot loader. In this case, you may need to optimize the speed of a decision (starting the application or boot loader) during the startup process. At this point, it may make sense to use assembly code for branch determination. Another occasion is to develop a control loop that runs on the DSP with strict timing requirements. In order to get every clock cycle from the device, it is meaningful to use the assembly language as the control loop. If the current task is suitable for assembly, it should be ensured that it is properly documented for easy documentation so that future developers (or future versions) will understand the purpose of the code.
Tip 5: Take full advantage of modularity
The author's most common experience is that a new project initiated by a hardware engineer is often a cluttered code organization. Usually we will find that the code consists of a single main module, which has more than 25,000 lines of code. In these applications, everything is global, there are few functions, goto statements throughout the code structure. This was normal 15 years ago but it is no longer applicable! C-language programming allows engineers to break code into separate functional blocks, which simplifies code navigation and enables engineers to use object-oriented technologies such as packaging. The code can be organized into logical modules, which makes sense. Although it may take some time (a few minutes), in the long run, it will save you a lot of long nights and lots of debugging pain!
Tip 6: Write a layer of cake-type code instead of spaghetti code
Beningo is an Italian name. Like many Italians, I have no reservations about Italian pasta. When comparing pasta with software, I would think of two kinds of pasta, spaghetti and a thousand layered cake. The spaghetti is confusing and the noodles are intertwined and criss-cross, resulting in no type of structure at all. Writing unstructured code is very much like spaghetti: take a bite and don't know what part to eat.
The other is Italian Melaleuca! This pasta is layered and structured. The code developed in layers is not only easier to understand, but also removes one layer and adds a new layer, which basically enables the ease of reuse and maintenance. Figure 1 shows an example of a simple software module using the layer cake model.
Figure 1 Melaleuca software model
Driver configuration
Application configuration
application
Driver library
hardware
Tip 7: Use Descriptive Variable Names
There are many obstacles to writing large software that is easy to understand and maintain. One of them is the naming convention of variables. In an effort to shorten variable names, developers often create short, puzzling mnemonics, often only symbols they can understand. Modern languages ​​allow a variable name to contain hundreds of characters. To make things clear and clear, "straightforward" methods are better than other methods. Therefore, the variable names at a glance are not only beneficial to developers but also to future maintenance teams. Listing 8 gives an example.
Listing 8 Name the variable
Tip 8: Use #pragma Less
There is a special #pragma statement in the C language. These statements usually deal with non-standard syntax and characteristics. They should be avoided if possible because they are non-standard and cannot be ported from one processor to another. Some compilers may require such statements to accomplish a task, such as defining an interrupt service routine. In this case, there may be no other way than using the #pragma statement. If possible, put all #pragma statements in one module or several modules. This helps to ensure that when the code is ported, only a few pieces of code need to be updated, not the entire code base; in addition, this will also help prevent the headaches of the first compilation of the ported code.
Tip 9: The error is often not as simple as it looks
When debugging a C program, one pitfall is the compiler error. Due to the complexity of the compiler, when an error is detected, the error is usually located elsewhere in the program rather than at the position indicated by the compiler. This is mainly related to the steps that the compiler generates the program. The type of error is usually the same, and 90% of the errors that engineers can find are root causes:
* Beware of missing #include files. This may cause the program developer to see the perfect line of code, but because the necessary header file is not included, the compiler flags it as an error, indicating that something is not defined.
* Watch out for missing semicolons. The most common mistake when writing C code is to forget to add a semicolon at the end of a sentence.
* Beware of missing the brackets. Leaving the parenthesis is another common mistake in the code writing process, either because of carelessness or because of mistyped characters.
* Watch out for missing commas. It's easy to forget the comma in a complicated definition!
In general, when a strange compile error dialog pops up, you need to see what has been compiled before the line. It is very likely that the error is! It may appear on top of a line, or in the middle, or in a completely different file.
do not give up! With certain experience, solving these difficult issues will become a second nature.
Tip 10: The number of lines of code written by a good programmer is not necessarily small
People often have this kind of misunderstanding, that is to say that a better programmer usually writes fewer lines of code to solve the problem than the average programmer. Don't get caught in this wrong idea! A good programmer usually has a coded and well-structured coding basis. Variable naming and encapsulation are just right, and there are few global variables in the system. The function should remain short and effective. If your code looks confusing and you need to write a few more lines to make it look cleaner, you might as well write a few more lines! You can go online and see the code that gets the most out of the C code to write the most outrageous awards as a lesson. The code written by good programmers is concise, easy to understand and maintain, and the number of lines of code is not minimal (Figure 2)!
Figure 2 Short program
Ningbo Autrends International Trade Co.,Ltd. , https://www.vapee-cigarettes.com