[ard]

this works super well for me, spycatcher2k. although the timing of tapping the standalone atmega chip's reset has to be really on the mark!

Question:
what could be a way we can make this self-controlled? so that you can keep the atmega chip on the arduino ISP and still not have to manually mess with the standalone atmega chip's reset wire each time to be programmed.

To upload to your standalone :
(ard - Arduino & std - stand alone)

ard rx - std tx
ard tx - std rx
+5 to +5
gnd to gnd

no power on std
short ard reset to ard gnd

remember to select the type of chip you are uploading to
click upload on IDE
wait for sketch size
tap std reset quickly

Drew.

Mike, just read your webpage. So it seems, as do Arduino inputs unless pulled-down or pulled-up, the human body is acting like an antenna and picking up signals from the air, but scientifically, what exactly is happening? What does "signals" mean... electrical interference but how exactly is that completing the circuit here? I'm only touching one end of the resistor (with my body closing that circuit to neither + nor GND), meaning the circuit is still floating, so what exactly is activating the transistor base to let current flow through the LED?

maybe I can use this technique for some interesting applications:
-as a very neat and comfortable pushbutton/sensing device
-a rough way to indicate/measure the presence/strength of signals in the environment
-maybe to measure some property (?) of the object touching the resistor

maybe this is common knowledge but I learned/saw something interesting today. I still don't fully understand it, but here is what I did:

I'd bought a 2N2222 transistor, and was unsure which end was emitter and which the collector. I don't know much about transistors, so I decided to just play with both options. So I set things up like this on my breadboard first:

battery +  -> 200 Ohm R -> LED -> one random end of 2N2222 -> other end of 2N2222 -> battery GND

and from the base of 2N2222, I put a resistor (100 kiloOhm, thinking to limit the current)

from there I was ABOUT to connect a wire from this resistor's end when my finger accidentally touched the resistor (which at this point only had one end connected to the base of the transistor; the other end was just floating).
And every time I touched the resistor, the LED lit up!

it was pretty cool to see it. now trying to read up some theory, but wanted to report here first!
here are doubts that I hope to clarify:

1) why did this touch thing happen? it was like an Iphone screen-touch effect when it first happened... although I know iphone displays use capacitor-related stuff. it can't be magic/mistakes; human body conduction maybe, but current needs TWO endpoints to flow... can't put a full story together..

2) when I exactly reversed the transistor's collector-emitter order from the above test, the same effect still happened but the LED was lit much more dimly when I touched the floating resistor. assuming the other collector-emitter order was correct, why did the LED still light up at all in this reversed order case? and why dimmer?

3) and finally, is there a quick(er) way of knowing (without datasheet) which end is emitter, which the collector of a transistor like this? I believe there is supposed to be a diode effect happening between each end and the base, so perhaps I could test something related to the current direction?

Cool, so what exactly is happening exactly when I did the following?

