mem - you sir win a cookie.  I upgraded to v18 and it is now running perfectly.  I'll have to try my original code with the rest of the software but the timer works fine now  

Alright, I switched over to using Serial.print and watching on the console and it's running spot on at 4 minutes.

I'll figure out who wrote the LCD library and follow up with them, obviously there's something in that library messing up a timing routine.

Thanks for your help guys.

It's now been running for:
33 minutes 43 seconds
clock time,
arduino says:
33 minutes 30 seconds

I'm using a stopwatch for comparison, I previously tested the stopwatch against http://www.time.gov/timezone.cgi?Central/d/-6/java for ~8 hours without losing a second, so for now the stopwatch is much more accurate than the Arduino  

Why are disabling interrupts before calling millis?

That's covered further up this thread, someone suggested that an interrupt would corrupt data from the millis call, doesn't seem to have any effect in my testing.

Why are you calling delay?

Delay is so the screen flicker on the LCD display isn't terrible.  If you run it any faster than 150 milliseconds it starts to blend things together (when the milliseconds readout is running, which isn't in this code).

There are more efficient ways of computing new values for minutes and hours.

I agree that when possible the most efficient path to the objective should be used, but fundamentally does it matter in this loop losing time?  Since the loop is just counting up how many milliseconds have iterated between loops and adding it to a value I don't think it has any effect on the loss of time (which is what I'm worried about before beginning to optimize anything).

mem says: perhaps try something like this: . . .

I ran this, after about 3 minutes the Arduino was off by exactly a second, it again is running too slowly.


The only way this could be happening is if the millis() call isn't returning the correct time, which is a function directly of the processor crystal right? Can anyone else test this code (mem's) and see if they're having similar results?  I'll run this code on a mega later today and see if I have similar issues or if things clear up; until then any other ideas?

Thanks everyone for help!

Alright, things aren't working so hot :-(

I'm running this code:

Code:

#include <LiquidCrystal.h>
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

unsigned long current_millis_value = 0;
unsigned long previous_millis_value = 0;
unsigned long m = 0;
unsigned int seconds = 0;
unsigned int minutes = 0;
unsigned int hours = 0;

void setup()
{
  lcd.begin(2, 16);
  lcd.clear();
}
void loop()
{
  cli();
  current_millis_value = millis();
  sei();
  m += current_millis_value - previous_millis_value;
  seconds += m / 1000;
  m = m % 1000;
  minutes += seconds / 60;
  seconds = seconds % 60;
  hours += minutes / 60;
  minutes = minutes % 60;
  hours = hours % 24;
  previous_millis_value = current_millis_value;
  lcd.clear();
  lcd.print("t:");
  lcd.print(hours);
  lcd.print(":");
  lcd.print(minutes);
  lcd.print(":");
  lcd.print(seconds);
  
  delay(150);
}

on a Duemilanove and am able to watch the Arduino run too slowly (loses 1/2 a second in the first minute).  Anyone have any thoughts?  Are there delays/interrupts in the LCD library?

I just need a timer that counts up accurately when some event is true, it only needs to run for about an hour max so the overflow isn't an issue at all for me.  Is there a better/more precise way to be doing this?  I've dug through the code and stripped it down to what you see, there isn't much left except for the LCD screen writes that could be losing/taking time but I shouldn't matter how long the program since that's all accounted for.

Any thoughts?   >

Yes, it does :-)

Can you use characters as case variables though?  I have the code working using integers but i really want to use characters as it makes the code so much clearer.

IE this works:

Code:

 switch(axis) {
    case 1:
      code = 0x06; //Set register for X data
      break;
    case 2:
      code = 0x07;
      break;
    case 3:
      code = 0x08;
      break;
  }

Hello,

I'm trying to use the 'switch case' to choose between cases with my accelerometer:

Code:

 switch(axis) {
    case 'X':
      code = 0x06; //Return register for X data
      return code;
      Serial.println("Found X");
      break;
    case 'Y':
      code = 0x07;
      return code;
      Serial.println("Found Y");
      break;
    case 'Z':
      code = 0x08;
      Serial.println("Found Z");
      return code;
  }

