Файл: The Microcontroller Idea book (Jan Akelson, 1997).pdf

Calling Assembly-language Routines

13

Calling Assembly-language

Routines

Although BASIC-52 is a convenient programming language that can do a lot, sometimes it’s just not fast enough for what you need. A line in a BASIC-52 program can take many milliseconds to execute, and for some applications, this is just too long.

One way to speed things up is to use assembly language. This doesn’t mean that you have to give up on BASIC-52 entirely. You can continue to use it for the parts of your programs that aren’t time-critical, and call assembly-language routines only for those parts that have to be fast. BASIC-52 can also serve as a convenient development system for loading and testing assembly-language routines in RAM, and even for programming the routines into NV memory.

Calling routines from BASIC-52 is a good way to become familiar with assembly-language programming. Plus, through experimenting, you can learn a lot about the internal workings of the 8052 chip and how the BASIC-52 interpreter works.

This chapter explores how and when to interface assembly-language routines to BASIC-52 programs. An example project connects a digital-to-analog converter to the 8052-BASIC. Programs in BASIC-52 and assembly language cause a sine wave to appear at the converter’s output. There’s also a section on how to use your BASIC-52 system as a general-purpose

Calling Assembly-language Routines

into memory in the 8052-BASIC system. The following sections describe each of these in more detail.

Programming Reference

This book concentrates on BASIC-52 programming. I’ve included enough information about assembly language to get you started programming, plus what you need to know to interface assembly-language routines to BASIC-52. But there is much more to assemblylanguage programming than I can cover here.

If you are an experienced assembly-language programmer, Intel’s Embedded Microcontrollers handbook, or a similar reference from another 8052 vendor, may be all you need as a reference. The handbook includes a programmer’s guide and describes each of the 8052’s instructions.

If you’re just starting out with assembly language, you might want to invest in a more complete text that includes examples and explanations of how to put together a program. Examples can be extremely useful for seeing how to do common tasks like generating a timing delay or handling an interrupt. Appendix A lists several books on the 8051 family that include programming examples and tutorials.

Text Editor

The text editor is the software that you use to create your source files. The editor program must be able to create files in straight ASCII format, without adding any formatting codes. Just about all word processors have this ability, as do simpler text editors like MSDOS’s EDIT.

Assembler

The assembler is the program that creates an object, or executable, file from your source file. If you write assembly-language programs for your personal computer, you use an assembler, such as MASM for 80x86 microprocessors. MASM creates files that will execute on 80x86 systems, using the 80x86’s instruction set.

To assemble a program for an 8052 microcontroller, you need a special type of assembler called a cross assembler. The cross assembler runs on your personal, or host, computer, but creates programs to run on a different chip, such as the 8052. Assemblers for 8051-family chips, which you can use for 8052 programming, are widely available. Appendix A lists vendors of assemblers and BBS’s from which you can download free and shareware assemblers.

Chapter 13

Most 8051-family cross-assemblers create files in Intel Hex format, which is convenient for EPROM programming and uploading to RAM. During the assembly process, if the assembler encounters a program line that is incomplete or not understandable, it will display an error message describing the problem. The assembler will also create a listing file that shows each line of your source file alongside the addresses and machine codes of the object file and any error messages generated.

Memory for Program Storage

On your BASIC-52 system, you’ll need room in external memory for storing your assem- bly-language routines. Remember that the 8052 has separate control signals for accessing code and data memory. For uploading into RAM and testing, you must use combined code/data memory, since you need data memory’s WR signal to write the routine into memory, and code memory’s PSEN to enable the 8052 to execute the routine.

You can upload routines into any unused combined code/data memory from 2000h to FFFFh. Code memory from 0 to 1FFFh is not available, because the 8052-BASIC chip uses these locations for the BASIC-52 interpreter. If you have a 32K RAM addressed at 0 in combined code/data memory, you can use the area above 1FFFh for storing and testing assembly-lan- guage routines. For combined data/code memory in Figure 3-1’s circuit, move the connection at pin 22 of U7 from pin 17 of U2 (READ) to pin 3 of U3A (RDANY). With this setup, however, if you upload your programs into ordinary RAM, you’ll lose them when you power down.

For more permanent storage, there are several options. You can use a 32K NV RAM, such as Dallas Semiconductor’s DS1235, or a Dallas 1213C SmartSocket and 62256 SRAM, in place of ordinary RAM at 0. Although you don’t need battery backup for data memory from 0 to 1FFFh, it does no harm. Again, you must connect RDANY, not READ, to pin 22 of the NVRAM.

To prevent overwriting your assembly-language routines in RAM when you reboot, set MTOP to 1FFFh, or another value that is lower than the beginning of your routines, and execute BASIC-52’s PROG3 command, as described in Chapter 3. (You must have NV memory at 8000h to save MTOP.)

If you use a 32K NV RAM from 0 to 7FFFh, you should be aware that BASIC-52 reserves two areas of code memory for optional additions and enhancements. One area, from 2001h to 2091h, stores information that tells BASIC-52 about custom reset routines, keywords and other language extensions. Another area, from from 4003h to 41FFh, stores information about user-defined assembly-language interrupt routines.

If you won’t be using these abilities, you can use these areas of memory for other purposes. However, if at all possible, it’s a good idea to avoid writing to locations 2001h, 2002h, and

