Unofficial ZiLOG eZ80 Acclaim! Modular Development Kit Programming HOWTO

Version 1
Copyright (c) 2006 Timothy Jon Fraser

ZiLOG is a registered trademark of ZiLOG Inc. The author of this document is not affiliated with ZiLOG Inc. Although the author provides the information in this document in the hope that it will be useful, the author does not assume liability for or provide a representation of accuracy of the information in this document.

Section 1 --- About this document

This document describes how to begin programming the ZiLOG eZ80 Acclaim! microcontroller provided in the ZiLOG eZ80F910100KIT modular development kit---hereafter called the "Target"---using the ZiLOG C compiler. It is intended to help people who, like the author, spend most of their time programming applications intended to run on top of PC operating systems and are unfamiliar with writing programs that run directly on microcontroller hardware. Experienced microcontroller developers may feel that some of the information carefully spelled out in this document seems so obvious as to hardly be worth mentioning. However, these explanations deal with the issues that confused me initially; they may be of help to other software people.

Where else can I find information on this topic?

The Yahoo! eZ80Acclaim! group is a good source of information. The ZiLOG eZ80F910100KIT modular development kit is one of the kits covered by the "Unofficial Guide to Creating Projects with the ZiLOG eZ80F91 Acclaim! Development Kits" guide found in their "Files" section. The Yahoo! eZ80Acclaim! group's document describes how to configure the Target in a manner that emphasizes fast program execution. This document describes how to configure the Target in a manner that emphasizes the execution of large programs with large memory requirements.

The ZiLOG corporate website contains makes a great deal of highly-detailed documentation available. The following titles are of particular interest:

How is the remainder of this document organized?

The remainder of this document is divided into three sections. Section 2 provides background information needed by the programmer to begin programming the Target. Section 3 provides a step-by-step walkthrough of building and running a simple "Hello World" program on the Target. Section 4 concludes the document with some extra information that is not essential to understanding the "Hello World" walkthrough but is worth knowing nonetheless.

Section 2 --- About the Target

The Target consists of two boards: a small eZ80F91 Mini Enet Module board attached to a larger eZ80Acclaim! Development Platform adapter board [FL0067, UM0170]. The eZ80F91 Mini Enet Module board provides the following components:

The larger eZ80Acclaim! Development Platform adapter board provides connectors for power, serial communications, and the ZiLOG smartcable used to program the device.

How do you write, debug, and run programs on the Target?

Writing C programs for the Target is similar to writing application programs for a typical PC, with two significant exceptions: First, the ZiLOG C library provides only a small number of functions compared to C libraries on typical PCs. Second, the Target has only a small amount of SRAM and Flash memory. You must keep size limitations in mind to a much greater extent than you would on a typical PC operating system with a large virtual memory space. The ZiLOG linker/locator will output build-time error messages when you make a program whose code or data segments are too large to fit.

One typically programs the Target by following these steps:

  1. Connect the Target to your PC.
  2. Using the ZiLOG development environment on your PC, make a new project and enter some Target-specific configuration information.
  3. Write a C program in the ZiLOG development environment on your PC.
  4. Build a "Debug" version of your program that is configured to run entirely in SRAM and not use Flash memory. The Debug build produces an executable image in a .lod file.
  5. Use ZiLOG's development environment to load the .lod file image into the Target's SRAM and execute it. ZiLOG's development environment allows you to insert breakpoints, examine variables, and single-step the Debug version of your program while it runs on the Target.
  6. Loop back to step 3 until you have all the bugs worked out of your program.
  7. Build a "Release" version of your program that is configured to use both SRAM and Flash memory. The Release build process produces an executable image in a .hex file.
  8. Use ZiLOG's Flash Loader Utility to load ("burn") the .hex file image into the Target's Flash memory.
  9. Manually reset the Target by pressing its RESET button or by cycling the power. Your program should begin running.

Section 3 of this document provides a more detailed walkthrough of this procedure.

While the ZiLOG documentation assumes programmers will use a Windows PC to run the ZiLOG development environment, I have also had success running the development environment on Windows 98 SE running inside Virtual PC on Mac OS X. This configuration requires the purchase of a ZiLOG USB SmartCable to replace the serial SmartCable provided in the ZiLOG eZ80F910100KIT modular development kit, as modern Macs do not have serial ports. I use a salvaged Digital Equipment Corporation VT520 serial terminal to perform console I/O with the Target.

What is the difference between Debug and Release configurations?

