Hardware | pepguard

Overview

ATmega1284P Target Board

Schematic Capture.

The ATmega1284P microcontroller (MCU) has been used since the first few laboratory exercises of this course. We populated a target board for the MCU to integrate and communicate with all other peripherals. The target board extends pin-outs of the serial communication ports for debugging. It connects with the peripherals through a single row of SIP connectors.

Peripherals: Camera & Bluetooth

ATmega1284P Target Board

As shown in the Schematic Capture above, the LinkSprite® camera module works off of 5V nominal power supply. The rationale for having a separate voltage regulator (TL780) for this module is its excessive current draw (~100mA) that exceeds the maximum rated source current of the on-board regulator (LM340L) from the target board. The camera module comes with limited random-access memory (RAM) to temporarily store the previous photograph taken. It communicates with the microcontroller on USART channel 1 through pin D.2 and D.3, configured in 8N1 (8 data bits, no parity, 1 stop bit) at a pre-defined baud rate (default = 38400 bps).

The Bluetooth module needs to be powered between 2.8V ~ 3.3V at ~200mA for normal operation, which clearly exceeds the current sourcing capability of most typical voltage regulators. In our prototype, the Bluetooth module is powered with two AA batteries connected in series (at 3.0V). The module internally further regulates power for its various components (2.8V, 1.8V). It communicates with the microcontroller on USART channel 0 through pin D.0 and D.1 with 8N1 at 115200 bps.

LinkSprite Camera Module

MOD-BT Bluetooth Module

External Interrupt

Two of the three dedicated external interrupt pins on the microcontroller coincides with the Rx/Tx of USART channel 1, therefore we used INT2 on Port B to accommodate push-button triggering into the Active Mode. Input to INT2 is not de-bounced in hardware because this will introduce 2 or more extra components into our design, which goes against the small-footprint design principle of our project. As is the norm for servicing interrupts with the ATmega family MCUs, INT2 is driven by the falling edge of an active-low pulse.

Note that it is possible to use almost any general purpose I/O pin to serve as external interrupt. However, such interrupts would trigger an interrupt service routine (ISR) for the entire port and we would then have to poll each pin to find out where it occurred. Although there should really only be one pin (connected to the push button) that can actively trigger an interrupt in our application, all other 7 pins on the same port are exposed as bare connectors in this prototype - thereby significantly increasing the possibility of false alarms. Overall, a dedicated external interrupt pin (INT2) is still a more preferable choice here.

High power LED Flash Light

LED flashlight has been widely used in digital photography. It serves as a low cost and robust alternative to the traditional xenon flash when ultra-high intensity illumination is not necessary (see comparison). We chose power white LED, a solid-state lamp, from LUXEON® as the flash light that facilitates our camera operations. The graphs below illustrate the nominal operating conditions of this LED in our device (3V forward voltage across the LED @ ~300mA, producing approximately 0.85 X (typical luminous flux = 105 lumens). See reference for more information on power LEDs.

Recall that the total current budget of an I/O pin on the MCU is 40mA, which is much lower than the 300mA required to drive the LED directly. Therefore, an LED driver or current limiter is necessary. We experimented with an LED driver from TI (LM3405XMK) before realizing that the flash LED in our case does not need to perform any prolonged or complicated blinking pattern. A simple power transistor switching circuit would suffice. In order to trigger the LED with logic level signals (0V / 5V), we used an NPN bipolar junction transistor (BJT, Vth = 0.7V) to serve as a power switch for the power LED.

The pull down current is limited by the resistor on the emitter. Its resistance is calculated by:

(V_B-0.7) / R = 300mA

Here, a nominally high resistance (330 ohm) is used in order to avoid thermal runaway. Since the LED has the largest instantaneous current consumption in our system, it is completely decoupled from the MCU to maintain system stability and powered directly from the 9V main supply. In the simulation on the left, we monitored the current through the LED and use an external function generator as the triggering signal. Current draw from the function generator falls within <30mA, which is an appropriate level for the MCU I/O pins to drive.

Simulation for Power LED Circuit.

Forward Current (mA) vs Forward Voltage (V)

Relative Luminous Flux (X 105 lumens) vs Forward Current (mA)

System Integration and Hardware Debugging

Our first attempt at system-level integration occurred after each sub-system (except the LED) is in working condition by itself (11/12/2012). As much as we would hope to see the entire system miraculously spring into action, it never happened.

The first prototype (shown on the right) had some serious power-related problems, namely: the Bluetooth was powered from a 3.3V regulator rated at 100mA DC output, and the camera shares Vcc with the MCU. The camera module worked surprisingly well at the time. In retrospect, this is probably because we have not integrated the LED circuitry into our system, and therefore the MCU was not drawing much current from the on-board voltage regulator.

The Bluetooth's behavior, however, was bewildering - it worked at some times but not others. We initially attributed this to a range of hypothetical factors: weak antenna, buggy code, poorly soldered connections. It turns out that at 100mA supply current from the regulator, the Bluetooth is able to successfully connect with the cell phone if the distance and orientation between the two devices were just right - but it would fail most other times. Because the datasheet lacked any information about the electrical characteristics of this module, and our original measurement of 85mA current consumption was much smaller than the typical ~200mA that it actually draws in active mode, it took us a long time to fix this benign bug.

After Thanksgiving, the camera module mysteriously failed, most likely due to an unfortunate ESD accident. Now that we had to re-order a new part, it seemed reasonable to completely revamp our design, correcting the mistakes that we made earlier on in the meantime. Thus we have version 2 (on the right).

Despite a larger package, this prototype has been working really well for us to test and debug our android application. Some suggestions for further improvement will be discussed here.

Prototype Ver 1.0: BT sandwiched between MCU and camera to minimize device footprint (when batteries were not introduced).

Prototype Ver 2.0