Put this subroutine at the end of your code...

Code:

void stop_program_here() {
  Serial.println("Program Stopped");
  for(;;);
}

And then go through your code bit by bit and tell us what state each output is in.

To do this just put this line in your code where you want it to stop...

Code:

stop_program_here();

It may be possible that you are using the wrong analogue pin, or don't have a common ground to the sensor.

You may want to print out to the serial monitor what value the analogue input is reading, see if it is what you expect.

ok, so...

Just to clarify: You want us to stop what we are doing and write some code for you?  For free?

Hey loyla,

That's ok, how much programming experience do you have?

Why not give it a go yourself?

We would be more than happy to help you if you make some code that doesn't work and posted it up here.

Just look into delay and digital write.

I think that you should have a close look at http://www.nxp.com/documents/application_note/AN10216.pdf

This is strongly supported by the Arduino by the "wire" library and is very easy to use.

You could also look into the "wire" library, as the I2C protocal is for a bus.

For error detection, I'd be inclined to use a credit allocation flow control mechanism.  Basically everything you send has a register/memory location and data to go with it.  The first device (sending the data) sends an 'S' for send, the register/memory location, and then the data.  The other device responds by sending 'A' for acknowledge, the register/memory address, and the data received.  If the received package is different, or if there is no response in a predefined time, resend the package.

The best way of knowing the answer for such questions is to try it.

Everyone can have their own opinion: But if it works, it works!

If it doesn't, just make a function called delay_8min().  Check the millis time when you start the function and stay there until millis equals:

Start time + 8 minutes

and...
8 min = 8 min * 60 sec/min * 1000 msec/sec = 480,000msec

Too easy!

If you wanted to go this way, what you can do is create a variable that increments every time it sees a positive reading and decrements when it sees a negative reading.

Set the variable range so it stops decrementing at 0, and incrementing at something like 20.

If it is over, say, 10, consider it on.

ie.

(pseudo)
if button is pushed

if reading gauge is under 20

increment reading_guage

[/list]
if button is not pushed

if reading gauge is larger than 0

decrement reading guage

[/list]
if reading gauge is larger than 10

button is pushed

(/pseudo)

This method works well if you are continuously polling for the buttons value (checking over and over).

Connect your robot up to the computer serially and follow it around.

Print the sensor value on the screen every 0.2 seconds and see what is happening.

(In my opinion) I think that "Linked Lists" are a good way of doing menus.

There is a section for this in the book "C: The Complete Reference" (great book)

I found something for you to look at http://cslibrary.stanford.edu/103/LinkedListBasics.pdf.  Basically, you use a "next"/"previous" approach, and I have found it to be a successful way to use XML data.  The trick is that you add another pointer called "parent"; you go through the list and print every element with that parent.

There is also a library out there somewhere if you keep digging around.

If you have lots of strings, it is best to look into PROGMEM

If I can't convince you that debouncing is a good idea because of the advantages given in the article you posted, I'm going to stop with this thread now.

A Digital signal is just an interpretation of an analogue signal and obeys the analogue laws, such as attenuation.  If the signal to noise ratio (SNR) is not large enough, your chances of reading a false reading are much more probable (this is the power of the signal, not voltage).  

Because we are dealing with small currents here (hence lower powered signals), false readings should be a concern.  The problem with impulse noise is that it is a high powered signal, which can be caused by coupling with a light being turned on or off (not just a brush motor).

It would be wrong to assume that the switch used in Joker's project is of ideal nature.  How long are the wires? How thick are the wires? What possible sources of noise are there where their project is designed to run?  You don't know what environment and hardware Joker's project will be operating with, so saying that the probability of transmission impairments occurring is "very, very unlikely" is just not a good assumption.  What if the switch was to turn on a nearby "brush motor"?

On http://www.ganssle.com/debouncing.htm

The experiment in this article does not address the issue of any sort of transmission impairments (eg: attenuation, delay distortion, thermal noise, impulse noise, crosstalk, ...).  It does not say what power the signal it is, so it would be wrong to speculate; however, it does seem to be strong enough to ward off the effects of noise.

It also acknowledges the random nature of bouncing saying that 2 switches exceeded 6.4mSec in bouncing time, with one sample at 157mSec in opening (I'd put that switch in the bin).  This article finished by saying,  "Assume things are worse than shown".

If you then click on <Go to Page Two of This report> at the bottom of the page, there are many different techniques for solving the debouncing switch problem.  

It says, "But the environment itself can induce all sorts of short transients that mask themselves as switch transitions. Called EMI (electromagnetic interference), these bits of nastiness come from energy coupled into our circuits from wires running to the external world, or even from static electricity zaps induced by shuffling feet across a dry carpet. Happily EMI and contact whacking can be cured by a decent debounce routine. . . . but both factors do affect the design of the code".


The bottom line of what I (and page 2 of the article deSilva provided) was trying to say is that using debouncing methods in your code/hardware is good practice.  Also, methods for debouncing can usually double up as protection against some transmission impairments: Therefore, debouncing should NOT be omitted from your design as suggested by deSilva.

Actually, it's quite easy when the switch is in the other room and is connected with unshielded wire.  

If all digital inputs where 100% reliable, we would not need error detection (parity checks, cyclic redundancy checks, ...) on serial communication.

I'm sorry, but I don't think that to "just do it" when the first edge is detected is good practice (for a switch input).  This is because the chance of having a program long enough (quote "100ms") to oversee the bouncing is "very, very unlikely".

The edge detector, in my opinion, is much better suited to analysing digital data communication, rather than a switch input.

What do you mean by "TTL level"?  Are you trying to return a joke?  Microprocessors are built with CMOS technology.