8 software must-have tricks on the road to hardware engineers

Embedded system design should not only understand the hardware, but also understand its interaction and role with the software. Hardware design requires a certain design paradigm, which is not so applicable to software design. How to transition from simple hardware design to hardware and software design, you need to pay attention to the following eight software design skills when you start developing software.

1. Design control flow chart

Engineers can't help but start writing code when they get to the point of developing software. This mindset is like trying to draw a PCB before the schematic is even finished. When developing software, it is important to resist the urge to write code and instead design a diagram of the software process structure. Flowcharts clearly represent the components of a developer's software, just as a schematic lists the components needed for a hardware design. This will greatly make the program easier to organize as a whole, and it will also reduce the debugging workload that takes up a long development cycle, thereby saving time and reducing the tediousness of debugging.

2. Use the state machine to control the program flow

The state machine is one of the excellent software inventions of the 20th century. Applications are generally broken down into different states, each controlling a specific branch of the program. The state machine includes internal states and state transitions controlled by different stimuli. Using state machine mechanism design software makes modular, maintainable software development easier and easier to understand. Examples of state machine principles and algorithms can be found everywhere.

3. Avoid using global variables

In the past, programmers used functions to write programs, and their sole goal was to make the program run as fast as possible, regardless of the structure and reusability of the program. This type of program style uses global variables without paying attention to the scope of the variable, which causes the danger of modifying other functions. This way the variable will be occupied and rewritten multiple times. In today's object-oriented programming, member variables are defined within a minimum scope and encapsulated to avoid re-complexing and abuse. Therefore, it is recommended to use as few global variables as possible, and use the keyword "extern" in C language to modify it if necessary.

4. Make full use of the modular design concept

If you ask an engineer which part of the project is most likely to delay delivery and exceed the estimated time, the answer must be the software cycle. Software is often complex and difficult to develop and maintain, especially when project applications are grouped together in a single file, or several loosely structured files. In order to facilitate code reuse, software maintainability, and reduce software complexity, it is strongly recommended to take advantage of the modularity of high-level programming languages and separate common functions into independent modules in the structure of the program. This allows programmers to start creating commonly used functions and declaration definitions that can be easily reused by other code, which not only saves time but also improves the quality of the code in the later testing phase.

5. Keep service interruption events concise

An interrupt service event is a mechanism by which the interrupt handler processes a program that is executing and instead processes the request of the peripheral that triggered the interrupt. The processor requires a lot of system overhead to respond to the interrupt request, which is manifested in saving the state of the interrupted program (the segment address of the next instruction in the stack, the offset address and the program state register, and sometimes the value of several registers in the stack), executing the interrupt service program and then resuming the break point to continue executing (out of the stack registers in turn), although the current processor speed is very fast, but this system overhead still needs to be considered. In general, in order to avoid conflicts with the main program, programmers always want to minimize the interrupt execution time. This means that service interruption events should be short and simple. Functions cannot be called in interrupt programs. In addition, if the interrupt needs to be processed is particularly complex or takes a long time, the interrupt service program should meet the minimum requirements, such as loading data into buffer registers, setting flag bits, and letting the main program process the read data. In this way, most of the processor's work cycle is processed rather than interrupted.

6. Test the device using the processor sample code

For hardware design, standard test circuitry before the artboard helps engineers understand the characteristics of the circuit. The same applies to software design, where semiconductor manufacturers often have sample programs that test the functionality of each part of a microprocessor, providing engineers with an experience of how each part works. This allows you to organize the structure of the software in advance and anticipate problems in the design. Identifying potential obstacles in design in advance is far more scientific than discovering problems hours before the product is completed. It is worth noting that the code provided by the manufacturer is usually not modular, and it is difficult to use it directly in the actual software without making necessary modifications.

7. Control the complexity of the function

There is a saying in engineering design called "KISS", which means "Keep It Simple Silly". The easiest and most effective way to deal with some complex tasks is to break them down into several simple subtasks, and when the task or function is very complex, it is difficult for people to pay attention to all the details and not make mistakes. When an engineer writes a complex function that can be understood at the time, but needs to maintain the program after a period of time, it is worth considering whether the original design idea can be clearly presented. There are a number of techniques to measure the complexity of a function, such as "cyclic complexity". Experience tells us that it is better for functions to have a cyclic complexity of less than 10.

8. Detailed documentation

In the fierce competition of software development, it is easy to focus on writing and debugging code and neglecting documentation. Sometimes under pressure, developers usually arrange the documentation in the last part of project development. However, writing documentation for code should be more critical when it is still clear in your mind, so that you can quickly recall the design ideas of that time when you develop or read the comments yourself