New product: Pololu Dual MC33926 Motor Driver for Raspberry Pi
The Pololu Dual MC33926 Motor Driver for Raspberry Pi is our latest offering designed to help you build a robot around the powerful and versatile Raspberry Pi single-board computer. It features a pair of Freescale MC33926 motor drivers, each capable of supplying a motor with up to 3 A continuous (5 A peak) at voltages from 5 V to 28 V. This makes it a good choice for driving bigger things like our 25D and 37D motors and even linear actuators.
Driving motors with a #2756 dual motor driver on a on a Raspberry Pi Model B+ or Pi 2 Model B. A step-down regulator provides 5 V to the Raspberry Pi.
We particularly like using the MC33926 because of its robustness: it can withstand voltage transients up to 40 V, and it has a current regulation feature that actively limits the output current to a safe amount. Furthermore, the driver automatically lowers the current limit as its temperature increases, allowing it to gracefully reduce the motor current instead of abruptly shutting down.
This add-on board is a step up from the relatively minimal, lower-power DRV8835 motor driver expansion we released last year, but it is just as easy to use. Our Python library helps you quickly get your motors running with the board’s default pin mappings, which use logic gates to enable drive/brake operation of the MC33926 drivers with only two control pins per motor.
Additional inputs and outputs on the MC33926 drivers are exposed for advanced users who want to make use of other configurations and control methods, and a small prototyping area on the side of the board provides a convenient space for adding custom circuits. As with the DRV8835 board, you can optionally connect a voltage regulator (not included) to power the Raspberry Pi from the motor power supply.
The motor driver board is available in two versions:
- a partial kit, with connectors included but not soldered in
- fully assembled, with the female header and terminal blocks soldered to the board
If you’re familiar with other Raspberry Pi add-on boards, you might find it unusual that we are not calling this board a “motor driver HAT”. In fact, it meets most of the requirements needed to qualify as a Raspberry Pi HAT (Hardware Attached on Top): it matches the HAT mechanical specification, and it even includes the recommended ideal diode circuit, allowing the optional regulator and the Raspberry Pi’s usual USB Micro-B power supply to be safely connected at the same time.
The reason the board does not qualify as a HAT is the absence of an ID EEPROM. Such a component is intended to allow the Raspberry Pi to identify a HAT board and configure itself to work with that board. We spent some time looking into how an ID EEPROM might help make this motor driver expansion better or easier to use, and we made provision for adding one in the design of the PCB, but eventually we concluded that it seems to offer no substantial value for this kind of board. (We’ve even seen some similar HATs from other manufacturers that ship with a completely blank EEPROM!)
Automatic configuration might be useful for making the Raspberry Pi automatically load a Linux device driver for an I²C or SPI add-on, but since this motor driver expansion is controlled with direct manipulation of GPIO pins, the responsible program or library can easily set up the pins itself before it begins driving and reading them. Other use cases, like enabling the Raspberry Pi to detect whether the HAT is connected and potentially distinguish between different versions of the HAT, would require much more complex support software to take advantage of while being of questionable benefit.
As a result, we’ve decided to omit the ID EEPROM from the board, even if that means it doesn’t meet the full HAT specification and shouldn’t be called a HAT. The EEPROM format specification still appears to be preliminary and subject to change, so it’s possible that future Raspberry Pi updates will make the EEPROM more useful; if so, we will likely reconsider the decision not to populate the EEPROM chip. However, if you think we’ve missed an argument for including an ID EEPROM now or have any other thoughts on its value, we’d be interested to hear your observations.