Understand motor-technology principles. AC-induction, brushed-dc and brushless-dc motors all have different electronic-drive requirements and control circuits. A brushless-dc (BLDC) motor, for example, can operate as a sensor-based or as a sensor-less device and each operating mode has its own characteristics, costs and benefits. By understanding these "variables" you can determine which motor type to use and how to best control it. Vendors of motors and microcontroller-based dev-kits offer a variety of application notes that explain how motors work and how to control them. Download and study them.

Understand drive and control operations. Just as motor technologies vary, so do the drive circuits that control them. Determine the types of circuits that can drive the motor you plan to use and then ensure that the dev-kit you plan to buy will provide them. In most cases, kit vendors let you know the type of drive circuitry available, but in a few cases, they might use a special hardware drive module that could complicate later prototype work. In some cases, a dev-kit might operate two types of motors, say brushed dc and BLDC motors. Many BLDC dev-kits will run a sensor-based or a sensor-less motor, which lets you explore both.

Take safety seriously. The quick-start guide for the Stellaris AC Induction Motor Reference Design kit shows a direct connection of the dev board with either 115V or 230V ac mains. Although the board provides some isolation, information in the User's Manual warns: "The microcontroller in the RDK is not referenced to ground; it is at ac line potential. Do not make direct connection to the JTAG header or any other microcontroller-related circuit." When you work with line voltages on a lab bench, always wear safety glasses. (Refer to the latest National Electrical Code for motor-wiring requirements in your product.)

Choose the right microcontroller. Motor dev-kits come with an MCU, but you must investigate its capabilities to determine whether it - or a member of the same MCU family - can handle the tasks you have in mind. If an application will include only a CAN bus interface and a small touchscreen LCD, the onboard MCU might suffice. But for more complicated projects you might have to move up to an MCU with more timers, memory or I/O ports. Or you could look at smaller MCUs that require less power and cost less. Choose an MCU in a family of devices that offers a continuum of capabilities and code portability.

Get the right motor. Most kits provide a motor you can use for experiments and to test your own or supplied code. If you want to use a kit that doesn't include a motor, ensure the kit specs tell you what motor to buy. Then find a supplier who has one in stock. No sense buying a kit now and waiting several months for a compatible motor to arrive. Also, determine if the kit will drive the motor you plan to use in your application. Often kits can drive motors from many manufacturers, so pay attention to your motor's voltage and current requirements and make sure your kit's driver circuits will handle them. If not, you might have to look for another kit, design your own drive circuits or use an off-the-shelf drive module. While learning about motor control, you want to do as little hardware design as possible.

Review the kit's bill of materials. After you work with a kit and try various control algorithms you'll likely build a prototype that uses the same basic drive circuits, glue logic, optical couplers and so on. I recommend adopting as much of a reference design as possible for your first prototype. Use the BOM information and distributor websites to ensure you can obtain all needed parts such as the "special module" mentioned above in Tip 2. No sense adopting a reference design when the vendor uses an obscure component not available in your area. Most vendors I know use standard parts, but it never hurts to carefully review a BOM before you commit to a design. (Kit vendors usually make kit documents, schematics, software, user guides, bills on materials, and so on, available via their websites. Always check for the availability of kit information before you break any seals on kit-component packages. If documents look awful, you can return the kit.)

Ensure your kit includes schematic diagrams you can read. I've had poor results printing decent schematics from many dev-kits because suppliers think they can put complicated circuit diagrams on letter-size paper (8.50 x 11 inch). If you can't print useful schematics, ensure the vendor can supply them another way. I recently asked a vendor's tech-support person for better diagrams and he mailed me a set on 11 x 17-inch paper. The labels are still small, but readable. Kits and reference designs also should include printed-circuit-board files and Gerber files so you can easily import and use the vendor's component layouts and power-and-ground planes. Pay particular attention to these planes and to proper circuit decoupling in your prototypes because motors can draw considerable current.

Get source code. Kits should provide source code for motor-drive applications, but often it comes cluttered with "side applications" that flash LEDs, display information on a PC monitor or perform other operations. Vendors should supply simple code examples that show and explain how the code relates to the motor-control algorithm and how you can adapt it to your application. Unfortunately, a lot of dev-kit code lacks comments and tutorial information. The Atmel application note, "AVR492: Brushless DC Motor Control using AT90PWM3/3B" offers a good example of how to supplement a kit with useful information.

Test your code on the dev-kit or reference design. Don't make an all-or-nothing leap from the vendor's equipment to your own board with your own code. Use the reference as a platform on which to first test your algorithms and controls. After you've debugged your software and it works on the reference design, move the code to your prototype. You don't want to have to solve too many problems simultaneously.

Consider an intermediate prototype. After you run your code successfully on a dev-kit or on a reference design, consider duplicating the vendor's drive circuit or module on your first prototype. You can customize the microcontroller section of your design, but sticking with the original drive circuit and components provides a known-good section of the prototype that should work right away. In the next prototype, use your own drive circuit and MCU configuration.