Nuts & Volts

THE DESIGN CYCLE
Obtaining an MC68HC908MR16
datasheet from the Freescale website
would be a good idea, as well. Okay,
now that you’ve been given the keys and
shown the secret codes, let’s go get ‘em.
We’ll build our RS-232 serial port
code on the foundation we previously
laid for the LED blinker code. As you
can see in the Photo 1 screen shot, I’ve
selected the AsynchroSerial Bean from
within the Bean Selector window and
double-clicked on it to add it to our
new C project (MR16_ADC), along with
the BitIO Bean we added previously. I
then proceeded to configure the
AsynchroSerial Bean, which I renamed
to RS-232, using the Bean Inspector.
The result of my selecting and
configuring the AsynchroSerial Bean
and initiating a compile was the
creation of a file called RS232.c, which
holds all of the C and assembler routines
necessary to send and receive
characters via the MC68HC908MR16’s
SCI (Serial Communications
Interface). Recall that the same file
creation process occurred when we
planted the LED_BIT I/O Bean in last
month’s installment of this column
and spawned the LED_BIT.c file.
If you take the time to explore the
Bean Inspector’s Methods and Events
areas, you’ll find that many of the
advanced RS-232 functions are unavailable.
I figure that’s because we’re using
a “FREE” C compiler and you get what
you pay for. In any case, all we want to
do is send and receive characters via
the MC68HC908MR16’s serial port and
there are enough options we can
choose from in the Bean Inspector
Methods area to make that happen.
Okay, so now — thanks to the
AsynchroSerial Bean — we have some
workable RS-232 send/receive code, in
addition to our LED blinker I/O code.
Adding the RS-232 Bean also posted
some changes in the MC68HC908MR16
startup files. Let’s examine the lowlevel
initialization code in Listing 1.
At first glance, the statement
setReg8Bits(PTB, 0x04); (which you
and I didn’t write) is obviously a
function or macro that is most likely
setting some bits in an eight-bit
register. However, the question may
arise as to what do the arguments of
this statement represent. An intuitive
guess would be that the bit 2 of I/O
Port B is being set (0b00000100). In
this case, my guess is correct and as
Spock would say, “Random chance
seems to have operated in our favor.”
To be sure of what the statement’s
intentions are, all we have
to do is place the cursor on the
statement in question and right-click.
You will be prompted to be taken to
the coded definition of the statement
which, in this case, is a macro. The
definition of setReg8Bits(PTB, 0x04);
is contained within the PE_Types.h
file and looks like this:
#define setReg8Bits(RegName, SetMask)
Once armed with the supporting
macro code, translating setReg8
Bits(PTB, 0x04); is easy. The PTB (Port
B) data latch (RegName) is being
“OR”ed with the mask value SetMask
(0x04), which sets bit 2 of Port B. The
next statement, setReg8Bits(DDRB,
0x04); places bit 2 of Port B into output
mode by setting bit 2 of the Port B Data
Direction Register.
A look at Schematic 1 tells you that
the two lines of C source we’ve just
digested are working on the LED, which
is attached to bit 2 of Port B. While your
eyes are on the schematic, note that the
RS-232 port pins are located in Port F
territory. Fire up your copy of
CodeWarrior Development Studio for
HC08 v5.0, pull up the Listing 1
C source (the Cpu.c file from the
project MR16_RS232) and right-click on
the clrSetREg8Bits(DDRF, 0x10,0x20);
statement. A window containing the
PE_Types.h file contents will appear.
The breakdown of the code behind
the clrSetREg8Bits(DDRF, 0x10,0x20);
statement will look like this:
The first argument, ClrMask
(0x10), specifies which RegName bit
to clear, while the second argument,
SetMask (0x20), sets the bit set fourth
in the mask, which is bit 5, in this
instance. The inclusion of DDRF in
the macro as RegName implies that
we are working on the Data Direction
Register of Port F. Thus, we are clearing
bit 4 of Port F’s Data Direction
Register providing an input I/O pin for
our SCI receive pin.
Conversely, we are setting bit 5 of
Port F’s Data Direction Register to
provide an output I/O function for our
SCI transmit pin.
A right mouse click on the next
statement, RS232_Init();, tells us
that the C statement represents a
function, which is found in the
RS232.c file we generated when we
activated and compiled our RS232
Bean. Once you navigate to the
RS232.c file, you’ll find that the
(RegName |= (byte)(SetMask))
RS232_Init function simply sets the
desired baud rate (we defined the
baud rate in the Bean Inspector) and
activates the SCI asynchronous
transmitter and receiver.
We’re done with the foundation
of our RS-232 serial port code. What I
hope that you have come away with is
that you can right-click on functions,
macros, declarations, and variable
definitions in the project’s C source
and be taken to the location of a
lower level of source code, which will,
in most cases, yield a pretty good
explanation of the object you right
clicked on.
The code snippet from
MR16_RS232.c shown in Listing 2
applies the RS-232 routines provided
by the AsynchroSerial Bean (the
RS232 Bean in our program) and
echoes any incoming character. I
modified our initial LED blinker
program for use in the RS-232 echo
code. Every pass through the endless
loop alternately illuminates and
extinguishes the LED. When you’re
#define clrSetReg8Bits(RegName, ClrMask, SetMask)
(RegName = (RegName & (~(byte)(ClrMask))) | (byte)(SetMask))
not thumping on the keyboard to
send a character, the blinking LED
gives some indication that the
program is actually running.
Now that we have a primitive
communications portal by way of the
MC68HC908MR16’s SCI, let’s press
forward and cook up an analog-todigital
converter Bean.
March 2006 27