Rainbow Electronics AT89C2051 - Manual (Page 6)

Microcontroller
5-52
Virtual Machine I/O
The Virtual Machine handles physical I/O (as well as virtual
I/O) through the use of input/output instructions. It is natural
to reserve certain I/O addresses for on-chip functions such
as serial I/O and for access to the AT89C2051’s on-chip
parallel I/O ports. Additional I/O addresses are assigned to
second level functions such as serial port configuration and
direct I/O bit set and clear functions. The bit manipulation
functions are important when an on-chip parallel port is
simultaneously used for both input and output.
Consider the ramifications of performing a standard
read/modify/write operation on such a port. Normally this
would be accomplished by reading the port via an IN
instruction, performing a logical operation on the value, and
writing the modified data back to the port using OUT.
Should an input pin be externally pulling low while the port
was being read, the unfortunate outcome of this exercise
would be to render that line permanently jammed low and
unusable for any further input!
Additional virtual input/output devices are provided for func-
tions such as time-of-day clock, general system timing,
pulse width modulation, and pulse accumulation. These are
implemented as background interrupt service routines and
are accessed as simple input/output devices.
Serviceable as the basic I/O resource set may be, it’s often
necessary to provide ancillary I/O functions external to the
processor. The Virtual Machine accomplishes this transpar-
ently by passing any undefined I/O addresses to the exter-
nal peripheral trap. This handler uses a secondary I
2
C bus
to implement an auxiliary external peripheral/memory chan-
nel.
Here, the instruction’s I/O address is taken as the I
2
C slave
address. For output operations data is passed via the low
byte of the virtual accumulator. Input functions return data
in the low byte of the virtual accumulator. In both cases the
accumulator’s high byte is utilized to convey completion
status and can be interrogated to determine the outcome of
the requested operation. The result code reflects the status
of the data link transfer and either indicates valid comple-
tion or fault status. Should a fault be reported it could be
the result of a peripheral in busy status, a device that is not
present, or a legitimate peripheral malfunction.
Virtual Machine Assembly
To clarify the relationship between the Virtual Machine ker-
nel, a virtual assembly language library function, and a vir-
tual C application program, an example is in order. This will
also serve to illustrate how easily communication to the
outside world can be orchestrated in such an environment.
The program depicted in Listing 1 is a library function that
supports console I/O using a special I
2
C user I/O module.
(This is the same module that was detailed in the applica-
tion note “A Framework for Peripheral Expansion.”) The
user I/O module contains a standard 20 x 4 LCD, 4 x 4 key-
pad, and beeper. These are supported using two I
2
C-to-
parallel port expanders. The underlying premise is that,
once the data transport mechanism is hidden, the I
2
C ports
can be used just like any conventional I/O ports. In this
case the concealment is complete since the I
2
C driver is
written in the AT89C2051’s native instruction set and is
therefore completely invisible and inaccessible to a virtual
program running on the Virtual Machine. Reading and writ-
ing to I
2
C devices now becomes strictly a matter of IN and
OUT.
Looking again to listing 1 reveals how virtual instructions
can be combined to generate a useful program. Far from
being constrictive, the virtual instruction set yields an econ-
omy of expression while retaining a great deal of flexibility.
The limited number of registers does, however, require a
reliance on the stack for parameter passing and for holding
intermediate results. This shouldn’t be surprising consider-
ing the fact that the Virtual Machine is primarily designed as
a C engine. Anyone familiar with the way a C compiler uti-
lizes the stack frame should have little trouble adapting
these concepts to writing efficient assembler programs.
Virtual Machine Compilation
Not much can be said about the compilation process for the
Virtual Machine. This is truly a virtue since, after all, the pri-
mary purpose of a language compiler is to insulate the pro-
grammer from the complexities of a particular processor.
To those experienced with C compilers for 8051 proces-
sors, the most notable omission here is the absence of the
multiplicity of libraries for the various memory models that
are so necessary when working with a native 8051. Recall
that the Virtual Machine supports a single, eminently rea-
sonable, flat 64K memory space.
Listing 2 reveals that there is nothing special and, more
importantly, that there are no artificial limitations inherent in
a C program written for the Virtual Machine. This program
implements a simple calculator function that uses the I
2 C
user I/O module as the system console device and utilizes
the long math functions from the Virtual Machine math
library. The actual functionality behind this module is sec-
ondary. What is more important is that it looks like a C pro-
gram and behaves like a C program — and can be abused
like a C program. In short, it can be coerced to do the
things you need a typical embedded program to do.