--I left arduino's atmega on the arduino just as it is, throughout the following steps...
--insert standalone atmega on breadboard
--connect up the circuit as shown in ArduinoToBreadboard tutorial (i.e., with SCK, MISO, and MOSI pins of arduino and of standalone atmega chip connected to each other)
--reset pin of standalone atmega chip (datasheet pin #1) with pull-up resistor, as well as a cable to pin #10 of Arduino (which is used in the ArduinoISP sketch for slave reset)
--arduino reset pin never handled by me (i.e., left open)

--I loaded ArduinoISP sketch to arduino
--burn bootloader using ArduinoIDE's Tools > Burn Bootloader command.
--then use AVRdude to load a hex file, e.g. avrdude -c avrisp -p m328p -P com3 -U flash:w:Blink.cpp.hex

The visible result is that everything worked fine... the Blink program is indeed uploaded, as I checked by placing an LED on standalone atmega chip.

But is there anything wrong with this approach of uploading code to the standalone chip? (i.e., with Arduino's atmega chip and reset pin left untouched, and shorting MOSI, MISO, and SCK pins between Arduino and standalone atmega chip)
I guess my question is...
What is the difference between that approach VERSUS the other approach discussed in this thread (i.e. where we first remove the Arduino Atmega chip from the board and ground Arduino's reset pin and then upload to standalone chip via ArduinoIDE/AVRdude with the RX and TX pins cross-connected?

I'm thinking what you guys are describing is, e.g., the breadboard circuit in this tutorial (with arduino pin 10 to reset, and pins 11, 12, and 13 the serial programming pins) am I right?:
http://arduino.cc/en/Tutorial/ArduinoISP

If so... I'm a little confused on what exactly is happening differently (in context of Arduino-as-ISP) between writing programs to the chip on the Arduino board vs. writing programs to the external chip?
I'm guessing it's related to Reset... what precisely is the function of reset here?

Based on what I've understood, reset serves to trigger the microcontroller to re-initialize, thus be open to (with the original bootloader still in place) new uploads, or if nothing is incoming, just lets it re-run the existent program in its memory. So, when @retrolefty suggested grounding the Reset pin on the arduino while loading programs to an external chip, what does that do?
(Reset is active low based on datasheet, so I understand somewhat...)

[Question:]

thank you! just plugged in a just-received 16mhz and the led blinks at the right speed now.

@westfw:
compiling in verbose mode, DF_CPU does indeed read 16000000, so that makes sense now as far as the program's expectation goes.

Question:
I'm now reading a couple of people's documentation regarding setting fuses via avrdude to have the ability to set a specific frequency according to the particular crystal I use, but in the meantime:

Atmega8L (not the 8, but the 8L) has a speed grade of 8 Mhz, as listed on datasheet (I'm assuming "grade" is a less specific way of saying recommended/maximum external clock frequency?).

Then, why is it that upon using 16Mhz crystal, the LED blinks at the correct rate? Maybe, the correct blinking is because the program is compiled with a 16Mhz expected config, but restating, why is it that the atmega8L is STILL functioning correctly with the 16Mhz crystal, despite that being beyond the "speed grade"? Perhaps it's expected to just be less RELIABLE at a crystal beyond the datasheet-listed speed grade?

hehe shoot, such an obvious reason huh?

but hmm wondering why the LED is not blinking exactly HALF the speed (it's blinking around quarter or less the speed) if I'm using a 4 mhz. maybe it has do with the fact that the frequency dictates the number of instructions executed per second, to which the LED blinking might not be linearly proportional because of the presence of other operations in the code. just ordered some 8 mhz crystals; will do some timing tests soon.

[Setup:]

Setup:
I'm using Arduino as ISP to burn small programs onto an external Atmega 8L chip on a breadboard, with a 4 MHz crystal (don't have an 8 MHz lying around), and an LED on one of the digital pins.

For example, right now, I burned the Blink program (with 1000 msec interval between pin HIGH and LOW in the code).

Problem:
Everything works fine, BUT the blinking happens every 3-4 seconds instead of the coded 1 second.
(Similar things happened with Fade program, etc.; everything works but seems to slow down a few-fold)

Wondering why this might be..

I suggest you download winavr here:
http://winavr.sourceforge.net/index.html

then try uploading using avrdude. you have to use commandline... you can find many tutorials for this, like this one:
http://jimsmindtank.com/using-the-arduinoisp-sketch-part-2/

post what happens after that step

@luky83.. the first one might be pretty straightforward. tell me:
1) what are the destination addresses that you set on the coordinator and on the router? they should complement each other. also, the PAN ID, the channel number, etc. should match but these are probably fine if it's already working one-way but do check. Run "ATNR0" on the router's X-CTU terminal to synchronize its network info with that of the coordinator (while of course keeping the coordinator powered at the same time).
2) what do you mean by "transmit" - what exactly are you sending from one to the other, and how are you reading it?

[Problem]

Here is the promised note, based on problems I solved over the last week as well as other problems, hoping it might help someone. Nothing is guaranteed to be perfect theory; just my thoughts/readings!

1) Problem: Is serial transmission via Xbee not working after you upload code to the Arduino on which the XBee is sitting? Or, instead, is code not uploading to Arduino when the Xbee is sitting on the Arduino via a shield?
Solution: If you use a typical Arduino Xbee shield, you need to set the two jumpers toward the label "USB" when you're UPLOADING code to Arduino, and you need to set the jumpers toward the label "Xbee" when you're using the Xbee to transmit data. This is related to the RX-TX configuration. More about this here: http://www.arduino.cc/en/Main/ArduinoXbeeShield

2) Problem: Does transmission from router to coordinator keep Resetting and/or going back to re-start?
Solution: Also, if you use a typical Arduino Xbee shield, the CTS (clear-to-send) line of the xbee will in most cases be connected to the Reset of the arduino. This will affect things in various ways; one simple example is, if you send out an incrementing array of numbers from your Router (situated remotely on Arduino shield) to your Coordinator (let's say situated on a USB explorer-type connection to your PC), to be read on your PC's serial terminal for the Coordinator's serial port. You will see that the array of numbers will print out well, but then after a set amount of time, it will restart from the beginning. This will happen repeatedly.
The Arduino is being reset by the CTS line of the xbee. Either physically cut off the connection between Arduino's reset via the shield to the DIO7 CTS pin of Xbee.
Or easier, while setting the Xbee command sequence, via the terminal, let's say in X-CTU, turn that functionality off by simply typing "ATD7 0".

3) Problem: Is the Router not sending information to Coordinator, even after you set up both Xbee modules and configured them on X-CTU?
Solution: A good method to follow, apart from setting common PAN ID, etc., to ensure that the network is matched up is to begin the configuration via terminal, of the Router Xbee, and then type "ATNR0", which sort of resets the network but does something important: it equates the PAN ID and something else called "operational PAN ID" to match that of the coordinator. While you're configuring the Router XBee as such, just ensure of course that the Coordinator Xbee is also powered and active, let's say on a separate port, on a powered Arduino via a shield, or via battery, whatever.

