[Design View / Design Solution]
Mixed-Signal Processors Can Aid Visual Robotic Development
State-of-the-art tools make motion control and development a more abstract process.
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.
Reprints
