Interfaced a
Windows XP motor control program
Introduction
I began with baseline Windows Visual C++ source code of unknown
provenance. My best information is that the code originated from
open source, but was likely since encumbered by proprietary changes.
My first problem was to build the code, which can be complicated by
differences in development environments. Regardless, I lacked access
to the graphical development files, or much information how the
graphics were designed. Consequently, for this and other
reasons that might become evident, the development approach was ad
hoc.
Building
with Visual Studio C++ Express 2010
As I attempted to build the baseline code, it became increasingly
apparent that beyond complications introduced by differing
development environments, there were missing components that were
inapplicable. While it is generally good practice to minimize
changes until baseline code is (re)built, e.g., defer
"optimization", the advantage of this practice is negated when the
related test environment is lacking. In this case, I lacked the Renesas
Brushless DC Motor Kit (YMCRPR8C25), that was apparently the
target of the baseline LEM code. I was targeting the Luminary Micro
LM3S8971 BLDC Motor Control RDK, that TI identified as the RDK-BLDC. The kit
hardware now appears to be unavailable.
Hewing
the HEW
Returning to the build, what was apparently missing from the
baseline code was the HEW
Target Server. The HEW
is evidently the High-performance
Embedded Workshop: "a GUI-based integrated development
environment for the development and debugging of embedded
applications for Renesas microcontrollers." The presence of the Migration
guide to CS+ suggests that the HEW might be NRND. Regardless, the HEW and
HTS appeared proprietary and inapplicable, and more trouble than
they would be worth, particularly as my target utilized an Ethernet
host interface, and the baseline code utilized USB. Hence the
decision to "hew the HEW", and its relation, the HTS. This expedient
enabled me to build the GUI, albeit with its limbs amputated.
Building
like Frankenstein
With apologies (and homage) to Mary Shelley (and her interpreters),
for her prescient, and iconic, forecast of future events, I was
obliged to scavenge the tech graveyards for suitable connective
tissue to complete the creature. I needed an expedient way to breech
the blood-brain barrier between the host OS security protections and
the target Ethernet interface. The choice was between something that
OS OEM Microsoft might offer, or perhaps, an aftermarket option. TI
support was lacking. Apparently, TI's
May, 2009 acquisition of Luminary Micro did not include source
code disclosure rights to the BLDC Motor Control
RDK GUI Ethernet driver. I would have to reverse engineer the
target Ethernet control protocol, though TI did supply helpful
(albeit incomplete) API documentation.
All things considered, Winsock (Berkeley sockets API), WinPcap, and
Wireshark looked like the best tools for the job. Long story short,
leveraging laudable freely available tools, I managed to transplant
a different motor control target, i.e., one connected to the host
using Ethernet rather than USB, onto the LEM GUI. Here follows a
visual depiction (used absent permission, asserting fair use, ©
2010-2015 Renesas Electronics Corporation. All rights reserved.):
I (briefly) considered a markup to illustrate the changes. I
concluded that readers should be encouraged to imagine the Luminary
Micro LM3S8971 BLDC Motor Control RDK in place of the Renesas
Brushless DC Motor Kit, the "USB" replaced by "Ethernet", and the
HEW and HTS replaced by Winsock. The LEM is the "Custom Windows
Application", i.e., a motor control GUI.
It's alive... It's alive, it's
moving, it's alive, it's alive, it's alive, it's alive, IT'S
ALIVE!!!
Ridiculous, right? I relate to that scene as emblematic of the
elation of relief even aspie nerds feel after working long and hard
to build something, however modest and grotesque. Now for the GUI
customization. Since I was ignorant of how the LEM GUI was built,
and I was loathe to invest money, time, and tranquilizers in GUI
building tools anyway, I directly manipulated the LEM GUI resource
(.rc) file. I recall searching for suitable resource file editors,
but found none suitably capable and available. Regardless, the
resource file links Visual C++ GUI components to underlying
procedural code structure (flesh on the bones). So rather than learn
a GUI builder, for the limited changes needed, it just seemed most
expedient to directly edit the resource file. Shocking, I know.
Customizing
Controls and Graphics
The LEM
GUI depiction has a "GUI Demo" button that invokes a Flash
presentation. Here follows a screenshot (used absent permission,
asserting fair use,
© 2010-2015 Renesas Electronics Corporation. All rights
reserved.):
Post-op:
Ignoring the differing image quality, I will just note a few changes
to illustrate how I modified the GUI: more tabs with different
captions and functions, indicator faces and legends changed (those
lacking illumination effect), new controls, and replacement of the
speed limits red-lining on the slider with text input boxes. Of
course, I also wrote and integrated the procedural code to answer
the GUI helm. Though this description is barely the tip of this
iceberg, it hardly seems worth expanding further. If you express a
particular interest, I might use the occasion to expand this
treatment. At least, here follows a side-by-side thumbnail to assist
in comparison:
© Copyright 2015 by Mike Ferguson.
All rights reserved.