Final build jitters, any help/thoughts/censures welcome.

So I got a box full of components, I have bread-boarded and programmed a functioning prototype, and am ready to let the solder fly. However, since this is my first Arduino/electronics project and some of what I am doing I do not entirely grok, I am not 100% certain that I am not missing something or making glaring error that may come back to bite me later. Anyhow below I'll post a schematic of my final design, a Fritzing of my prototype and add an attachment of my code. Any criticisms/critiques ( from the general electronics, and coding to the drawing of the schematic or even the grammar of this post) will be much appreciated.


MDSfinalSketch.rtf (13.2 KB)

LM7805 datasheet says C1 should be .33uF and C2 should be .1uF. An LM1117 recommends 10uF.

When building circuits you should plan on a .1uF cap for each IC between VCC and GND as close to the chip as possible. De-coupling. I'm assuming you're building a standalone circuit without a full Arduino board in your final project.

I don't see any other problems.

LM7805 datasheet says C1 should be .33uF and C2 should be .1uF.

C1 and C2 can really be just about anything reasonable, eg in the range of 10-47 uF or
so, however, you "definitely" need a 0.1 bypass cap in parallel with C2, and preferably
as Chagrin says, right at the chip Vcc pin.

And don't forget a pullup on the Rest pin.

Also, schematics are much easier to read if you would start using ground symbols
instead of snaking wires all over the place.

Thanks for the input

Also, schematics are much easier to read if you would start using ground symbols
instead of snaking wires all over the place.

so more like this?

Why bother with R12, R13? Just just use the internal pullups, with switch closure connecting the pin to Gnd.
R14 - make it 10K.
Add a 2nd 0.1uF cap for Avcc. 0.1uF caps should be mounted close to the VCC/AVCC pins.
Need Gnd connection for Battery -.

How will you re-program and/or debug?
You have D0, D1, free - I would add a 5 or 6 pin header to be able to connect a FTDI Basic or similar for downloading sketches:
DTR to 0.1uF cap to reset pin

Lot easier than pulling the chip over & over to reprogram it - avoids damage from bent legs & stuff.

Make sure the pinout matches so you can just slide the programmer on & off.

Fritzing - no pin #s on the uC?

He's not using any analog inputs so the .1uF on AVCC shouldn't be needed.

When I raised the question about handling the reset pin I was given advice to leave it unconnected that I found pretty hard to ignore, but Atmel's guideliness would be the way to go if you're planning on creating an FTDI header.

R12 and R13 are there because all of the tutorials I studied had them. If it'll work without 'em consider them gone.

This is just a silly one-off gadget so I don't intend to do any reprogramming, the de-bugging I believe has been handled in the prototyping. thus no FTDI.

As far as the gnd connection for the battery, do you mean add one to clarify the schematic?

since I was using a switch to interrupt the power supply and reset the sketch I didn't think I needed to address the reset pin on the IC. I added it cause I thought maybe the chip itself needed it. If not I'll remove R14 as well.

Fritzing - no pin #s on the uC?

what is the "uC?"

I think I'll bead-board a final version without the Arduino and test whether leaving those res's and caps in or taking then out works best (or at all) before I get to soldering.

Thanks again,

As drawn, the battery- and Gnd are two seperate circuits. Add a Gnd symbol to battery- to show they are meant to be connected.

You have a lot of LEDs with a lot of current switching going on. Keep Reset pullup resistor to keep things stable.
Same for cap on Avcc.

How will you bread-board without pin #s on the microcontroller (uC)?

Yeah, better to keep adding ground symbols beyond what's shown in reply #3, ie,
separate symbols on the power supply and also the xtal grounds. It's obvious how
much clearer the new schematic is.

The other thing is, when you do this you tend to, in effect, "modularize" the ckt
into functional parts, and it's easier to think about how it works that way. Same
for software modularization, same for hardware. Otherwise, it's all spaghetti.