C programmers familiar with PC environments are probably used to the practice of configuring their programming environment to build two versions of a program from the same source: a "Debug" version that contains extra debugging information and a "Release" version that is stripped of extra information and is highly optimized. A similar practice is encouraged by the ZiLOG development environment. However, the configuration differences between the Debug and Release versions are apt to be greater in the ZiLOG environment in order to handle the differences between SRAM and Flash memory. These additional differences are explained below.

The final step of programming the Target is to "burn" (that is, load) the Release version of the program's executable image (the .hex file) into Flash memory. When the Target is powered on, it will begin to execute the instructions stored in Flash memory. Unfortunately, the programmer can burn images to Flash memory only so many times before it wears out. Being mindful of this limitation, ZiLOG programmers are traditionally reluctant to burn images to Flash memory any more often than is absolutely necessary.

Programmers generally go through many versions of a program during debugging. Rather than wearing out their Flash memory by burning each one, ZiLOG programmers traditionally configure their development environment to build Debug versions that run entirely in SRAM. This configuration usually involves dividing the available SRAM in half (or some other fraction) and using one half to play the role of simulated Flash memory and the other half to play the role of normal SRAM memory. The ZiLOG development environment enables the programmer to load the Debug image (the .lod file) into SRAM without touching the real Flash memory and then reset the device in a manner that causes it to begin running the instructions stored in simulated Flash memory (actually one half of SRAM). Note that because of this division, the Debug version of the program must run with only a fraction of the SRAM that would be available to the Release version.

How does the Target organize memory for Release configurations?

This section describe the layout of the Target's memory address space for Release configuration programs. The next section does the same for the Debug configuration. Normally this information is not of much interest to a C programmer, particularly on systems with large uniform virtual memories. However, ZiLOG programmers need to be aware of it in order to properly configure their programs. This document presents the Release configuration section first, because it is less complicated than the Debug configuration.

The eZ80F91 MCU has a 24-bit memory address space. This fact means that it can theoretically address up to 16MB of memory with locations addressed 000000h to FFFFFFh. However, the amount of memory on the actual Target is far less than 16MB, so much of this memory address space is unused. Table 1 below shows how the Target maps its SRAM and Flash memory into its 24-bit memory address space:

Component Size Start End
ON-CHIP DATA SRAM 8KB FFE000h FFFFFFh
ON-CHIP EMAC SRAM 8KB FFC000h FFDFFFh
unused 040000h BFFFFFh
OFF-CHIP SRAM 128KB C00000h C1FFFFh
unused C20000h FFDFFFh
ON-CHIP FLASH MEMORY 256KB 000000h 03FFFFh
Table 1: typical memory mapping (Release configuration)

The on-chip Flash memory occupies the bottom 256KB of the memory address space [UM0170, eZ80F91 Module section, On-Chip Flash Memory subsection]. The two 8KB blocks of on-chip SRAM occupy the top 16KB of the memory address space [PS0192, Random Access Memory section]. The mappings for on-chip Flash and SRAM are set by the bootloader at boot time by storing the appropriate values into special-purpose registers. The locations shown in the table are the ones used by the ZiLOG bootloader for the eZ80F91 MCU [AN0174, appendix C].

While the mappings for the on-chip SRAM and Flash memory cannot be configured by the programmer using the ZiLOG development environment, the mapping for the off-chip 128KB SRAM can. The programmer can choose to map the off-chip SRAM to the beginning of any 64KB boundary in the unused portion of the 24-bit memory address space (that is, any address XX0000h). This 64KB boundary restriction unfortunately prevents the programmer from mapping the on-chip and off-chip SRAM into a contiguous block. The ZiLOG documentation examples tend to map the beginning of off-chip SRAM to C00000h, presumably for historical reasons [TA0004]. This choice is adequate for our purposes, so the mapping shown in Table 1 simply follows the ZiLOG tradition.

To run the Release version of a program, the programmer uses ZiLOG's Flash Loader utility to load the executable image of the program's Release configuration---the .hex file---directly into the Target's Flash memory. As shown in Table 1, this Flash memory is mapped to the region of memory address space beginning at 000000h. The ZiLOG Flash Loader utility simply copies the file to this region. When the programmer RESETs the Target, it immediately begins executing instructions starting at address 000000h---the beginning of the loaded .hex file. The .hex file begins with ZiLOG startup code that reads segments of your program (DATA, BSS, and so on) from the remainder of the .hex file, copies them into SRAM as appropriate, and then jumps to the beginning of your program's main() routine [TA0004, AN0174].

