MotorV+ lead being attached to the H-bridge’s OUTPUT 1 and the
actuator’s black Motor ground lead attached to the H-bridge’s OUTPUT 2.
To extend the actuator, we must drive OUTPUT 1 with VS and provide a
ground path via OUTPUT 2. To accomplish this, we must drive the
DIRECTION and PWM inputs logically high. To retract the actuator, we
reverse the current flow through the actuator’s motor by driving OUTPUT
2 from VS and grounding OUTPUT 1. Driving the H-bridge’s DIRECTION
logically low while holding the PWM input logically high will retract the
actuator. Thus, we can start and stop actuator motion by driving the H-bridge’s PWM input logically high and logically low, respectively. When the
PWM input is being driven logically high, the DIRECTION input logic level
determines the actuator’s direction of travel.
Let’s turn the H-bridge actuator motion logic into C source code.
However, before we dive into the logic of driving the actuator, we need to
do a bit of I/O port preparation. If you’re familiar with the PIC, you know
that we need to configure PIC I/O pins we will use for input or output operation. The CCS compiler
does a great job of shielding the C programmer from having to determine if an I/O pin is an input or
output, and writing code to that effect. Since we initially defined our H-bridge control pins using the
PIC Wizard, there’s no more I/O direction code that needs to be added for the application to run as
designed. Here’s one of those times that the C programmer has the desire to have control over a
built-in compiler feature. I would feel better if I specified the way the PIC’s H-bridge I/O pins operate.
SOURCES
Firgelli
Firgelli L12 Linear Actuator
www.firgelli.com
National Semiconductor
LMD18200T H-bridge
www.national.com
CCS
CCS C Compiler
www.ccsinfo.com
Fred Eady can be reached via
email at fred@edtp.com.
#use fast_io(B)
I’ve just instructed the CCS compiler not to set the I/O direction before each I/O operation. With
the compiler clear of generating I/O direction code, the programmer assumes the responsibility of
setting the I/O port pin direction. We set RB0 and RB1 as output pins using this built-in compiler
function:
set_tris_b(0b11111100); //RB0 and RB1 outputs – all other pins are inputs
Okay. Now we can turn our attention to writing the H-bridge driver code. We’ll take advantage
of our compiler’s output_bit function. The output_bit function arguments consist of the desired port
pin followed by the logic level to be driven out of the selected port pin. For instance, output_
bit(RB0,1) will force I/O pin RB0 logically high. I don’t think you’ll have any problem deciphering this
code snippet:
#define ACT_EXTEND
#define ACT_RETRACT
#define ACT_STOP
output_bit(ACT_DIR,1); \
output_bit(ACT_PWM,1);
output_bit(ACT_DIR,0); \
output_bit(ACT_PWM,1);
output_bit(ACT_PWM,0)
ACT_EXTEND and ACT_RETRACT are C macros we created using the C language #define
command. Multiple lines of C source that make up the C macros are separated by the “\” character.
The ACT_STOP definition is a simple text substitution that is called statement shorthand. The idea
behind the C macros and the statement shorthand is to allow the C programmer to use human-readable logical definitions (instead of keying in the actual lines of C source code represented by the
macros and shorthand into the main C source).
All of the supporting elements are in place. So, let’s test our H-bridge driver code by putting
together a simple application that extends, retracts, and stops the actuator in timed intervals. The
CCS C compiler has a built-in millisecond delay function that we can call on to produce the timed
intervals. Here’s a look at the main C source:
#include “C:\servo-ccs-firgelli\firgelli-ccs.h”
#use fast_io(B)
#define ACT_DIR PIN_B0
72 SERVO 08.2010
