Show Posts
Pages: 1 2 3 [4] 5 6 ... 17
46  Forum 2005-2010 (read only) / Syntax & Programs / Re: How to add variable to #define on: November 01, 2009, 01:37:51 pm
Where is PSTR defined? etherShieldNEW.h?

Let's see that also, please...
47  Forum 2005-2010 (read only) / Syntax & Programs / Re: How to add variable to #define on: October 31, 2009, 06:16:32 pm
Yes, you still aren't formulating the string correctly with sprintf.

I need to see more of your sketch code to advise you more. The link above at hetnet.nl is not valid.
48  Forum 2005-2010 (read only) / Syntax & Programs / Re: How to add variable to #define on: October 31, 2009, 11:49:39 am
You haven't used sprintf correctly.

Here's a small example of using it to format a number:
Code:

char str[4];
int rpm;

sprintf (str, "%3d", rpm);
lcd.print (str);

Make sure your buffer is one char longer than the string you want to represent so that it has a trailing null, required to represent strings in c.
49  Forum 2005-2010 (read only) / Syntax & Programs / Re: How to add variable to #define on: October 31, 2009, 09:19:00 am
You can find many examples of how to use sprintf by just googling "sprintf example c." Here is one.

The idea is that you declare a string buffer variable to receive the result of the formatting operation (sprintf). You give sprintf some variables and a string that contains formatting instructions. It substitutes the values of the variable you give it in the corresponding slots in the formatting string, and puts the result in the buffer you give it. The formatting string has all kinds of options to convert numbers to text.

I don't know what your PSTR call does, since you didn't post your whole sketch, but this should get you going.
50  Forum 2005-2010 (read only) / Syntax & Programs / Re: How to add variable to #define on: October 31, 2009, 08:42:22 am
#define pragmas are evaluated at compile-time, not run-time. So if you want to send a string whose value changes at various times while the sketch is running, you'll need to generate that string in your code.

You can use the C library function sprintf to generate a string from the value of variables and constants, then pass the result of that to the routine that sends the string to the server.
51  Forum 2005-2010 (read only) / Syntax & Programs / Re: Calculating RPM's... Problem in code... on: November 18, 2009, 10:08:45 pm
Yes.

In fact you should NOT compare to zero because you don't know how long all the stuff that happens before and inside the setup() function will actually take, and you don't know exactly when the millis() routine considers time zero. You want to save the clock time when you start the real work, which is right at the end of setup().

In your example, remember that one hour is 60 minutes * 60 seconds * 1000 ms = 60 * 60 * 1000 = 3600000 ms. This is why those variables need to be long, not just int. So you would add 3600000 to the startcount to get the endcount = one hour later.

Actually, I should have declared the timer variables as unsigned long, not just long, to get the maximum possible period. Even an unsigned int can only store a maximum value of 65,535.

In your example, each time through loop(), you would then check the current time [as returned by millis()] against the endcount:

Code:
if (millis () > endcount) {
  // time's up!
}

This is logically equivalent to my code, because:

Code:
if ((curTime - startTime) > period)  // is the same as
if (curTime > (startTime + period))
and (startTime + period) is just like your endcount = (startcount + 1000), except I used 3000 for three seconds.

Clear?
52  Forum 2005-2010 (read only) / Syntax & Programs / Re: Calculating RPM's... Problem in code... on: November 18, 2009, 07:39:57 pm
Try the program below. It will "beep" every three seconds. Is that the kind of thing you're trying to do?

Code:
const long period = 3000;   //  time interval you want to measure (ms)

long startTime;    // clock time at the start of the timer (ms)
long curTime;      // clock time each pass through the loop (ms)


void setup () {
  Serial.begin (9600);
  // save the current time
  startTime = millis ();
}


void loop () {
  curTime = millis ();
  if ((curTime - startTime) > period) {
    // time's up!
    // do something
    Serial.println ("Beep");
    // and reset the timer
    startTime = millis ();
  }
}
.andy
53  Forum 2005-2010 (read only) / Syntax & Programs / Re: Calculating RPM's... Problem in code... on: November 18, 2009, 06:54:53 pm
millis() simply returns the number of milliseconds since the Arduino was reset.

So the general strategy for timing is to save the value of this call at the beginning of the event you want to time. Then each time through loop (), you get the current value of mills () and subtract the saved start time from it. That tells you exactly how long it has been since you marked the start time.

When you want to reset your timer, you simply overwrite the saved timer with the current value of millis () and keep on going.

The advantage of this logic is that it is independent of the number of times through the loop or of what might be going on in the loop.

Does that make sense to you? Do you need a code fragment to illustrate the logic, or can you derive it for your app?

.andy
54  Forum 2005-2010 (read only) / Syntax & Programs / Re: Calculating RPM's... Problem in code... on: November 17, 2009, 08:21:54 pm
I implemented an RPM calculator with a Hall effect sensor on the frame, without using interrupts.

