Microcontroller "language" specification

　　I have found in many years of teaching that the most difficult part of learning single-chip microcomputers is programming. Looking through the current single-chip microcomputer textbooks, the hardware part and the knowledge explanation part are basically the same, only the programming part is really varied and colorful. Just imagine, facing a variety of programming materials, how can students know where to start? It is no wonder that most students think that programming is only a matter for individual students and has nothing to do with them.

　　This is the teaching situation of single-chip microcomputer in school. What about the learning situation of single-chip microcomputer in society? With the development of electronic component technology, the production of hardware circuits is becoming simpler and easier. Some devices can directly solder the pins together, and can even be used without connecting with a circuit board. What makes people feel headache is programming.

　　Especially amateur MCU enthusiasts, who have not received professional programming language training, mostly use programs written by others, or at most modify other people's programs. When we read articles about MCU production, most of the content is about introducing the principles. When it comes to programming, it is often just about where to download it. To be honest, the programming language just appears in the article. People who understand it don't need to read it, and people who don't understand it can't understand it either, which is a thankless task.

　　Is it true that learning programming is "rules and rules" and that teaching programming can only be done "improvisationally"? After years of teaching practice, I have explored a programming method that has achieved very good teaching results. I will temporarily call it the "language" specification of the microcontroller.

　　How does the MCU "speak"? Since the MCU assembly language is called "language", it is similar to our natural language. For example, it has sentences, and the sentences must conform to grammatical rules.

　　When it comes to the word "standard", some friends will say that since it is a "language", as long as the sentences and grammar are correct, you can say whatever you want, write whatever you want, as long as the compilation is passed and the functions can be realized, is there any need for "standards"? The answer is, of course it is necessary. We also need to have standards when learning natural language. Don't we call the articles in the Chinese textbook "model essays"? Of course, the use of natural language can be very flexible and free, but it also depends on what kind of article it is. For articles such as poetry and prose, the use of language can be very flexible, while for some practical documents, the use of language must be restricted. For example, when we learn to write leave requests, missing person notices, meeting notices and other articles, we must follow certain formats. When we are writing practical documents, only by following these "formats" can we write qualified practical documents.

　　Assembly language is the language we use to deal with microcontrollers. We use assembly language to "talk" to the microcontroller and let it obey our commands. First, it must understand our "talk", that is, to use the instructions correctly. The "brain" of the microcontroller is not as smart as our human brain. We can guess what the other party means when we talk, but the microcontroller can only execute our commands strictly according to our agreement. The second is how to "talk". Assembly language belongs to engineering language, and the essence of engineering language is specification. Its rules are more rigorous and the writing requirements are more stringent. The more standardized and rigorous the language is, the more it should be based on laws to learn. And if we find this "law", our learning will take a big step forward. What kind of specifications are there in assembly language?

　　When teaching assembly language, we first emphasize to students that assembly language programs are composed of three parts: ① predefined part; ② main program part; ③ subroutine part. This is the standard format for writing assembly language programs. Of course, some simple programs may lack a certain part, but we still emphasize to students from the beginning that simple programs should try to write these three parts. Because as the content of the program increases, the importance of the structure and hierarchy of these three parts will become more and more apparent. Below we take the simplest single-chip microcomputer control circuit as an example to introduce this standard program writing method, and introduce the content and meaning of each part one by one.

　　Figure 1 is a circuit diagram of the three pins p0.1, p0.2, and p0.3 of the single-chip microcomputer system and the three light-emitting diodes. From Figure 1, we can see that as long as we control the potential of the three pins p0 of the single-chip microcomputer, we can control the on and off of the three LED lights at will. Our control requirements are: LED1 turns on for 1s and turns off for 1s, then LED2 turns on for 1s and turns off for 1s, then LED3 turns on for 1s and turns off for 1s, and ends.

Figure 1 Circuit connection diagram of single chip microcomputer system and LED

　　The circuit function is very simple, and the programming idea can be described as follows. See Figure 2.

Figure 2 Circuit editing ideas

　　Programming is also very simple. Most people think that programs can be written directly. Please see the program example 1 below.

　　//Program function: three LED lights turn on and off for 1s in turn

　　start: clr p0.0 //Light up the first LED

　　acall delay1s

　　setb p0.0 //Turn off the first LED

　　acall delay1s

　　clr p0.1 //light up the second LED

　　acall delay1s

　　setb p0.1 //Turn off the second LED

　　acall delay1s

　　clr p0.2 //Light up the third LED

　　acall delay1s

　　setb p0.2 //Turn off the third LED

　　acall delay1s

　　ajmp $ // standby state

　　delay1s: //delay 1s subroutine

　　mov r5,#50

 

　　d3: mov r6,#100

　　d2: mov r7,#100

　　d1: djnz r7,d1

　　djnz r6,d2

　　djnz r5,d3