How does the Target organize memory for Debug configurations?

The memory organization for Debug configurations is quite different from the one used for Release configurations. This difference is probably the most confusing aspect of programming the Target.

Unlike the Release configuration, the Debug configuration of a program is supposed to run entirely in SRAM, not using Flash memory at all. One might expect the procedure for handling the Debug configuration to be similar to the one for the Release configuration, except (1) the programmer would use the ZiLOG development environment to load the program's executable image instead of the Flash-memory-specific ZiLOG Flash Loader utility, (2) the Debug executable image would come from a SRAM-formatted .lod file rather than a Flash-memory-formatted .hex file, and (3) the load and initial instruction address would be C00000h (the start of off-chip SRAM in Table 1) instead of 000000h (the start of on-chip Flash memory in Table 1). Unfortunately, this is not the correct procedure---it does not work.

Apparently, the ZiLOG development environment loads .lod files to the region of memory beginning at 000000h, just as the ZiLOG Flash loader utility does with .hex files. I am not aware of any means of configuring this address to a more convenient value like C00000h---the beginning of off-chip SRAM. Consequently, instead of loading the .lod file where the off-chip SRAM is, the programmer must change the location of off-chip SRAM so that it covers the region where the ZiLOG development environment insists on loading the .lod file. The programmer accomplishes this configuration by first turning on-chip Flash memory off. This action makes the 000000h-03FFFFh memory address space region formerly occupied by on-chip Flash memory effectively unused. Then the programmer maps off-chip SRAM to 000000h-01FFFFh rather than the Release configuration's C00000h-C1FFFFh. This new mapping places the start of off-chip SRAM at 000000h where the ZiLOG development environment will load the program's .lod file. This Debug memory organization is shown in Table 2.

Component Size Start End
ON-CHIP DATA SRAM 8KB FFE000h FFFFFFh
ON-CHIP EMAC SRAM 8KB FFC000h FFDFFFh
unused 040000h 020000h
OFF-CHIP SRAM 128KB 000000h 01FFFFh
ON-CHIP FLASH MEMORY 256KB (disabled) (disabled)
Table 2: typical memory mapping (Debug configuration)

Once configured properly, the ZiLOG development environment makes it easy to switch between Debug and Release configurations and hides most of these details from the programmer.

Section 3 --- Hello World program walkthrough

This section provides a walkthrough of building a Debug and Release version of a simple "Hello World" program that does input and output via the Target's serial port. Please see the printed instructions that come with the ZiLOG eZ80F910100KIT modular development kit to set up your hardware. These instructions describe how to connect the Target to a PC with the ZiLOG serial SmartCable. They also describe how to use a second serial cable to communicate with the Target using the Windows HyperTerminal program.

The Target ships with a sample program already burned in Flash memory. You can test your HyperTerminal connection by powering-on the Target and watching for output in HyperTerminal. If you see no output or garbled output, make sure your serial ports are activated in your PC's BIOS and are correctly configured both in the Windows Device Manager and in HyperTerminal.

My development environment is ZiLOG's ZDSII version 4.9.1. Be sure to check ZiLOG's website for updates when you first install your kit---the version of the development environment provided on the shipped CD-ROM may not be the latest version, and you can download the latest version free of charge after registering.