I offer an extract of my code below. This compiles, but I haven't tested this exact version. The program from which it was taken does work, though.
Code:
// a bike RPM calculator
// Andrew Davidson

const int magSensorPin  = 53;       // digital - Hall effect
const int revFlashPin   = 12;      // indicator LED for each revolution

const int magnetIn = LOW;      // sensor value when magnet is in range
const int magnetOut = HIGH;      // sensor value when magnet is out of range

const int revTimeout = 3000;      // if no revs in this period, wheel has stopped (ms)

int curMagState  = magnetOut;      // current state of the magnet sensor
int prevMagState = magnetOut;       // prior state of the magnet sensor

long curRevTime;            // clock time of the latest pass of the magnet
long prevRevTime;            // clock time of the prior pass of the magnet

long  revCount = 0;            // number of revolutions we've seen
int   magRPM = 0;            // RPMs of the latest pass (revolution) of the magnet


void setup () {
  pinMode (magSensorPin, INPUT);
  pinMode (revFlashPin, OUTPUT);
}

void loop () {

  //..... do other stuff


  // check the magnet sensor on the rotating wheel

  curMagState = digitalRead (magSensorPin);

  if (curMagState != prevMagState) {

    // something has changed

    if (curMagState == magnetIn) {

      // we've just detected the start of a new revolution
      // (call out the troops!)

      // count it and turn on an LED to indicate it

      revCount++;
      digitalWrite (revFlashPin, true);

      // remember this moment

      curRevTime = millis ();

      // and see how long it has been since the last revolution

      long thisRev = curRevTime - prevRevTime;

      // calculate the RPMs from the time of this latest revolution

      // 1 minute = 60 * 1000 ms
      // RPM = ms/min / ms/rev

      magRPM = 60000 / thisRev;

      // and remember the interval for the next time

      prevRevTime = curRevTime;

    }  

    else  

      // the magnet has just left the sensor's range,
      // so turn off the indicator LED

    digitalWrite (revFlashPin, false);
    
  }

  else

    // no change in magnet state, but check
    // to see if pedaling has stopped by comparing the
    // interval since the last revolution against a
    // timeout value

      if ((millis () - prevRevTime) > revTimeout) {

      // wheel has stopped rotating

      magRPM = 0;

    }


  // remember the current state of the magnet for next time

  prevMagState = curMagState;

  //......
  // and go do other stuff

}
Perhaps it could be useful to you.

.andy
55  Forum 2005-2010 (read only) / Syntax & Programs / Re: serial.print or serial.write? on: November 04, 2009, 05:20:36 pm
Lefty, you're good at performance calculations. Any estimates on the Serial.print vs Serial.write runtime overhead? Of academic interest and pure curiosity, at this point...
56  Forum 2005-2010 (read only) / Syntax & Programs / Re: serial.print or serial.write? on: November 04, 2009, 02:03:24 pm
I agree about the readability. Since your data is not text, Serial.write seems to makes more logical sense, while Serial.print implies human-readable data (to me).

I'm not an expert but my understanding is that the extra overhead of Seril.print is probably a few instructions and a function call. Even at high baud rates, I'm guessing that would be just roundoff errors in performance.

But I'm really just speculating and waiting for a more knowledgeable geek to chime in here on this increasingly prolonged (by me) discussion of marginal utility.

 ;D
57  Forum 2005-2010 (read only) / Syntax & Programs / Re: serial.print or serial.write? on: November 04, 2009, 12:27:12 pm
Quote
From the point of (thought of) overhead i'll stick to Serial.write();

I have a hard time believing that, for serial communications at 9600 baud, the overhead of one extra function call could be significant.

It seems to me that the best coding practice would be the one that is the clearest and easiest to read and understand.
58  Forum 2005-2010 (read only) / Syntax & Programs / Re: Arduino Mega - additional Interrupts on: October 28, 2009, 05:41:51 pm
Hmm, this low-level code is beyond my familiarity and interest, at this point.

I would still be asking why you need to use interrupts for the application, and consider if you could stay at the basic app-level coding and just continuously poll all the devices from the main loop.
59  Forum 2005-2010 (read only) / Syntax & Programs / Re: Arduino Mega - additional Interrupts on: October 28, 2009, 09:01:25 am
Often the best strategy to get help in the forum is to post your code (use the "#" button above) so that people can take a look at what you are doing and offer suggestions.
60  Forum 2005-2010 (read only) / Syntax & Programs / Re: Arduino Mega - additional Interrupts on: October 28, 2009, 12:26:56 am
Unless you are doing a very, very small amount of processing inside your ISR, it is probably not a good idea to make extensive use of interrupts. Search around the forums for various conversations about this, but the issue is that they block other actions from continuing.

The typical scheme is to only set a global flag inside the routine and then immediately return to the main loop, where you can be continuously checking your state variables.
Pages: 1 2 3 [4] 5 6 ... 17