Issue
144 July 2002
Driving
the NKK Smartswitch
Part
1: Configuration and Software
MODULE
IMPLEMENTATION
Let’s
get back to the project at hand. The PSoC does not need
an external crystal operating to within ±2.5% of the
intended oscillator value. This is because the internal
oscillator operates to within ±2.5% of the intended
value. The base frequency of the unit is 24 MHz, and
the timer/counter clock sources can be derived from
this. In fact, the digital modules can work up to 48
MHz.
You
can set a number of global resources, but I only changed
three of them for this particular application. I set
the CPU clock to 12 MHz. There are two internal prescalers
available for clocking functions, 24V1 and 24V2. The
former is the internal 24-MHz oscillator divided by
a number from one to 16. The latter will further divide
24V1 by a number from one to 16. I set 24V1 to 16 and
24V2 to 15 in order to generate a clock signal of 100
KHz with a counter resolution of 10 µs. All of these
settings are set up in a graphical user environment,
part of which is visible in Photo 1. PSoC Designer then
translates the settings into code in a process that
is transparent to the user.
I
didn’t need many modules for the implementation of the
hardware interface, so I decided to drive the LP signal
from an 8-bit timer that would interrupt every millisecond.
I took the terminal count (TC) output directly to an
output pin to be used as the LP signal. The width of
the TC signal is the same as the high period of the
input clock.
To
drive the data and SCP lines, I used an SPI master (SPIM)
without the receiver function. As expected, it’s possible
to configure the edge and polarity of the clock signal
relative to the data being shifted out. So, I thought
I would relieve the processor overhead by allowing the
hardware to shift eight bits at a time. This called
for processor intervention after every byte under interrupt
control. The only other information you’ll need refers
to the connection of the internal signals to the output
pins (see Photo 1).
|
(Click
here to enlarge)
|
Photo
1— Pins are allocated either by clicking on the
graphic outline of the package or by modifying the
table in the bottom left window. Those pins that
are not allocated to the user modules may be used
as standard microcomputer I/O. |
|
|
Figure
3—The wire interface is simple. Note that the pin
numbers for the PSoC are for the 28-pin DIP. |
Figure
3 depicts the simple wiring for the microcomputer to
the LCD interface. The software for this project is
written in a simple fashion allowing multiple tasks.
Tasks are identified and numbered as cPhases. The background
routine in Listing 1 is included in main.c. This extract
is the heart of the operation. RefreshMatrix is the
process that maintains the scan of the display. It’s
contained in Matrix.c, you can see a portion of in Listing
2.
| Listing
2—The background routine waits for a
signal from the timer interrupt, then it initiates
the first byte of transmission on the SPI block
and prepares the pointer for the interrupt routine
for the next four bytes or the row. Every 24 lines
the FLM signal is activated. |
The
interrupt of the 8-bit timer occurs every millisecond.
The PSoC Designer cannot implement interrupt routines
in C, so this routine is in assembler module Timer8_1INT.asm
(see Listing 3). Note how the PSoC Designer has created
the routine identifying where the user code should be
placed. When eight bits have been shifted out of the
SPI controller an interrupt is generated, vectoring
to the code in SPIM_1INT.asm (see Listing 4).
| Listing
3—The terminal count on the timer module
will generate an interrupt and output pulse every
millisecond. A flag is sent in the interrupt routine
to indicate to the background routine that the pulse
has been generated so that the next line can be
shifted out. Note the software loop that delays
the reset of the FLM line. This happens every interrupt
whether or not the FLM is set. |
| Listing
4—The first byte transmitted from the SPIM module
is initiated from the background program. When the
transmission is complete, an interrupt will be generated
and program execution will be vectored to this routine.
This routine will fetch a further byte and transmit
it until four more bytes have been sent. After these
five bytes have been transmitted, the routine does
not send another byte, so the interrupt will not
occur again until the first byte of a new line is
sent from the background routine. |
The
software is connected as follows. When a timer interrupt
occurs, a flag (LP_DONE) is set in cStatus. The processor
tests this flag within Refresh-Matrix. If set in cStatus,
the LCD line pointer (RAM address cRowCount) is tested
and when it’s greater than 24 (number of lines on the
screen) the process is refreshed and the FLM line is
set high. In contrast, if it’s not greater than 24,
the counter is merely incremented. In either case, the
first byte of the line is sent to the SPIM master and
a pointer is initiated (RAMpnt) for use in the SPIM
interrupt routine along with the number of bytes left
to be transmitted (cByteCount = 4). I prefer to do this
in C because it allows for easy access to the array.
When
the SPIM interrupt occurs, the processor checks to see
if there are any bytes left to transmit (in cByteCount).
If a byte remains, the processor fetches it by RAMpnt,
transmits it, and decrements cByteCount. If there are
no bytes left, the processor exits the interrupt. Additional
SPIM interrupts will not occur until the RefreshMatrix
routine writes the next byte after the next LP interrupt.
At
the next timer interrupt, the routine sets the LP_DONE
flag once again and clears the FLM line after the output
signal becomes low. It always clears the FLM signal
whether or not it’s set. The routine stretches the point
where the FLM signal is cleared through a software timer
loop. Take care when doing the background loading of
the processor because the LP_DONE flag must be seen
with enough time for the 40 bits to be transmitted before
the next LP signal (see Figures 2a and b).
Now
you know how to configure the peripherals of the PSoC
to implement the hardware interface to the NKK Smartswitch.
In addition, you’ve seen the basic software flow to
shift data out of the shift registers contained within
the Smartswitch. In Part 2 of this series, I will show
you how to add functions for a character generator.
I will also describe a user interface that will allow
the display of graphics and text and the ability to
place them anywhere on the screen.
