I can see that it wouldn't work if the RST pin was constantly LOW, but I have a 10k pull-up that forces it HIGH. The programmer (my arduino) or a simple button will force it LOW thus resetting it or making it capable of being programmed, won't it?
You assumption is right .... I'm not sure what else to tell
Add a 470nF ceramic cap across the rails to this schematic and you have it: http://www.open-electronics.org/wp-content/uploads/2012/03/Arduino_standalone_minimal.jpg
Here's the board layout: http://i42.tinypic.com/2qakbdg.png
I don't have a logic analyzer. I don't see anything when scoping, but that might just be because things are happening very fast. I don't know how the actual uploading is happening, but I can assume that it's some communication back and forth? If the programmer isn't receiving an acknowledge after the first package, it might just sit there waiting? I've assumed that this first package is transferred too fast for me to pick it up on the scope
No, not quite. With a pull-up, if there's no overriding input, the RST pin will be high, but as soon as there's another signal with lower impedance, it will win. Not pulse, just stay at the level supplied. So a low-impedance DTR LOW signal should hold the pin low until it is removed. The only time it wouldn't is if 1) there's already a cap in your programmer cable, so it pulses instead of holding low; or 2) the DTR pin has an impedance close to, or more than, your pull-up resistor.
I see some problems...Pin 21 (the 4th down on the right side) is Gnd, but you haven't connected it.Pin 20 (the 5th down, just below 21) is Aref and should have a 0.1uF to Gnd if you intend to use analog inputs.It looks like you're tying SHDN on the MCP4231 to Vcc, which makes it pretty useless. (Edit: Oops, no, it's active LOW, nevermind.) Why is R7 there, on the clock inputs between the two MCPs? You're grounding WP on the right one, and not on the left one. Is that intentional? There's a (weak) pull-up on that pin, so the grounded one will not accept changes but the other should.I haven't gotten a whole lot farther than that... Without knowing what other parts of this circuit do, and having the pinout for the LCD, I can't check it 100%. Do you have a schematic? It would make it easier to spot errors. Already though, I fear there are enough mistakes to make this PCB design suspect. (Sorry. Happens to all of us.)
Not sure why I have such a difficulty understanding this Isn't the RST pin tied to GND during the uploading? If there's just a short pulse on the RST pin, how does the MCU know when to stop downloading code and start running the program?
If you take a look at the "how-to upload bootloader" and the "arduino standalone" schematics and tutorials, there is no mention of this cap so I can only assume that it's already on the Arduino board.
It's not like the MCU uses so much current that a single pin can't handle it? What purpose does the different GND and VCC pins have?
As for the power and ground pin discussion --- I was not aware the AVR connected these internally. It seems to defeat the point somewhat if this is true. AFAIK, the whole motivation for separate analog pins was to be able to isolate digital and analog power rails, including the grounds, at least back to some common star ground point. If the grounds are connected internally, you don't really have that option anymore. If they're connected internally, I don't know why they are separate pins, except maybe better fault tolerance and internal current sharing. It seems leaving any of them disconnected is probably not a great habit to get into regardless though.
why would a DTR signal need to be "wiggled in a timely fasion" at all? Even if it took two and a half hours to assert and release DTR, that would still be a "pulse", technically, and sufficient to properly reset the chip.
As to the behaviour of the IDE to the serial ports, it does exactly as it should - opens the port, issues the download, and closes it again (so that another program such as the serial monitor, can then use it). DTR reflects this operation - correctly. That you can use this as a reset signal - using the capacitor - is a convenience, but no justification to have the signal behave in anything other than in a standard manner. There is nothing to criticise about this behaviour.
not quite. bootloaders have a limited timeout and anything more than a few seconds (milliseconds with modern loaders like opti) will not work.
also note that sometimes pulse is generated on software high rather than low so pulse goes out on trailing not leading edge. ive seen cases where poorly written drivers took a minutes or two to reset the chip. NOT good.
I don't understand what you're saying here. What do you mean pulse is generated on software high? The Win32 API seems to be pretty clear on what happens based on the constants in the DCB, or the parameter sent to EscapeCommFunction. I don't think it's likely to be inverted. If it is, that's a bug in the driver.