Calling Assembly-language Routines

2048h in code memory. This is because BASIC-52 checks these locations on bootup to determine what additions have been made to BASIC-52. If you by chance have certain data stored at these locations, BASIC-52 will look for the additions it thinks you have, and crash when it doesn’t find them.

If you have an EPROM addressed at 8000h, and you don’t need the entire EPROM for BASIC-52 programs, you can store your assembly-language routines in the unused area. BASIC-52’s (F)PROG command stores programs in sequence beginning at 8010h, so to leave the most room for BASIC programs, you should place your assembly-language routines in the EPROM’s highest addresses.

You can also add NVRAM or EPROM in any unused area of combined code/data memory. For example, you could add an 8K NVRAM addressed from 2000h to 3FFFh, or a 16K EPROM from 4000h to 7FFFh.

Software for Uploading

You’ll also need a way to load your routines from your personal computer into your 8052-BASIC system’s memory. All that’s required here are your host computer’s communications software and a BASIC-52 program that reads and stores the uploaded file.

Appendix B contains two such programs. Listing B-1, HEX2RAM.BAS, loads Intel Hex files from your personal computer into RAM, including NVRAM, in a BASIC-52 system. Listing B-2, HEXLOAD.BAS, does the same, and also offers the options of loading into EPROM or EEPROM.

On your host computer, you can the same communications software that you use to upload BASIC-52 programs, as described in Chapter 3.

Another option for loading routines from your host computer into memory is to program an EPROM or other device with a device programmer, and then insert the programmed device into your BASIC-52 system. If you use this method, you can access the chip as code-only memory, rather than combined code/data memory, since you don’t need to write to it when it’s installed in the 8052-BASIC system.

Loading a Routine

When you have the necessary tools, you’re ready to write an assembly-language routine and assemble, upload, and call, or run, it. As a first try, we’ll begin with a very simple routine, just to verify that the circuits and techniques are working.

Listing 13-1 has just one function: it toggles pin 1 (Port 1, bit 0) of the 8052. An ORG directive tells the assembler the address at which to begin loading the routine. Listing 13-1

Chapter 13

Listing 13-1. Source file for a simple program to test assembly-language interfacing with BASIC-52.

end

specifies 3000h. You can change the address to match whatever locations you have available in your system.

The program body’s single instruction complements bit 0 of Port 1, changing it from high to low or low to high. A ret instruction then returns control to BASIC-52.

To create and test the routine, do the following:

Use a text editor to create a file containing Listing 13-1.

Use your assembler to assemble the file. A typical command line looks like this:

A51 bittog.asm -L bittog.lst -O bittog.hex

The above command tells the assembler to create two files: the listing file bittog.lst (shown in Listing 13-2) and the object file bittog.hex, in Intel hex format (shown in Listing 13-3).

File Formats for Assembly-language Routines

This is a good time to look at Intel Hex and other file formats in greater detail. Most EPROM programmers are able to program EPROMs directly from the files created by assemblers and compilers, but the file must be in a format that the programmer recognizes. Three

Calling Assembly-language Routines

Figure 13-1. Examples of a byte expressed in binary, hexadecimal, and the ASCII codes representing the Hex characters.

common formats are binary, ASCII Hex, and Intel Hex. Intel Hex is also the format required for programs that you upload using Listings B-1 and B-2. Figure 13-1 shows a byte expressed in binary, hexadecimal, and ASCII hex.

Binary

A binary file is the most primitive or unadorned type. It consists of a sequence of bytes that exactly corresponds to the bytes to be programmed. The file contains no addressing information for loading or programming, and no error-checking.

To view or edit a binary file on a personal computer, you need a special file-viewing utility. This is because conventional file-viewing techniques, such as MS-DOS’s TYPE command, will interpret the bytes as ASCII codes and will display the ASCII characters that the codes represent. For example, the value “1" in a binary file appears on-screen as a happy-face character.

ASCII Hex

In ASCII Hex, or pure Hex, format, each byte is expressed as a 2-character hexadecimal number, with each character represented by its ASCII code. ASCII Hex files contain only these 16 codes: 30h through 39h (for numerals 0 through 9) and 41h through 46h (for capital letters A through F).

You can easily view and edit ASCII Hex files on a personal computer, because the computer displays the ASCII characters that the codes represent. However, the EPROM programmer or uploading program must translate the codes into binary data before it writes the codes into the device to be programmed.

Because each byte to be programmed requires two codes, an ASCII Hex file is twice as long as the resulting file that is programmed into the EPROM.

Listing 13-3. Intel Hex file created by assembling the source file in Listing 13-1.

:03300000B2902269

:00000001FF

Chapter 13

Intel Hex

Like ASCII Hex, Intel Hex format stores bytes as ASCII codes representing hexadecimal characters. But Intel Hex adds addressing and error-checking information for more flexible programming and more reliable file transfer.

Each Intel Hex file consists of a series of records. Table 13-1 has more details about the records and what they contain. You don’t have to understand everything about Intel Hex format in order to use it, but the information can be useful if you run into problems and want to examine the contents of a file.

Assembling a Program

When you assemble a program, the message Assembly Successful, or something similar, means that the assembler found no errors that prevented it from creating the object file. If you do see error messages, you’ll have to find out what’s wrong before continuing. The listing file also includes the error messages, and these should help you track down any problems.