10. Memory Planning

The following requirements should be considered when planning memory configuration for a Rabbit system.

• The size of the code anticipated. Usually code size up to 512K is handled by one flash memory chip. Static data tables can be conveniently placed in the same space using the xdata and xstring declarations supported by Dynamic C, so the amount of space needed for static data can be added to the amount of space needed for code. If you are writing a program from scratch, remember that 512K of code is equivalent to 25,000 to 50,000 C statements, and such a large program can take years to write.
  
• C programs vary in how much RAM will be required. Many programs can subsist on 32K of RAM. Having more RAM on the system is convenient for debugging since debugging and program testing generally operates more powerfully and faster when sufficient RAM is available to hold the program and data. For this reason, most Z-World controllers based on the Rabbit use a dual footprint for RAM that can accommodate either a 32K x 8, which is in a 28-pin package, or a 128K x 8 or 512K x 8, which is in a 32-pin package. The base RAM is interfaced to /CS1 and /WE1, and /OE1.
  
  RAM is required for the following items:

  Root variables--maximum of 48K.

  Stack pages--rarely more than 20K.

  RAM for debugging convenience on prototype units--512K is usually enough to accommodate programs.

  RAM for extended memory--such as data logging applications or communications applications. The amount needed depends on application.

10.1 Making a RAM-only board.

Some Rabbit customers are designing boards that have only a single RAM chip and no flash memory. Although this is not generally recommended, it may be safe to use only a RAM chip as long as the board has a continuous power supply and is set up to be field-programmable via the Rabbit bootstrap mode.

For example, a Rabbit board in a noncritical system such as a lawn sprinkler system may be monitored from a remote location via the Internet or Ethernet, where the remote monitor has the ability to reload the application program to the board. One way to achieve field programmability is with the RabbitLink Network Gateway.

There are certain hardware and software changes that are required to make this work which are discussed here. Dynamic C starting with version 6.57 has the software files discussed here which are necessary to make a RAM only board work.

10.1.1 Hardware Changes

Ordinarily, CS0/OE0/WE0 of the Rabbit processor are connected to a flash chip, and CS1/OE1/WE1 are connected to RAM. However, if only RAM is to be used, CS0/OE0/WE0 must be connected the RAM. This is because on power up or reset, the Rabbit will begin fetching instructions from whatever is hooked up to CS0/OE0/WE0.

10.1.2 Software Changes

In order to program a RAM only board from Dynamic C or the Rabbit Field Utility (RFU), several changes are needed. When Dynamic C or the RFU first start, they put the Rabbit based target board in bootstrap mode where it awaits data sent via "triplets." These programs then send triplets that map the lowest quadrant of physical memory to CS1/OE1/WE1 in order to load a primary loader to RAM. The first set of triplets loaded to the target is contained in a file called coldload.bin. A different coldload.bin is required in order to map the lowest memory quadrant to CS0/OE0/WE0. The image file for this program is \BIOS\RAMONLYCOLDLOAD.BIN. To use it, rename BIOS\COLDLOAD.BIN to BIOS\COLDLOAD.BAK, and rename \BIOS\RAMONLYCOLDLOAD.BIN to \BIOS\COLDLOAD.BIN. (Later versions of Dynamic C may have a GUI method of choosing the cold loader.)

The primary loader loads a secondary loader, which doesn't affect the memory mapping. The secondary loader loads the Rabbit BIOS to RAM (from the application program image file in the case of the RFU, by compiling the BIOS straight to the target in the case of Dynamic C.) One of the first things the BIOS does in program mode is copy itself to flash, and then transfer execution to the flash copy. When the board powers up later without the programming cable attached, it will start running the BIOS in flash.

The special BIOS file \BIOS\RAMONLYBIOS.C eliminates the self copy step and initializes the MIU/MMU correctly to match the hardware configuration. This BIOS can be selected as the user-defined BIOS by using the Options | Compiler dialog box.