(De)BuggyBoard! - Electrical and Computer Engineering at

(De)BuggyBoard!
Image Source: Aaron & Vivek’s blood, sweat, and tears
Prefatory Information
Team Name: The J.K. Flip Flops
Team Members:
Aaron Reyes
Vivek Nair
Erik Pintar
Justin Frye
Date: May 12, 2015
Project Title: (De)BuggyBoard
1
Abstract
(De)BuggyBoard is an interactive, educational breadboard to ease circuit-building and
debugging, targeted at beginner electrical engineering students. (De)BuggyBoard’s two primary
features are real-time nodal voltage measurements with error checking and an auto-wiring
protoboard.
We begin this report with an overview of the (De)BuggyBoard project concept and continue by
discussing the formal design requirements and high level functional architecture of the product.
We then evaluate currently-existing, similar projects before diving into a full system description
of (De)BuggyBoard.
Since (De)BuggyBoard began as a capstone design project at Carnegie Mellon (for 18-549), we
also graph the project schedule for the spring 2015 semester, outline its budget within the
context of the course, delegate team member responsibilities, and consider risks of the project
within the course context.
We conclude with lessons we learned working on (De)BuggyBoard in 18-549 and a brief list of
decisions we could have made differently to improve project results. Finally, we outline future
features we can add to (De)BuggyBoard to develop it into a marketable product.
(De)BuggyBoard represents significant development in introductory circuits education.
2
Table of Contents
Prefatory Information
Abstract
Table of Contents
Project Description
Design Requirements
Hardware
Software
Functional Architecture
Design Trade Studies
System Description
Hardware Architecture Overview
Breadboard and LEDs
Routing Matrix
Full HW Diagram
Software Architecture
Project Management
Schedule
Budget
Team Member Responsibilities
Risk Management
Schedule
Resources (Personnel and Budget)
Related Work
Conclusions
Lessons Learned
What We Would Do Differently
Future Work
References
Appendix: Budget
3
Project Description
Ever been frustrated trying to make a circuit on a breadboard? The (De)BuggyBoard is
here to ease that frustration.
(De)BuggyBoard is an interactive, educational breadboard comprising of hardware and
software components. Students design the circuit they want to build on a user interface. Then,
as they build it on the attached breadboard, their circuit design will sync with the software to
provide real-time information about their circuit. The student can see what voltages are at each
node, connect nodes without wires via the autowiring functionality, and most importantly notice
when something goes awry.
The primary purpose of (De)BuggyBoard is to take out the frustration and slowness of
building an analog circuit by hand, cutting wires, creating a mess of connections, and tediously
testing each component with a multimeter when things go wrong. Rather, with (De)BuggyBoard,
you work clearly from a schematic, and have LEDs giving error feedback. Then overlayed on
your software design as you build, the physical circuit’s information is constantly displayed and
updated, visible at a glance.
This project is the future of introductory circuits education.
This is (De)BuggyBoard.
Design Requirements
Below we list the hardware and software requirements for our design.
Hardware
●
●
Explicit Requirements
○ Measure voltage at each node of a breadboard
○ Relay voltage data to software
○ Color each row on the breadboard in real-time with status LED
Implicit Requirements
○ Integrate specific circuit components
■ Voltage sources
■ Resistors
■ Capacitors
■ Inductors
■ Diodes
○ Provide mechanism for controlling each pin’s LED independently
4
●
Cool Features / Stretch Goals
○ Auto-wire breadboard based on circuit schematic (use crosspoint switches)
Software
●
●
●
Explicit Requirements
○ Allow users to diagram symbolic circuits
○ Allow user to place and route circuit components onto virtual breadboard
○ Provide real-time feedback in software tool based on physical circuit
Implicit Requirements
○ Error check symbolic circuit diagram
○ Error check breadboard diagram
○ Solve for expected nodal voltages of symbolic and breadboard circuit diagrams
Cool Features
○ Allow user to see feedback from the physical circuit on a familiar looking
symbolic circuit diagram. Auto-updating labels of the physical circuit’s voltages.
Functional Architecture
The figure below overviews the major functional components of the (De)BuggyBoard system.
There are three primary stages of user interaction with (De)BuggyBoard, and user-system
interactions in each stage transfer information, energy, or material:
1. Circuit Diagramming - Users draw their circuit schematic (information) in the
(De)BuggyBoard circuit diagram tool.
The system generates error feedback
(information) for users to correct basic circuit blunders.
5
2. Routing and Placing - Users translate their circuit’s components from the circuit
schematic to the protoboard (information). They receive feedback on routing errors and
step-by-step routing instructions to place physical components on the protoboard once
routing is complete (information, material).
3. Operating - Operating consists of both real-time nodal voltage measurements and
autowiring.
a. (De)BuggyBoard measures the voltage of each row (energy, information), and
reflects the current circuit state (red: faulty connection) via the LED’s (energy,
information).
b. (De)BuggyBoard automatically connects autowired nodes (energy) via the
crosspoint switches.
Design Trade Studies
This section lists a number of key decisions we made over the initial design of our prototype.
Note that we include figures illustrating our design choices resulting from these tradeoffs in the
System Description section.
Digital vs. Analog
Circuits can be broadly classified as either analog or digital. Although digital logic is
implemented using fundamentally analog components such as transistors, interfacing digital
logic circuits with off-the-shelf microcontrollers is a lot easier than trying to hook up analog
circuits to a microcontroller for either routing or sensing purposes.
1. A digital circuit can be hooked up to GPIO pins on a microcontroller which can read and
write logical highs and lows or 1s and 0s.
2. An analog circuit can be hooked up to microcontroller using ADCs and/or DACs,
depending on what role the microcontroller plays in the circuit.
Ultimately, we decided that since a breadboard is primarily used for educational prototyping of
analog circuits, limiting our design to purely digital node sensing and management would not
lead to a very useful product. Thus, although the analog breadboard is more complex in design,
it avoids a fundamental tradeoff that severely hampers the board’s scope of use.
MCU Selection
Our choice of MCU influences the rest of our design significantly because the MCU’s
fundamental limitations, such as number of IO pins, supported communication protocols, and
other features which determine the need for peripheral subsystems. The following are some of
the criteria we used to make our decision:
●
●
Maximum supported frequency
On-chip ADC specifications
6
●
●
On-chip USB module
Number and nature of IO pins
Based on our analysis, the ATMega32U4 and the ATMega1284P were two chips we were
contemplating using in our design. In the end, we decided to go with the 32U4 for the following
reasons:
●
●
●
Adequate maximum operating frequency of 16Mhz
On-chip USB eliminates need for FTDI USB chip
Sufficient IO pins for all remaining peripheral subsystems
On-board or discrete ADC
Given our decision to go ahead with an analog design, one of the primary functional goals of our
project now becomes the ability to measure voltage levels at all nodes of our breadboard. This
can be achieved using an ADC (analog-to-digital converter). That being said, we have multiple
options on how to implement this.
1. We can use the inbuilt ADC on a microcontroller. They typically have 8-bit or 10-bit
resolution.
2. We can use a discrete ADC IC. They typically have higher resolution and sampling
frequencies, which may be relevant to future iterations of (De)BuggyBoard performing
AC measurements.
These choices present a couple of tradeoffs.
●
●
Using an inbuilt ADC, as compared to a discrete ADC, has no upfront monetary cost
associated with it apart from the cost of the microcontroller itself.
A discrete ADC with a higher clock rate and resolution is less likely to distort and skew
analog signals.
Based on these tradeoffs, we decided to go for one (or more) ADCs since they are relatively
inexpensive and improve the overall quality of our design by a great deal. Our chosen ADC can
sample at a resolution of 16-bits at 20 Mhz, as opposed to our chosen ATMega’s inbuilt ADC
which is at 10-bits with a variable frequency between 9 and 200 Khz. The ADC costs about $40
as opposed to the ATMega which is about $3.
Number of ADCs
In order to be a useful breadboard, we need to have multiple rows of headers that represent
nodes in a circuit. However, this introduces an additional challenge in the form of scaling nodal
analysis via the ADC. There are a couple of ways ways to scale the design.
7
1. First, we can use multiple ADCs and hook all of them up to the microcontroller
individually.
2. Second, we can use multiple ADCs but demux their outputs into one (or a few) channels
of PWM inputs into the microcontroller.
3. Third, we can use a single ADC and a demux to route different nodes to the ADC's
inputs and then hook up the ADC’s outputs to the microcontroller.
Each of these possible implementations has its own advantages and disadvantages:
●
●
Using a larger number of ADCs hooked up to the microcontroller means choosing one
with a lot of IO pins.
Using demuxes to control one or more ADCs complicates the logic for measuring
voltages where we first need to select which node to measure before reading the ADC
output.
Taking into account budgetary and IO constraints, it seems that the most useful approach would
be to use a single ADC and demux the nodes into its output. This seems reasonable since there
is no perceivable need to concurrently sense all voltages at the same time. We believe a roundrobin sampling of voltages will be sufficient. Since each of our ADCs is about $40, it is also
prohibitively expensive to use multiple chips, especially if all of them are not going to need to be
sampling at the same time. Instead of using multiple ADCs, using a $5 mux is a significantly
cheaper way to sample up to 16 nodes. A more complex mux can be constructed to scale this
up even further.
Routing
The ability to create and break connections between nodes is a reach goal of our breadboard
design. There are two ways to implement routing logic on the breadboard:
1. We can use a microcontroller or secondary IO IC to logically connect different nodes on
the breadboard by reading values via ADCs and artificially recreate “node” voltages
using DACs.
2. We can use FPGA-esque crosspoint switches to connect wires programmatically for the
breadboard. These crossbars only have an internal resistance, but essentially act as
ideal programmable switches.
However, as was discussed earlier, a system of using multiple ADCs or DACs is prohibitive for a
number of reasons, including but not limited to a fundamental limitation on the number of pins
on most affordable microcontrollers. Further, using a controller adds clock skew and artifacts
that are undesirable, especially for analog circuits. For reference, our crosspoint switches are
about $40 whereas a high IO density microcontroller such as the
Freescale
MC9S12XD256CAG is about $17.
PC-Board Communication
8
Since this board is designed to interface (and act as a slave) for a PC circuit design and debug
interface, real-time PC-board communications is an important feature. However, this can be
realized in multiple ways.
1. Using a wired interface such as UART over USB or a similar protocol.
2. Using a wireless interface such as Bluetooth or USB to communicate between the board
and the PC.
The tradeoffs for these are apparent:
●
●
Bluetooth and WiFi are more convenient but more complicated to implement.
Serial communication over USB physically tethers the board to a PC.
Given this information, we decided to go for a physical interface. This is appropriate since an
educational breadboard such as ours is unlikely to need to be significantly far from a PC that a
user may be using to design and debug the board. For reference, a WiFi breakout board costs
around $35 whereas a USB-UART IC is about $20.
System Description
The system will first be described by its submodules and then the full diagram will be shown.
Hardware System Overview
The MCU is responsible for controlling the datapath of the design and each of the three
subsystems (LEDs, Crossbar switches, and ADC). It receives commands from the software and
executes the commands (it is essentially a slave). The method of communication between the
9
MCU and each subsystem is through SPI. Each subsystem is listening on the same SPI line but
is selectively enabled by the MCU only when being communicated with. The communication to
the computer (software) is bidirectional and through USB since the software will ask for data
and also be sending commands to the MCU. The figure on the previous page illustrates the
primary components of (De)BuggyBoard’s hardware architecture and their communication
paths.
ADC
The microcontroller (MCU) is responsible for gathering as much data as possible from the
analog-to-digital converter (ADC). The ADC is connected to the outputs of analog multiplexers
who multiplex the outputs from the switching matrix. These muxes are controlled by the
microcontroller who just cycles through the nodes and lets the ADC convert each analog signal
into a digital value. The MCU is constantly gathering node voltage data from the ADC and
updating its own internal memory state of the board as it cycles through nodes. When the
software sends a command to receive all nodal voltages, the MCU sends the current status of
the node voltages from its own internal state of the board over USB in a protocol we defined.
Breadboard and LEDs
10
The breadboard has 23 rows with 2 columns for VCC and GND. The breadboard will be
mounted onto a PCB which contains all the hardware for the backend of the design described in
this section. On the sides of the breadboard will be a row of red LEDs. There will be one LED for
each row. The LEDs are controlled from a chain of shift registers that are controlled by the
microcontroller with only 1 IO line using SPI. The underlying rows of the breadboard are
connected to a routing matrix that is described next. The figure above illustrates the breadboard
and its associated LEDs.
Routing Matrix
The routing matrix is a grid of 16x16 crosspoint switches. Each crosspoint switch is equipped to
handle an analog signal and is controlled via a serial line from the microcontroller. The control
lines of these switches can be daisy chained like the shift registers so only 1 IO line is needed
11
from the MCU that is SPI. The crosspoint switches allow for any input to be connected to any
output. This is what makes the auto-routing possible. There is a trade off here in size and cost.
As we increase the number of switches needed, we dramatically increase the cost of the board.
Therefore we have limited the overall board size to 48 (16 * 3) nodes. The figure on the previous
page illustrates the crosspoint switch layout.
Full Hardware Diagram
Putting together the components described above (MCU, ADC, XP’s, shift registers,
multiplexers, and breadboard), we reach the figure above, the full hardware system architecture
diagram. We see that, in contrast to our proposal’s design, a single MCU interfaces with both
the software and all system components, which simplifies the design. Also, we now only use red
LEDs instead of the proposed RGB LEDs. This removed a lot of board area clutter around the
breadboard which made PCB layout easier. Lastly, we also changed the communication
protocol to SPI between all 3 board subsystems so we drastically minimized IO usage from the
MCU.
12
Software Architecture
(De)BuggyBoard’s high-level user flow adheres to the illustration in the figure below: Students
have two panes in software on which to develop their circuit. The left pane is the Circuit
Diagrammer on which students create a conceptual, textbook-like circuit. When they have
specified the circuit diagram, they can check it before placing components on the virtual
breadboard. If their circuit is in error at this point, they will receive feedback.
The right pane is the Board and represents the circuit’s intended layout on (De)BuggyBoard’s
breadboard. Students move components from the Circuit Diagrammer to the board by clicking
diagrammer components and then clicking the spaces on the protoboard they intend to place
the component. Like the Circuit Diagrammer, students can check that the components on the
board form a valid (solvable) circuit after adding each component.
Once students have finished moving components from the diagrammer to the board, they can
check the two circuits are equivalent before placing components on the physical protoboard. If
the circuits are equivalent, the software can begin reading nodal voltages from (De)BuggyBoard
and displaying them in near real time.
We implemented the circuit diagrammer and router, as well as their respective error checkers, in
Python using PyQt and the Ahkab (SPICE-like) circuit solving library. In the figure on the enxt
page, we give an overview of the (De)BuggyBoard software architecture. The root class is
DeBuggyBoard, which holds the container for both the Board and Diagrammer objects.
Because the Board and Diagrammer implementations differ significantly (and sometimes
subtly), each contains its own model, view, and controller classes. (Note that the BoardDraw
and DiagrammerDraw classes are also conceptually part of the view but separated into their
own classes due to their size.)
13
We intend (De)BuggyBoard’s software and hardware components to work together to create the
integrated user flow described by the diagram below.
Project Management
This section describes our team’s semester schedule, member responsibilities, budget, and
identified risks and management strategies.
14
Schedule
First, we illustrate our originally-planned schedule via the figures below. This original schedule
captures the division of labor we followed in the project, as well as the order of tasks we
followed in making iterative progress.
In the figures on the next page, we evaluate our success in keeping this schedule by revisiting
our weekly status reports to construct the updated Gantt chart below.
15
Overall, the project made continuous, iterative progress throughout the development process.
While we initially considered a simple hardware prototype with just nodal voltage sampling to
test software on, we found it was significantly more efficient for hardware development to invest
more time up-front designing the full board rather than pay the overhead of producing multiple
16
iterations. In addition, backordered parts, updated demo times, and the tedious process of
bringing-up the board did impact our progress.
Team Member Responsibilities
Here we overview the individual responsibilities of each team member.
Member Responsibilities
Aaron
Primary: PCB layout, board bringup. Work hard on the hardware!
Secondary: Firmware
Vivek
Primary: Firmware
Secondary: PCB layout, board bringup.
Erik
Primary: Website, UI
Secondary: Circuit diagramming, routing, and feedback software
Justin
Primary: Circuit diagramming, routing, and feedback software
Secondary: Website, UI
Budget
The figure below is an overview of the team’s final, end-of-semester budget. We include both
the costs of the PCB and replacement parts for board bringup in the categories below. For a
detailed overview of the entire budget, please see the Appendix.
Team 1 Budget
$983.57
Category Total Price
Crosspoint Switches
312.66
PCB
300
Multiplexers
100.02
Voltage Regulator
58.96
Microcontrollers
44.24
ADC's
43.52
Capacitors
26.06
Breadboard
23.56
LED's
21.8
Wall Plug / Power Jack
21.5
Soldering Supplies
9.73
Shift Registers
8.26
Resistors
3.36
Crystal Oscillator
3.16
Switches
2.6
17
USB
2.5
Pin Headers
1.64
Figure 11: Final Budget
Risk Management
The tables below overview the major risk categories of our project and provide a series of risk
mitigation strategies.
Design
Risk
Mitigation Strategies
Testing-prohibitive hardware development - Mock the hardware in software.
Effectively testing some software components
requires a working hardware platform.
Underestimating software complexity - The four
major software components are (1) circuit diagram
GUI, (2) circuit solver, (3) routing GUI, and (4)
routing checker.
We must integrate these
components.
Build modular software, and focus on
fundamental functionality first: Build the
routing GUI and checker first, as these
are necessary for the minimum viable
product.
Invalid Circuit Handling - User plugs in a short- Incorporate a physical hardware fuse in
circuit or high-power voltage that could “blow”.
the design.
Program a “software fuse” to disconnect
components at dangerous voltages.
Over-reliance on hardware interfaces - We have Iterate, building progressively more
limited experience with major hardware components complex circuits from a relatively simple
we plan to incorporate, such as the crossbar setup.
switches.
Schedule
Risk
Mitigation Strategy
PCB/Protoboard Manufacturing Time - There Purchase backups of vital hardware
may be non-negligible production time.
components, such as the microcontroller.
Maintain a list of tasks we can still work on
in cases of specific hardware failures.
Repetitious, Time-intensive Tasks - Among Minimize board bring-up time by avoiding
other tasks, soldering will be time-intensive.
small surface-mount components.
18
Resources (Personnel and Budget)
Risk
Mitigation Strategy
Expensive Crossbar Switches - The Scale the size of the protoboard inversely with
protoboard requires nine crossbar switches, the cost of the crossbar switches, i.e. use a
over $25 each.
small protoboard.
Additional class projects and external Overestimate timing requirements in our Gantt
commitments
chart and set spring break as time off.
Conclusions
Developing (De)BuggyBoard has taught us both technical and team-building lessons. While we
would change certain project decisions, we have, through such missteps, honed our vision for
(De)BuggyBoard’s ultimate potential. Overall, each mistake and setback was handled well and
the team found ways to cope with each setback.
Lessons Learned
We have learned lessons through (De)BuggyBoard by both our effective and misguided
decisions.
Our team effectively delegated project responsibilities according to individual skills and
interests, and we saw this policy prevent the project from stagnating on multiple occasions
throughout the semester. Hardware and software progress were rarely (if ever) simultaneously
stalled, and working closely with one other team member significantly reduced overhead
compared to coordinating with three.
In hardware, we learned (or were reminded :)
● soldering PCB components is time-intensive and difficult as the package size gets
smaller.
● destroying numerous IC’s during board bring-up is expected.
● Eagle autorouter may (i.e., did) surrender (i.e., fail) on complicated designs (i.e., our
board).
In software, we learned
● Trello is an effective planning system for incremental feature development.
● investing significant effort into UI improvement pays off.
● pair programming can be effective for debugging.
What We Would Do Differently
19
Our development process had hiccups. If we were to repeat the process, we would make the
following changes:
In hardware, we would
● order more IC’s and PCB copies for board bring-up, which proved a tedious process.
● create a notification system so that we know when parts are backordered to avoid
downtime.
● spend more time on the power system of the board by consulting more professional
advice before sending out the PCB order.
● find a way to edit Eagle files in parallel so the pcb layout can be done faster.
In software, we would
● architect the software circuit model with saving, loading, and exporting or importing from
different file formats as a higher design priority.
● spend additional time studying the Ahkab circuit solving library upfront to improve our
ability to interpret Ahkab’s errors and provide more insightful user feedback.
● create a simple hardware prototype to test our software while the real board is under
construction.
● use an automated documentation system to maintain up-to-date software architecture
diagrams through the development process.
Future Work
Our fumbles through the development process have informed our view of (De)BuggyBoard’s
potential. Below are the main development focuses for future project work; there are certainly
improvements in addition to these we can make.
In hardware, we would
● improve the electrical isolation of the board’s design.
● add a fuse to the board to regulate its maximum current, preventing IC damage.
● for cost purposes, produce a board design without crosspoint switches to deploy in 18100 labs, while also searching for a less costly alternative to crosspoint switches (i.e.,
(De)BuggyBoard Lite vs. (De)BuggyBoard Pro).
In software, we would
● add a feature to save and load files, accepting not only circuits previously constructed in
(De)BuggyBoard but also standard netlist files.
● We would add step-by-step, interactive tutorials for building and deploying several
introductory circuits (from 18-100).
● support for transistor and *some* IC components.
Related Work
20
The related work in this field is very limited since this idea has not been brought to fruition
completely. This idea has been attempted, in some respects, during Build18.
The first Build18 attempt tried to make a breadboard that tracked voltages at each node to allow
for real time debugging of hardware. The design did not fully get off the ground and was limited
to sensing the voltages using the on chip ADCs of the MCU, which are too low quality for any
analog signal. This motivated our desire to use more precise (and more expensive) ADCs than
a simple MCU has to offer.
The second Build18 attempt was to make an auto-routing breadboard for digital designs. This
project did not get a demoable product since the sheer size of the routing was too much to do
with just simple transistors and shift registers. This is what motivated the more complex (and
more expensive) routing scheme with crosspoint switches.
The last inspiration is a project done by an eight-person Egyptian team, which designed an auto
routing breadboard that uses a software backend to route nodes. This design is the closest to
ours, except it lacks the quasi-real-time voltage tracking. However, the UI of the project helped
give us ideas for the software interface and how autorouting would work from the user’s POV.
Our design is the first to incorporate quasi-real-time voltage updates with an auto routing
breadboard that also has a built in circuit solver. In that sense, it stands unique as an
educational tool.
References
1) Build18 2014: ProtoSmart
2) Build18 2015: Field Programmable Protoboard
3) The only marketable product without voltage sensing: http://smartbreadboard.tictail.com/
4) Possible competition in the field, but no product yet: http://signup.smartbreadboard.com/
5) Sample project pitch: http://vimeo.com/98339147
6) Egyptian Team project pitch: https://www.youtube.com/watch?v=2W9zznZocqw
21
Appendix: Budget
Team 1 Budget
Total Spent:
Description
Brand
$983.57
Unit Price Quantity Shipping Cost Extended Price
Crosspoint Switches
AD75019JP Digikey
$31.27
10
$312.66
$150.00
2
$300.00
Digikey
$10.68
9
$96.12
YSD-160AB3C-8 (COM-09191) Sparkfun
$1.95
2
$3.90
PCB
PCB Order
Multiplexers
ADG1406BRUZ
Voltage Regulator
12V to 5V TO-220 LDO voltage regulator
Mouser
$7.23
4
$28.92
LTC1044AIS8#PBF
Digikey
$5.13
4
$20.52
MIC5209-3.0YS
Digikey
$2.02
3
$6.06
MIC5209-3.3YS
Digikey
$1.73
2
$3.46
ATMEGA32U4-AU
Digikey
$6.32
4
$25.28
ATMEGA32U4-AU
Digikey
$6.32
3
$18.96
AD7366BRUZ-5
Digikey
$10.88
4
$43.52
CAP CER 10UF 16V 10% X5R 0805
Digikey
$0.14
60
$8.16
CAP CER 10UF 35V 10% X5R 0805
Digikey
$0.30
15
$4.50
CAP CER 10UF 25V 10% X5R 0805
Digikey
$0.14
30
$4.08
CAP CER 0.68UF 50V 10% X7R 0805
Digikey
$0.45
6
$2.70
CAP CER 0.1UF 50V Y5V 0805
Digikey
$0.03
70
$2.17
CAP CER 22UF 10V 10% X5R 1206
Digikey
$0.37
4
$1.48
CAP CER 10UF 25V 10% X5R 1206
Digikey
$0.24
4
$0.96
Microcontrollers
ADC's
Capacitors
22
CAP CER 0.1UF 50V Y5V 0805
Digikey
$0.03
30
$0.93
CAP CER 18PF 50V 5% NP0 0805
Digikey
$0.10
6
$0.60
CAP CER 1UF 16V 10% X7R 0805
Digikey
$0.12
4
$0.48
270-point breadboard
Pololu
$3.30
2
LT1086CT-5#PBF
Digikey
$4.02
2
$8.04
MIC5209-3.0YS
Digikey
$2.02
2
$4.04
LED SUPER RED CLEAR 0603 SMD
Digikey
$0.22
100
$21.80
T1096-P5P-ND
Digikey
$17.78
1
$17.78
CONN POWER JACK 2.1MM PCB
Digikey
$0.93
4
$3.72
Soldering Flux 952D6 FLUX PEN
Mouser
$6.72
1
$6.72
Solder Removal PROWICK
Mouser
$3.01
1
$3.01
IC 8BIT SHIFT REG 3ST-OUT 16SOIC
Digikey
$0.59
14
$8.26
RES SMD 330 OHM 1% 1/8W 0805
Digikey
$0.02
100
$1.96
RES SMD 10K OHM 1% 1/8W 0805
Digikey
$0.10
8
$0.80
RES SMD 22 OHM 5% 1/8W 0805
Digikey
$0.10
6
$0.60
Digikey
$0.79
4
$3.16
Digikey
$0.65
4
$2.60
USB Type ‘B’ Female connector Sparkfun
$1.25
2
$2.50
$1.64
1
$1.64
Breadboard
$4.88
$11.48
LED's
Wall Plug / Power Jack
Soldering Supplies
Shift Registers
Resistors
Crystal Oscillator
CRYSTAL 16.0000MHZ 18PF SMD
Switches
SWITCH TACTILE SPST-NO 0.05A 12V
USB
Pin Headers
CONN HEADER VERT DUAL 36POS 2.54
Digikey
23