Writing the Control Program
When it’s time to write the program that controls your project, the options include using machine code, assembly language, or a higher-level language. Which programming language you use depends on things like desired execution speed, program length, and convenience, as well as what’s available in your price range.
Machine code. The most fundamental program form is machine code, the binary instructions that cause the CPU to perform the operations you desire.
Assembly language. One step removed from machine code is assembly language, where abbreviations called mnemonics (memory aids) substitute for the machine codes. The mnemonics are easier to remember than the machine codes they stand for. For example, in the 8052’s assembly language, the mnemonic CLR C means clear the carry bit, and is easier to remember than its binary code (11000011).
Since machine code is ultimately the only language that a CPU understands, you need some way of translating assembly-language programs into machine code. For very short programs, you can hand assemble, or translate the mnemonics yourself by looking up the machine codes for each abbreviation. Another option is to use an assembler, which is software that runs on a desktop computer and translates the mnemonics into machine code. Most assemblers provide other features, such as formatting the program code and creating a listing that shows both the machine-code and assembly-language versions of a program side
-by-side.
Higher-level languages. A disadvantage to assembly language is that each device family has its own set of mnemonics, so you have to learn a new vocabulary for each family you work with. To get around this problem, higher-level languages like C, Pascal, Fortran, Forth, and BASIC follow a standard syntax so that programs are more portable from one device to another. The idea is that with minor changes, you can use a language like BASIC to write programs for many different devices. In reality, each language tends to develop many different dialects, depending on the chip and the preferences of the language’s vendor, so porting a program to a different device isn’t always effortless. But there are many similarities among the dialects of a single language, so, as with spoken language, a new dialect is easier to learn than a whole new language.
Higher-level languages also simplify programming by allowing you to do in one or a few lines what would require many lines of assembly code to accomplish.
Interpreters and compilers are two forms of higher-level languages. An interpreter translates a program into machine code each time the program runs, while a compiler translates only once, creating a new, executable file that the computer runs directly, without re-translating.
As a rule, interpreters are very convenient for shorter programs where execution speed isn’t critical. With an interpreted language, you can run your program code immediately after you write it, without a separate compile or assembly step. A compiler is a good choice when a program is long or has to execute quickly. A single language like BASIC may be available in both interpreted and compiled versions.
Each device family requires its own interpreter or compiler to translate the higher-level code into the machine code for that device. In other words, you can’t use QuickBASIC for IBM PCs to program an 8052 microcontroller—you need a compiler that generates program code for the 8052.
Compared to an equivalent program written in assembly language, a compiled program usually is larger and slower, so assembly language is the way to go if a program must be as fast or as small as possible. A higher-level language also may not offer all of the abilities of assembly code, though you can get around this by calling subroutines in assembly language when necessary.
BASIC-52 is an interpreted language, but BASIC compilers for the 8052 are also available. In fact, you can have the best of both worlds by testing your programs with the BASIC-52 interpreter, and compiling the finished product for faster execution and other benefits of the compiled version.
Testing and Debugging
After you’ve written a program, or a section of one, it’s time to test it and as necessary, find and correct mistakes to get it working properly. The process of ferreting out and correcting mistakes is called debugging. Easy debugging and troubleshooting can make a big difference in how long it takes to get a system up and running. As with programming, you have several options here as well.
Testing in EPROM. One way is to burn your program into EPROM, install the EPROM in your system, run the program, and observe the results. If problems occur (as they usually will) you modify the program, erase and reburn the EPROM, and try again, repeating as many times as necessary until the system is operating properly.
Development systems. Another option is to use a development system. A typical development system consists of a monitor program, which is a program stored in EPROM or other memory in the microcontroller system, and a serial link to a personal computer. Using the abilities of the monitor program, you can load your program from a personal computer into RAM (instead of the more permanent EPROM) on the microcontroller system, then run the program, modify it, and retry as often as necessary until the program is working properly.
Most development systems also allow single-stepping, setting breakpoints, and viewing and changing the data in memory. In single-stepping, you run the program one step at time, pausing after each step, so you can more easily monitor what the circuits and program are doing at each step. A breakpoint is a program location where the program stops executing and waits for a command to continue. You can set breakpoints at critical spots in your program. At any breakpoint, you can view or change the contents of memory or perform other tests.
Simulators. Another development tool is a simulator, which is software that runs on a desktop computer and uses the video display to demonstrate what would happen if a specific microprocessor or microcontroller were to run a particular program. You can look “inside” the simulated chip, observe the contents of internal memory, and single-step or set breakpoints to stop program execution at a desired program location or condition. In this way, you can get a program working properly before you commit it to EPROM. One drawback to simulators is that they can’t mimic all features of the chip of interest, especially interrupt-response and timing characteristics.
Emulators. An in-circuit emulator (ICE) is hardware that replaces the microprocessor in question by plugging into the microprocessor’s socket on the device you want to test. Like a simulator, an emulator lets you control program execution and monitor what happens at each program step. Microprocessor emulators typically are expensive. A ROM emulator is a lower-cost option that simulates an EPROM (using RAM, for example) for program storage, and usually provides the abilities of a development system as well.
The 8052-BASIC’s development system. The 8052-BASIC system and a personal computer form a complete development system for writing, testing, and storing programs. The personal computer’s keyboard and screen make it easy to write and run programs and view the results.
BASIC-52 has many built-in debugging features that make it easy to test programs. You can run a program immediately after writing it, without having to assemble, compile, or program an EPROM. You can use a STOP statement and CONT (continue) command to set breakpoints and resume executing your program. You can use PRINT statements to display variables as the program runs. And, if you wish, you can use your personal computer for writing programs off-line and uploading and downloading them to the 8052-BASIC system
0 comments
Tambahkan Komentar Anda