8 software tricks on the road to hardware engineers

Embedded system design should not only understand the hardware, but also the interaction and interaction between it and the software. Hardware design requires certain design examples, which are not so applicable to software design. How to transition from pure hardware design to a combination of hardware and software design, you need to pay attention to the following eight software design skills when you start developing software.

1. Design the control flowchart

When engineers get to the step of developing software, they can't help but start writing code. This mindset is like trying to draw a PCB before the schematic is finished. When embarking on software development, it is important to resist the urge to write code and replace it with a design of the software process structure diagram. The flowchart clearly presents the required components of the developer's software, just as the circuit diagram lists the various components required for hardware design. Doing this can greatly make the overall program easier to organize, and it will also reduce the debugging workload that accounts for a long development cycle, thereby saving time and reducing the tedious debugging process.

2. Use the state machine to control the program flow

The state machine is one of the outstanding software inventions of the 20th century. Applications are generally decomposed into multiple different states, each of which controls a specific branch of the program. State machines include internal states and state transitions controlled by different stimuli. Using state machine mechanisms to 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, in functional programming, programmers used functions to write programs with the sole goal of making the program run as fast as possible regardless of program structure and reuse. This style of procedure uses global variables without paying attention to the scope of the variables and the danger of modifying other functions. This allows the variable to be occupied and overridden multiple times. In today's object-oriented programming, member variables are defined within a minimum scope and encapsulated to avoid re-valuation and abuse. Therefore, it is recommended to use as few global variables as possible, and if necessary, use the keyword "extern" in C to decorate it.

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 estimates, the answer must be the software cycle. Software is often complex and difficult to develop and maintain, especially when project applications are concentrated in a single file, or in several loosely structured files. In order to facilitate code reuse and software maintainability and reduce the complexity of software, it is strongly recommended to take advantage of the modular nature of high-level programming languages, and separate common functions as a separate module in the structure of the program. This allows programmers to start creating definitions of common functions and common declarations, which can be easily reused by other code, which not only saves time and money but also improves the quality of the code in later testing phases.

5. Keep service interruption events simple

An outage service event is an outageprocessorA mechanism for executing a program that instead processes requests from peripherals that trigger the interrupt.processorResponding to interrupt requests requires a lot of system overhead, which is manifested in saving the state of the interrupted program (the segment address, offset address and program status register of the next instruction on the stack, and sometimes the value of several registers on the stack), executing the interrupt service program and then resuming the interrupt point to continue execution (in turn out of each register on the stack), although the current processor is very fast, but this system overhead still needs to be considered. In general, to avoid conflicts with the main program, programmers always want to minimize interrupt execution time. This means that interrupt service events should be short and simple. You cannot call a function in an interrupt program. In addition, if the interrupt needs to handle an event that is particularly complex or takes a long time, the interrupt service should meet the minimum requirements, such as loading data into buffer registers, setting flags, and letting the main program process the read data. In this way, the processor spends most of its work on handlers rather than interrupts.

6. Test the device with processor sample code

For hardware design, standard test circuits before drawing boards help engineers understand the characteristics of the circuit. The same can be applied to software design, where semiconductor manufacturers often have sample programs that test the functionality of various parts of a microprocessor to provide engineers with a sense of how each part works. This allows the structure of the software to be organized in advance and to anticipate problems in the design. Identifying potential design roadblocks in advance is far more scientific and reasonable than identifying problems hours before the product is complete. It is important to note that vendor-supplied code is usually not modular, and it is difficult to use directly in actual software without 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 simplest and most effective way to deal with some complex tasks is to break them down into simple subtasks, and when the task or function is very complex, it is difficult to pay attention to all the details and it is difficult not to make mistakes. When an engineer writes a complex function that can be understood at the time, but after a period of time, the program needs to be maintained, and whether the original design idea can be clearly presented is worth considering. There are a number of techniques to measure the complexity of a function like "loop complexity". Experience tells us that it is better for the loop complexity of functions to be less than 10.

8. Detailed documentation

In the fierce competition for software development, it is easy to limit the focus of attention to writing and debugging code and neglect the writing of documentation. Sometimes under pressure to write documentation, developers usually schedule documentation to be written centrally at the end of the project's development. However, writing documentation for code should be more critical when the mind is still clear, so that you can quickly recall the design ideas at that time when you develop later or read comments yourself