the serial println's are there for debugging, I never see any output so it's never getting to any of the cases.  I'm pretty sure it's because it's not correctly comparing the axis being passed in to the character in each case.

Here's the calling code:

Code:

 //Handle Accelerometer

    Serial.print("X Data: ");
    xValue = getAccelData(X);
    Serial.println(xValue);
    
    Serial.print("Y Data: ");
    yValue = getAccelData(Y);
    Serial.println(yValue);
    
    Serial.print("Z Data: ");
    zValue = getAccelData(Z);
    Serial.println(zValue);
    delay(500);

Can you only use integers with switch cases?

noob mistake :-)  Works perfectly now.

Thanks for the help, I'll format things correctly in the future.  I chopped up the code because I didn't want people getting hung up on other things.

Thanks for your help!

I'm getting this error whenever I use a variable to define an address using the requestFrom function in the Wire.h library:
"error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:

. . . libraries\Wire/Wire.h:52: note: candidate 2: uint8_t TwoWire::requestFrom(uint8_t, uint8_t)"

Code in question:
#include <Wire.h>

byte max6965 = 32; // write to device 40h (01000000 binary), shifted gives 0x20

  Wire.beginTransmission(max6965);
  Wire.send(address);
  Wire.endTransmission();

  Wire.requestFrom(max6965, 1);  //TROUBLED LINE
  if(1 <= Wire.available())    // if 1 byte was received
  {
    reading = Wire.receive();  // receive high byte (overwrites previous reading)
    Serial.print("RAM Holds: ");
    Serial.println(reading);   // print the reading
  } else {
    Serial.println("Sorry, the LED ram appears to hold no data");
  }

*****
Serial print stuff is just for debugging.  Any ideas?  I'm guessing this has to do with how the variables are handled in the actual Wire.h library.  I tried declaring max6965 as an int or a byte when passing it into the wire.requestFrom function but it didn't help.

Anybody ever looked into using an Arduino as a cheap HART industrial bus communicator?  I need a HART transceiver for work and don't really want to buy one :-)

http://www.analogservices.com/about_part0
http://en.wikipedia.org/wiki/Highway_Addressable_Remote_Transducer_Protocol

Anybody ever get this figured out?  I'm using a CP2102 USB->TTL converter with Windows 7 and Windows XP, using the Arduino host the reset pin is never asserted low so you have to manually trigger the reset when programming.

Anybody know if there is anyone selling the bare board for the Arduino Pro Mini board?  I really like the form factor but $19/each is way too expensive for whats on the board.

On the same topic, anyone interested in having boards made and splitting the cost?  :-)

You can also get free samples from http://freescale.com

Direct link:
http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=0112691118

Watch the packages though, most of those are surface mount reflow chips :-)

I'm pretty sure you're going to need all 3 data pins to make it work:

http://www.totalphase.com/support/kb/10045/

I would suggest posting on the Arduino forum specifically asking if you can use SPI with only 2 wires.  If you configure the accelerometer for I2C communication you could then use 13, 14 without pin 12, but then you will no longer be able to use my code.  You might consider purchasing a different accelerometer that does analog output like one of these:

http://www.sparkfun.com/products/252

Accelerometer Pin -> Arduino Pin
1 -> 3.3V
2 -> GND
3 -> GND
4 -> GND
5 -> GND
6 -> 3.3V
7 -> GND
8 -> NO CONNECTION
9 -> NO CONNECTION
10 -> GND
11 -> GND
12 -> SPO Pin 12
13 ->SPI Pin 11
14 -> SPC Pin 13

SPI is a standard interface, meaning that no matter whose sketch you're running you always use the Arduino SPI data pins that I linked to above in the Arduino playground.  (Others - yes, I'm sure you can change those data lines, but there are certain capabilities needed of those pins so using the standard pins is a good idea, YMMV)

Try those pins and see what you come up with, there's a chance you'll have to switch the accelerometer pins 13 and 14 oppositely, meaning if things aren't working try swapping what's hooked to pin 13 -> 14 and pin 14 -> 13