The following steps describe how to configure, build, and run the Hello World project.

  1. Create a new project.

    Start by selecting File->New Project and fill in the New Project dialog as follows:

    Project Name:
    C:\My Documents\Zilog\Hello\hello.zdsproj or whatever you like.
    CPU Family:
    eZ80Acclaim!
    CPU
    EZ80F91
    Project Type:
    Executable

    Click continue to move on to the "Step 1 - Build options" dialog. Simply click next to accept the defaults and move on to the "Step 2 - Link Configuration" dialog. Choose the "standard" link configuration:

    Link configuration:
    Standard

    In this configuration, your code will reside in Flash memory (actually simulated Flash memory in the Debug build), leaving your SRAM free for stack and heap. Although the Standard link configuration is the only link configuration discussed in this document, it is only one of several options supported by the ZiLOG development environment.

    Click next to move on to the "Step 3 - Target memory configuration" dialog. Fill the fields in as follows:

    Rom
    000000-03FFFF
    Ram
    C00000-C1FFFF, FFE000-FFFFFF
    IntIO
    0-FF
    ExtIO
    0-FFFF
    FlashInfo
    0-1FF

    "Rom" is the address range for on-chip Flash memory. "Ram" is the address range for off-chip SRAM followed by the on-chip Data SRAM. It does not include the on-chip SRAM for EMAC use because our program will not use the EMAC. The numbers correspond to the address ranges shown in Table 1 from section 2 of this document. Click Finish when you are done.

  2. Configure project settings for the Release configuration.

    Select Project->Settings from the menu to get the "Project Settings" dialog. This dialog contains many settings on several tabs. Fortunately, most of them have reasonable defaults or were set automatically based on the information we entered earlier when creating the new project. Some work remains to be done, however.

    This dialog should have a selection box that allows you to choose one of the two build configurations: Debug or Release. We'll work with the Release configuration first. Choose Release.

    1. Configure the ZiLOG Standard Library

      Choose the "ZSL" tab. Select the Port D and UART0 checkboxes. This selection will allow us to communicate with the Target using HyperTerminal. The other checkboxes should remain unchecked. Don't hit OK; we have more to do.

    2. Configure the debugger

      Choose the "Debugger" tab. Check the box next to the "EZ80DevPlatform_F91_Flash - Serial" entry if you are using the serial SmartCable provided with the kit. Check the box next to the "EZ80DevPlatform_F91_Flash - USB" if you spent the extra money for the USB SmartCable.

      You'll note that the entries in this list all come in "Flash" and "RAM" pairs. If you pick the "Flash" version, the "Configure Target" dialog we will deal with next will have reasonable defaults for using flash. If you pick the "RAM" version, the "Configure Target" dialog will have reasonable defaults for using only SRAM. Picking the right one simply reduces the number of settings we have to change in the "Configure Target" dialog.

      Click the "Setup" button to bring up the "Configure Target" dialog. You shouldn't have to make any changes here; just verify that all the settings are as follows:

      For PC/STACK Registers:

      Program Counter (hex)
      000000
      SPL Stack Pointer (hex)
      FFFFFF
      SPS Stack Pointer (hex)
      FFFF

      For External Memory/IO, Chip Select Registers CS0, CS2, and CS3:

      Lower Bound (hex)
      000000
      Upper Bound (hex)
      000000
      Control Register (hex)
      00
      Bus Mode (hex)
      02

      For External Memory/IO, Chip Select Register CS1:

      Lower Bound (hex)
      C00000
      Upper Bound (hex)
      C1FFFF
      Control Register (hex)
      28
      Bus Mode (hex)
      02

      For Clock:

      Phase-locked Loop
      (selected)
      System Clock Frequency (Hz)
      50000000
      Oscillator Frequency (Hz)
      5000000
      Charge Pump Current
      500 microAmps
      Lock Criteria
      8 cycles
      Change ZDI Clock Update
      (checked)

      For Mode:

      Start in ADL mode
      (checked)

      For Internal Memory:

      Enable Data RAM
      (checked)
      Enable EMAC RAM
      (unchecked)
      Address Upper Byte (hex) for EMAC RAM
      (any value is OK)
      Enable Flash
      (checked)
      Address Upper Byte (hex) for Flash
      0
      Wait States
      3

      The Program Counter (hex) entry indicates the location of the first instruction in your program. The development environment has automatically set this to 000000h---the lowest address of the "ROM" range we entered during project setup.

      The SPL Stack Pointer entry indicates the bottom of the stack. The development environment has automatically set this to FFFFFFh---the highest address of the "RAM" range we entered during project setup. (You may recall this is the end of the region corresponding to on-chip Data SRAM as described in section 2 of this document.) The linker/locator will begin the stack here, and it will grow down towards lower addresses (hopefully not exceeding the 8KB region of on-chip Data SRAM).

      The eZ80F91 MCU has two modes: a "Z80" mode with a 16-bit memory address space and an "ADL" mode with the 24-bit memory address space described in section 2 [PS0129, eZ80 CPU Core section]. We will use only the ADL mode in this tutorial. The SPS Stack Pointer is the bottom of the stack for the unused Z80 mode.

      The eZ80F91 MCU has four Chip Selects, named CS0, CS1, CS2, and CS3 [PS0192, Chip Selects and Wait States section]. Each Chip Select corresponds to a particular off-chip memory or IO device. On the Target, CS1 corresponds to off-chip SRAM, and the other three Chip Selects are unused. It would be less confusing for the programmer if the "Configure Target" dialog said "off-chip SRAM" instead of "CS1". However, ZiLOG puts eZ80F91 MCUs in a variety of products with different off-chip memory and IO devices. The Chip Select scheme gives them an added level of indirection to hide these differences from the MCU. Chip selects never correspond to on-chip devices.

    3. Configure the Linker

      Choose the "Linker" tab. Select the "Address Spaces" category. You shouldn't have to change anything here. Verify that the dialog's fields have the following values:

      Rom
      000000-03FFFF
      Ram
      C00000-C1FFFF, FFE000-FFFFFF
      ExtIO
      0-FFFF
      IntIO
      0-FF
      FlashInfo
      0-1FF

      This dialog's "Rom" and "Ram" fields tell the linker/locator where to place different parts of your program. Rom tells the linker where to put read-only things like the program code. It will place your program's code at the lower end of the Rom range. Ram tells the linker where to put things that change during runtime, like the stack and heap. It will put your program's stack at the high end of the Ram range. In this Release configuration, Rom corresponds exactly to Flash memory and Ram corresponds to all of our on-chip Data SRAM and off-chip SRAM. However, this will not be the case with our Debug configuration.

      The dialog's IntI/O, ExtI/O, and FlashInfo fields refer to address spaces other than the memory address space that has been the focus of our discussion so far. The fact that these other address spaces exist is generally hidden from the C programmer by the ZiLOG standard library. However, an explanation of these address spaces is included in section 4 for the curious.

  3. Configure project settings for the Debug configuration.

    Now it is time to set up the Debug configuration for our project. In the "Project Settings" dialog box, choose the Debug selection from the selection box.

    1. Configure the ZiLOG Standard Library

      Choose the "ZSL" tab. As you did for the Release configuration, select the Port D and UART0 checkboxes.

    2. Configure the Debugger

      Choose the "Debugger" tab. Check the box next to the "EZ80DevPlatform_F91_RAM - Serial" entry if you are using the serial SmartCable provided with the kit. Check the box next to the "EZ80DevPlatform_F91_RAM - USB" if you shelled out the extra money for the USB SmartCable.

      Click the "Setup" button to bring up the "Configure Target" dialog. You shouldn't have to change anything; just verify that the fields have the following values:

      For PC/STACK Registers:

      Program Counter (hex)
      000000
      SPL Stack Pointer (hex)
      FFFFFF
      SPS Stack Pointer (hex)
      FFFF

      For External Memory/IO, Chip Select Registers CS0, CS2, and CS3:

      Lower Bound (hex)
      000000
      Upper Bound (hex)
      000000
      Control Register (hex)
      00
      Bus Mode (hex)
      02

      For External Memory/IO, Chip Select Register CS1:

      Lower Bound (hex)
      000000
      Upper Bound (hex)
      01FFFF
      Control Register (hex)
      28
      Bus Mode (hex)
      02

      For Clock:

      Phase-locked Loop
      (selected)
      System Clock Frequency (Hz)
      50000000
      Oscillator Frequency (Hz)
      5000000
      Charge Pump Current
      500 microAmps
      Lock Criteria
      8 cycles
      Change ZDI Clock Update
      (checked)

      For Mode:

      Start in ADL mode
      (checked)

      For Internal Memory:

      Enable Data RAM
      (checked)
      Enable EMAC RAM
      (unchecked)
      Address Upper Byte (hex) for EMAC RAM
      (any value is OK)
      Enable Flash
      (unchecked)

      Note that in this case the development environment has set the CS1 address range for the Debug configuration differently from the Release configuration. In order to simulate Flash memory with SRAM as described in section 2, the development environment has turned on-chip Flash memory off and mapped off-chip SRAM in its place.

    3. Configure the linker

      Choose the "Linker" tab. Select the "Address Spaces" category. Change the Rom and Ram fields to the values shown below. Also, verify that the remaining fields match the values shown as well.

      Rom
      000000-00FFFF
      Ram
      010000-01FFFF, FFE000-FFFFFF
      ExtIO
      0-FFFF
      IntIO
      0-FF
      FlashInfo
      0-1FF

      The Rom and Ram changes implement the trick described in section 2 of this document to simulate Flash memory using SRAM. The Rom field tells the linker/locator to use the lower half of off-chip SRAM for the program code instead of Flash memory. The Ram field tells the linker/locator to use the upper half of off-chip SRAM along with the on-chip Data SRAM for stack and heap. Note that in this configuration "Rom" actually corresponds to SRAM and Flash memory is not used.

      Now we have set up both the Release and Debug configurations. Hit OK to close the "Project Settings" dialog. If the development environment offers to rebuild your project, decline.

  4. Add some code to the project. Choose "File->New File" from the menu to create a new file. Type the following program into the new file:
    #include <ez80.h>
    #include <uart.h>
    #include <stdio.h>
    
    void
    main(void) {
    
    	int thechar;
    
    	ENABLE_UART0();
    
    	puts("This is my program.");
    	puts("There are many others like it,");
    	puts("but this one is mine.");
    
    	while(1) {
    		putchar('>');
    		putchar(' ');
    		thechar = getchar();
    		putchar(thechar);
    		putchar('\n');
    	}
    
    }
    

    Use "File->Save As" to save this file to hello.c. Use "Project->Add Files" to add hello.c to the project. Use "File->Save All" to save all your work.

  5. Build and run the Debug version.

    Use "Build->Set Active Configuration..." to make the Debug configuration active. Use "Build->Rebuild All" to build the project's Debug configuration. You should eventually see this output in the development environment's "Build" tab:

    0 Errors
    0 Warnings
    Linked Completed
    Build Completed.
    

    Make sure the Target is connected and powered on. Choose Build->Debug->Go from the menu. This action will download the Debug version of the program's executable image (the .lod file) to the Target's SRAM and begin running the program. You should be able to interact with the program using your terminal. You can also manipulate the program using the ZiLOG debugger.

    Choose Build->Debug->Stop Debugging from the menu to halt the program.

  6. Build and run the Release version.

    Use "Build->Set Active Configuration..." to make the Release configuration active. Use "Build->Rebuild All" to build the project's Release configuration. You should eventually see this output in the development environment's "Build" tab:

    0 Errors
    0 Warnings
    Linked Completed
    Build Completed.
    

    Choose Build->Flash Loader to open the "Flash Loader Processor (EZ80F91)" dialog. Use the "..." button to chose the hello.hex file. Set the "Erase Before Flashing" checkbox and make sure the rest of the fields are set as follows:

    File:
    hello.hex
    Path:
    C:\My Documents\Zilog\Hello\
    Internal Flash
    (checked)
    All external Flash options
    (unchecked)
    Erase Before Flashing
    (checked)
    Do Not Erase Info Page
    (unchecked)
    Close Dialog when Complete
    (unchecked)
    Flash Configuration
    000000 -- 03FFFF INT
    Internal Start Address
    000000
    File Offset
    000000
    Serialization Controls -- Enable
    (unchecked)

    Press the "Burn and Verify" button. When this procedure completes, the Status window should show the following output:

    File flashed with verification: hello.hex
    CheckSum::0x73632
    Flashing complete.
    

    Press the "Close" button to close the Flash loader dialog. Reset the Target by pressing the RESET button on the eZ80Acclaim! Development Platform adapter board or by cycling the power. The program should begin running on RESET and you should be able to interact with it using your Terminal.

