Hi,
I'm basically using a pushbutton counter sketch for counting pulses.Those pulses I'm sending it throuh serial to an excel sheet.There, with NETCOMM I'm reading them at real time.
Well, my problem is following:
90% of the time it works well, but sometimes- I don't know the real cause- the communication blocks and I have to reset the sketch and the counter starts again, so I'm loosing all the measured pulses.
It's crazy ,because when the communication blocks ,the arduino sketch is still working(Ican see it on the blinking led):
So I've been thinking to save the value of the counter to the EEPROM, but I don't know how would the best way for doing it.
Obviously it has no sense to do it continuosly ( I'm counting pulses at an average of 8 per second...about 30000 per hour), so in 3 hours my EEPROM wil be burn...
Any idea or suggestion?
Also with a little help with the sketch code would be grateful !!
If you can't find the reason for the hang, then
"when the communication blocks ,the arduino sketch is still working(Ican see it on the blinking led)"
add a push button to store the current count before restarting the sketch.
*/ Pulse counter with debounce filter */
// this constant won't change:
const int buttonPin = 2; // the pin that the pushbutton is attached to
const int ledPin = 13; // the pin that the LED is attached to
// Variables will change:
long buttonPushCounter = 0; // counter for the number of button presses
int buttonState = 0; // current state of the button
int lastButtonState = 0; // previous state of the button
// the following variables are long's because the time, measured in miliseconds,
// will quickly become a bigger number than can be stored in an int.
long lastEvent = 0; // the last time the output pin was toggled
long interval = 20; // the debounce time
void setup() {
// initialize the button pin as a input:
pinMode(buttonPin, INPUT);
// initialize the LED as an output:
pinMode(ledPin, OUTPUT);
// initialize serial communication:
Serial.begin(19200);
}
void loop() {
// read the pushbutton input pin:
buttonState = digitalRead(buttonPin);
// compare the buttonState to its previous state
if (buttonState != lastButtonState)
{
// if the state has changed, increment the counter
if (buttonState == HIGH && millis() - lastEvent > interval) // <-- Ignore last press if it is too close to the last one
{
lastEvent = millis(); // <-- record when the last good event occurred
buttonPushCounter++;
Serial.println(buttonPushCounter,DEC);
}
else {
}
}
// save the current state as the last state,for next time through the loop
lastButtonState = buttonState;
// turns on the LED every five button pushes by checking the remainder of the division
if (buttonPushCounter % 5 == 0) {
digitalWrite(ledPin, HIGH);
} else {
digitalWrite(ledPin, LOW);
}
}
the code really works fine. It doesnt hangs..the problem is in the Excel sheet and/ or communication through NETCOMM or the event...but I don't want to fight with it...I prefer t osave the value of " buttonPushCounter"
About he suggestion of CrossRoads, "...add a push button to store the current count before restarting the sketch." That's a good idea...but how would you do it?
Read another pin as part of loop, if its low (pressed) then store whatever you're saving to EEPROM.
Here's how I did similar to save two bytes, and check for them on startup. This was part of void setup.
Save a byte into EEPROM when you make the switch, have the sketch read the EEPROM in void setup and set your program selection flag appropriately.
This is kinda long, I stored two bytes that got put together to make an address (and theres a bunch of print statements from my debugging), but I think you can get the idea of what to do.
Altho reading this, this is only the readback part - there is a similar part for storing an int as two bytes when a button is pushed that I can't post until tonight.
//Serial.print ("EEPROM 0, 1 = ");
// check if loading from EEPROM
lowEEPROM = EEPROM.read(0);
Serial.print(EEPROM.read(0));
highEEPROM = EEPROM.read(1);
Serial.println (EEPROM.read(1));
EEPROMend = (highEEPROM<< 8) + lowEEPROM;
Serial.print ("EEPROMend = ");
Serial.println (EEPROMend);
if (EEPROMend == 0 || EEPROMend == 0xffff){
// do nothing, normal startup waiting for data via serial port
}
else {
// EEPROM had been previously loaded, start showing it
//dataEntry = Memory;
displayEnd = EEPROMend;
for (x = 2; x<EEPROMend +1; x=x+1){
Serial.print ("Writing array address ");
Serial.print (x, HEX);
displayArray = EEPROM.read(x);
Serial.print (" ");
Serial.println (displayArray
);
}
}
// Serial.print ("dataEntry source (1=PC, 2=EEPROM)" );
// Serial.println (dataEntry);
If you decide to take the approach of saving the counter when a button is pressed, make sure you detect button state transitions and only do the save when the button is pressed (ore released). If you were to save the counter each time you saw the button was depressed, you could end up saving it very frequently and use up the life of your EEPROM.
It seems to me that you'd be better off solving the stability problem, which may be outside the Arduino. As a first step I'd replace the current sketch with something much simpler that just generated some realistic output at the expected rate so that you can eliminate the complexity of your sketch from the problem.
Thank you both,
to Crossroads: thank you but it seems very difficult to implement to my sketch..maybe because I' m a starter..maybe because I don't understand very well your sketch...I don't know how to proceed for going on...
To PeterH:well, maybe my sketch could be much easier.But as I told you before when the serial communication crashes ( as I said before probably due to fragile management of the communication through NETCOMM), the sketch seems to continue working fine...it's only I can read the pulses on my excel sheet:I have to reset and stablish again the communication with the result of loosinf the counted pulses until this moment.
So I didn't think that an easier sketch will solve the problem but please send me your proposal and I'm going to test inmediately and tell you the results.I'm wondering if it would work!
If it helps I'm counting pulses with a reed sensor, between 2 and 20 pulses per second.