A PWM has two parameters—frequency and duty cycle.
The frequency represents the PWM oscillation rate, and the
duty cycle represents how much of that time is spent in the
ON state. If the required pulse width is a 50% duty cycle at a
frequency of 50 Hz, each pulse would be 20 ms in length, with an ON state of 10 ms as shown in the following calculation:
(1000 ms/50 Hz) = 20-ms total pulse, 20-ms pulse/2 (50% of
total pulse time) = 10 ms in the ON state.
In this development environment, the ON state can be
either high or low, depending on whether the chosen PSoC
Express driver is a “high side” or “low side” driver. To create
the PWM, a generic “HIGH side” PWM driver was used. The
Frequency is set to 1000 Hz (or 1 kHz), and the available duty
cycles are “OFF,” “LOW,” “MED,” and “HIGH.”
For the project, only the “HIGH” duty cycle was used, which
is 100%. So with a duty cycle of 100%, we’re pulling the
motor-control line to an “ON” state all of the time, which
means the motor is running at full speed. Figure 7 shows the
lookup-table function for the left-side front motor.
BUILDING THE PROGRAM
The next step is to build the program. An interesting element
to this tool is that a complete “C” program is created, compiled,
and linked without any user input. The first step in this
process is to configure I/O pins (Fig. 8).
For the sake of clarity, I’ve broken the pin assignments into
six groups, starting with accelerometer input pins 35 and 36
as group number 1. Group number 2 consists of accelerometer
output pins that are passed along the
bus for future use. These are connected
to pins 41 and 42. Group 3 is a single pin
that controls the MP (Motor Power) LED
on pin 23.
The Group 4 pins control the right-side
H-bridge on pins 20 and 22. Group 5,
attached to pins 12 and 15, controls the
right side H-bridge. Group 6 provides the
I2C Monitor on pins 16 and 18. After the
pins are assigned, a single click generates
code, compiles, links, and generates
the hex file, ready to download.
PROGRAMMING THE PART
After a successful build, the next step is
to program the device using a five-pin
interface and small programmer connected
to the header. The programming
task is a separate program invoked
within the development environment
through a shell.
Consequently, the programming interface
is already set to the proper part and
programming port. Once programmed,
the programming interface displays the
status of the program and verify functions.
Any errors during programming or
verify cycles are displayed.
SIMULATING AND MONITORING
THE SYSTEM
At this point, all inputs that will be acted on, plus the output control logic, have
been finished. If it were a manual process,
a compile, download, and debug execution
of the target would then occur. But
because it’s not manual, the next steps in
the process are either to run a simulation
or run the target system and monitor the
results in the development program. For
this article, the in-line monitor function of
the development tool was used.
A simulation can be run at any point
during the development cycle. The only
requirement is that all of the logic be completed,
which means no evaluation box
has a partial expression. By the way, this
tool checks for a complete expression
before letting you to continue, so you will
have to either complete or abandon a
partial expression before continuing.
This tool also allows a “Live System” to
be monitored via the I2C port on the target
system’s programming header. The
monitor display is almost identical to the
simulation display. The main difference is
that instead of entering “what-if” values,
the displayed values are actually coming
from the embedded system while it’s running.
It’s also possible to chart and record
variables while the system is running, for
later playback or import into Excel.
CONCLUSION
Though opinions vary when it comes
to visual embedded design tools, using
this type of product with a mixed-signal
processor offers many advantages.
On the positive side, it allows focus to
remain on the design of the solution,
instead of the distraction of debugging
simple coding errors.
On the negative side, the developer
does incur a long learning curve that
offsets any time saved on initially developed
projects. Also, development is limited
to supported components in the
driver catalog, and performance is less
than real time.
But in the end, the benefits outweigh
the drawbacks when learning this type of
design tool. Developing appliance panels,
output displays, keyboards, and data
collection from sensors are quick and
easy to implement. The ability to monitor
live data when the target is executing
brings this type of tool almost up to par
with source-level debugging. I say almost
because of the initial learning curve.
Like it or not, this is the next generation
of development tool. In time, it will
become the new way of developing
embedded systems. With mixed-signal
capabilities and clock speeds many
times what they were five or 10 years
ago, in addition to larger on-board flash,
many of the constraints facing tool and
compiler vendors have vanished.