Section 4 --- Other address spaces

The Target has four separate address spaces: memory, IntI/O, ExtI/O, and FlashInfo. This fact can be confusing to programmers used to typical PC application programming. Table 3 shows each address space, its range, the peripherals for which the address space is used, and the kind of instructions programs use to access it.

Address Space Range Peripherals Instructions
memory 000000h-FFFFFFh on- and off-chip SRAM,
on-chip Flash memory
memory access instructions
IntI/O 00h-FFh registers I/O instructions
ExtI/O 0000h-FFFFh I/O instructions
flashinfo 00h-FFh flash info page I/O instructions
Table 3: Four address spaces on the Target

The memory address space is of the most interest to the C programmer; it is the one that contains SRAM and Flash memory as described in section 2. The IntI/O address range covers the eZ80F91 MCU CPU's registers [PS0192, Register Map section]. There are many registers; each has a number in this range. Some registers control the CPU, some to control I/O devices such as the Ethernet MAC and the serial ports. The ExtI/O address space appears to be unused on the Target. The flashinfo address space corresponds to the Flash memory information page [PS0192, Flash Memory section].

These four address spaces are separate. Programs use different instructions to access each address space. As shown in table 3, memory is accessed with typical memory access instructions (loads and stores). The others have special I/O instructions. Because the address space to access is clear based on which instruction the program is using, there can be no conflicts between address spaces. The ZiLOG standard library hides most of these details from the C programmer.


Tim Fraser's page at the WPI alumni site

$Id: howto-mini.html,v 1.1 2006/01/12 16:03:14 tim Exp $