Eye Candy
The PIC32MX575F512H is a wonderful
microcontroller. However, it can’t do everything. By that, I
mean it can’t power and provide computational support
for everything you want to hang on its I/O pins. That
applies particularly to LEDs.
To avoid exceeding the PIC32MX575F512H’s
maximum current limit on its I/O pins, we can buffer our
LED indicators with NUD3105 MOSFETs. Doing this
passes the LED current load to the NUD3105 devices. The
PIC32MX575F512H sees the MOSFETs as low current
digital I/O devices instead of high current LEDs.
With only three user-defined LEDs, our design won’t
get anywhere close to the I/O pin current limit maximum.
The inclusion of the MOSFETs is more of a personal
preference here. We could easily drive the three LEDs
directly from the PIC32’s I/O pins.
We will also design in a utility momentary normally
open pushbutton switch. A pushbutton switch could come
in handy as a bootloader start signal. The switch could
also be helpful with debugging or play a role in an
application.
Design Details — Microcontroller
The microcontroller hardware details are outlined
graphically in Schematic 1. The major players are the
UART ports. UART1 is dedicated to the FT232RL USB
UART IC, whose supporting circuitry is outlined in
Schematic 2. A firmware implemented interrupt-driven
data buffer stands behind the UART1 receive pin. The
receive interrupt mechanism makes sure that all of the
incoming data flowing between our communications
board and the external host USB device is captured and
accounted for.
Debugging is the main idea behind designing in the
FTDI device. I see it mainly used to interface to the CCS C
serial I/O tool that comes with the CCS PIC C compiler.
External devices or programs could also use this USB
portal to issue application-specific commands or transfer
packets of data.
UART2 is responsible for communicating with the
ATmega328P that drives the microSD card. File system
commands and application data will flow between the
PIC32MX575F512H’s UART2 and the ATmega328P’s
UART. The only coding we have to perform to realize this
interface is setting up the PIC32MX575F512H’s UART2.
Assigning the RS-232 portal duty to the PIC32’s
UART4 preserves SPI portal 2. SPI portal 2 shares pins
with the PIC32MX575F512H’s UART3. This is a win-win
situation in that we can accommodate an additional UART
interface or support an SPI portal. For convenience, we’ll
pin out the SPI portal to a DF13 header.
Talking to the multi-unit radio socket is the
responsibility of the PIC32MX575F512H’s UART5. The
XBee-type radio modules share a common three-wire
serial interface. So, a simple serial communications
interface is all that is required. The radio data interface
includes a common RESET I/O line and an additional
adhoc mode I/O signal that is specific to the WiFly
module.
All of the LEDs that are under the control of the
PIC32’s I/O pins are driven by the user’s application code.
The same is true for the pushbutton switch.
July 2015 71
■ Schematic 2. The FTDI FT232RL is carrying the USB load in our
design. This utility USB portal can be used for debugging,
program control, and fast data transfers.