　　ret

　　end //End of program [page]

There are also rules for "speaking"

　　After compiling, downloading and running the above program, it can fully realize the expected functions. However, we have to say that this kind of program is not written in a standardized way.

　　This is like when we write an article, it can only be regarded as a draft. Although the meaning is clear, some syntax does not conform to the standard, and the structure is not clear, so it cannot be regarded as a qualified article. So, what are the requirements for standard writing? Let's take a look at the three parts of standard writing.

　　The first part of the standard writing is "predefined". The predefined part requires us to define a name for the interface when using the microcontroller pin interface, instead of directly using the microcontroller interface name. For example, we should not directly use p0.0 in the program. In addition, when we use the storage unit in RAM, we should not directly use the unit address, but also define a unit name for it in the predefined part. For example, if we want to store a count value in the 30h storage unit, we can write the "counter equ 30h" statement in the predefined part, and then in the program, we can directly use the name "counter". The advantage of writing in this way is that if the pin interface of the microcontroller in the circuit changes in the future, or the storage unit needs to be modified, we only need to change it in the predefined part, and the program part does not need to be changed at all. This is the convenience of predefinition.

　　The distinction between "main program" and "subprogram" is even more important. Let's put it this way. When writing a program, we'd better not put the program segment that can realize certain specific functions in the main program, but write it as a subprogram. For example, in the program example above, the delay program of 1s is written as a subprogram, which is good, but the functional program segments that make the LED light on and off should also be written as subprograms, which will be better. Then a friend asked, if you have written it as a subprogram, what does the main program do? Well asked, in fact, when writing a program, we try not to let the main program do specific things, because it has more important things to do. We leave the specific things to the subprogram, and for the main program, we let it play the role of commanding, coordinating, and checking the work of the subprogram. See, the relationship between the main program and the subprogram is like this. The main program is our brain, and the subprogram is our hands and feet. They are in a command-and-being relationship. So, how does the main program "command" the subprogram? Specifically, it is "calling".

　　From the beginning of writing a program, we should establish three modules in our minds: "predefined", "main program" and "subprogram". When writing the program, we fill the content into these three modules, and this is what we call standard writing.

　　Based on this idea, how should the program in Example 1 above be written to comply with the standard? Please see the program Example 2 below.

　　//Program function: The three LED lights turn on and off for 1 second in turn (rewrite using standard writing)

　　//Part 1: Predefined

　　led_light1 bit p0.0 //define pin

　　led_light2 bit p0.1

　　led_light3 bit p0.2

　　org 0000h //Program start

　　ljmp main

　　org 0030h

　　//Part 2: Main program

　　main:

　　acall led1 //Call led1 subroutine

　　acall led2 //Call led2 subroutine

　　acall led3 //Call led3 subroutine

　　ajmp $ // standby state

　　//Part 3: Subroutines

　　led1: //led1 subroutine

　　clr led_light1 //Light up the first LED

　　acall delay1s

　　setb led_light1 //Turn off the first LED

　　acall delay1s

　　ret

　　led2: //led2 subroutine

　　clr led_light2 //Light up the second LED

　　acall delay1s

　　setb led_light2 //Turn off the second LED

　　acall delay1s

　　ret

　　led3: //led3 subroutine

　　clr led_light3 //Light up the third LED

　　acall delay1s

　　setb led_light3 //Turn off the third LED

　　acall delay1s

　　ret

　　delay1s: //delay 1s subroutine

　　(The middle content is omitted)

　　ret

　　end //End of program

　　Please note that in addition to "define pins" in the predefined part, we use the pseudo instruction "org" to define "program start" to avoid the entry address of the five interrupt service subroutines and make the program start from 0030h. The "main" program has only three call instructions to complete the command function. Only by writing the program in this way can the main program part play its due role. And we put the implementation of all specific functions into the subroutines, so that the program structure looks much clearer.

　　Of course, because this program is simple, we don't feel the benefit of this standard writing method, but we think it is more complicated than the first method. In fact, as the functions of the circuit increase, the content of the program will also increase. At that time, you will find more and more advantages of our standard writing method.

　　Because we can look for the main function of the circuit in the main program part, and the specific method of realizing the function can be found in the subroutine part. Such a program structure makes the people who write the program feel that there is an order to follow and proceed step by step; and the people who read the program also feel that the structure is clear and easy to understand.

　　Is this really the case? Let's change the function of this circuit and let the three lights go on and off in a cycle. How should we write this program? In fact, it is very simple. We just need to make a slight change in the main program (main) of the sample program 2. Please see the modified main program:

　　main:

　　loop: acall led1

　　acall led2

　　acall led3

　　ajmp loop //loop

　　Of course, this change is too simple. I just want to show you that the main program actually has only two working states, one is the standby state and the other is the loop state.

[page]