Feel free to ask here or shoot me a message if you have problems.

Thanks for the tips guys!
Things are working out (at least for my case); was a combination of RX and TX on the shield, as well as some AT commands for the Xbee.
I'm preparing a small note that I'll put up some time this weekend (when I'm free from classes!)... with a general layout of steps to use for this kind of setup, for permanent reference.

[Problem has been solved, and VARIOUS SOLUTIONS to this and other problems provided on Reply#5 in this thread (http://arduino.cc/forum/index.php/topic,53971.msg392881.html#msg392881).]

Problem has been solved, and VARIOUS SOLUTIONS to this and other problems provided on Reply#5 in this thread (http://arduino.cc/forum/index.php/topic,53971.msg392881.html#msg392881).


I'm using:
--Arduino Uno
--a pair of Xbee Pro Series 2-B modules
--the first Xbee connected to the Arduino via an Xbee shield
--the second Xbee connected to the computer's USB port via a USB "explorer" board

GOAL
When I Serial.print something in an Arduino program, I want it to transmit via the 1st/node Xbee sitting on the Arduino shield, so that the information is printed on the Serial output for the 2nd/coordinator Xbee (...and vice versa).

What I've done

I have got everything configured using X-CTU/terminal software, and the 2nd/coordinator Xbee even recognizes the 1st/node Xbee (as tested by ATND command), so no problems there at all.

Then I uploaded a simple program in the 1st-Xbee-connected Arduino (COM3) that outputs "ABC" on the serial output.
Then I opened a separate terminal for the 2nd-Xbee-connected USB explorer board (COM4).

PROBLEM

I cannot get ANY serial output in the terminal for the 2nd/coordinator Xbee, matching the Arduino IDE serial output transmitted via the 1st/node Xbee.
Seems basic, but I think I'm missing something!
Anyone gotten this to work?

Based on what I read in what some people have written, I think the problem might be with the RX, TX pins/crossover, OR with the USB-versus-Xbee jumper selection on the Xbee-Arduino shield. But both of them are confusing me.
Could anybody clarify?

Side-observation
Perhaps related to above... I've also noticed that when I load the code onto just the Arduino by itself, then the serial output in the Arduino IDE terminal is fine (it's a simple Serial output program). But when I then insert the Xbee shield on top, and then open the Arduino IDE terminal again, suddenly the IDE freezes!

What is a program you can recommend to make schematics like that in the original post?

are you being sarcastic, Coding Badly?

if not, here are instructions:
http://www.arduino.cc/en/Guide/Windows#toc4

my reply was aimed for Riesko's problem...