In the above programs, we all use software timing, which is not cost-effective for the single-chip microcomputer system. Because of this, most of the CPU time is consumed in counting. In fact, the CPU has more important things to deal with, and we need to free the CPU from counting. Next, we use the timer to realize our circuit function, so how should the program be written? From the above programming idea block diagram, we can see that the LED light has 6 states of on and off. The following is a programming method. Please see programming example 3:

　　//Program function: The three LED lights turn on and off for 1s in turn, and use the timer to delay

　　//Part 1: Predefined

　　led_light1 bit p0.0 //define pin

　　led_light2 bit p0.1

　　led_light3 bit p0.2

　　counter equ 30h //define the count register

　　org 0000h //Program start

　　ljmp main

　　org 000bh

　　ljmp int_t0 //Timer T0 interrupt entry address

　　org 0030h

　　//Part 2: Main program

　　main:

　　acall init_t0

　　ajmp $ //wait for interrupt

　　//Part 3: Subroutines

　　init_t0: ; Initialize timer T0 subroutine

　　mov tmod,#01h

　　mov tl0,#low（65536-50000） //50ms initial value

　　mov th0,#high（65536-50000）

　　setbea

　　setb et0

　　setb tr0

　　mov counter,#0

　　mov r2,#0

　　ret

　　int_t0; Timer T0 interrupt subroutine

　　mov tl0,#low（65536-50000）

　　mov th0,#high（65536-50000）

　　inc counter

　　mov r0,counter

　　cjne r0,#20,lp1

　　mov counter,#00h //12MHz crystal, timing 1s

　　acall led_flash

　　lp1: reti

　　led_flash; LED flash subroutine

　　mov dptr,#table //scatter transfer program

　　mov a,r2

　　add a,r2

　　jmp @a+dptr

　　table: ajmp led1

　　ajmp led2

　　ajmp led3

　　ajmp led4

　　ajmp led5

　　ajmp led6

　　led1: clr led_ light1 //led status 1

　　mov r2,#1

　　ajmp lp2

　　led2: setb led_ light1 //led status 2

　　mov r2,#2

　　ajmp lp2

　　led3: clr led_ light2 //led state 3

　　mov r2,#3

　　ajmp lp2

　　led4: setb led_ light2 //led status 4

　　mov r2,#4

　　ajmp lp2

　　led5 clr led_ light3 //led status 5

　　mov r2,#5

　　ajmp lp2

　　led6: setb led_ light3 //led status 6

　　mov r2,#0

　　clr tr0 //Timer stops counting

　　lp2: ret

　　end //End of program

　　In this procedure, you need to pay attention to the following issues:

　　1. In the main program, except for initializing T0, the main program does nothing, which is correct. Because we always emphasize that the main program has more important things to deal with, it should let the subprogram handle some small things and specific things. It's like when we use chopsticks to pick up food when eating, we don't have to think about "putting the food into our mouth" all the time, our hands will automatically put the food into our mouth. Because such small things don't bother our brains anymore, only in this way can we free our brains, so that we can think about other things when eating, and talk to others without delaying eating. The microcontroller can only show its powerful functions when it can handle many complex things, so when programming, we must pay attention to let the main program do less specific things and more commanding things.

　　2. A complete program is definitely not written from the first line to the last line. We say that a standard program consists of three parts, and some statements are added while writing the program. For example, when we write the timer timing 1s, we need a counting storage unit, so we add the statement "counter equ 30h" in "predefined in the first part". If the program needs to use a stack, we must first assign a value to the stack pointer SP to specify the position of the top of the stack. This is how actual program writing works.

　　3. In this program, we use the scattered transfer statement, which is actually a bit of an overkill. There are simpler ways to write it. We write it this way, on the one hand, to let everyone try the use of scattered transfer statements, and on the other hand, to show everyone that we only focus on methods (standard programming methods) and not on techniques.

　　When it comes to learning MCU, using C language programming is the general trend. But then again, the study of MCU has a lot to do with hardware circuits, and learning assembly language will give you a better understanding of the hardware structure of MCU. So learning assembly language is not contradictory to learning C language. Those who use C language programming can learn about assembly language to have a deeper understanding of the structure of MCU; those who use assembly language programming should learn C language if they want to enter the application field as soon as possible. And the standard writing method of our assembly program is completely consistent with the programming idea of ​​C language.

　　In other words, with this kind of standard writing training, learning C language is really easy. Just like you learn to drive a car, and you have learned to drive a manual car, how would you feel if you were asked to drive an automatic car? It must be a piece of cake. But what about the reverse? Therefore, friends who learn MCU from assembly language will not suffer any loss. If they learn C language, it will be like adding wings to a tiger.

　　I hope that our standardized program writing method can help friends who are learning assembly language. Of course, you can't learn assembly language by reading one or two articles. The important thing is to write and practice more to truly enter the palace of single-chip microcomputer programming.