Show Posts
Pages: [1]
1  Forum 2005-2010 (read only) / Syntax & Programs / Re: Reset Clock on: September 25, 2010, 02:21:50 am
Quote
You want a snippet of code, that causes an undesirable side-effect, to overcome a serious problem introduced by your unnecessary attempt to reset the millis counter.  The answer is no.
I'm not sure why you're being argumentative about this; it's nothing personal. You said there were two additional steps, so I'm curious to know what they are.  Otherwise, I'm not sure what undesirable side-effects you're talking about.

The solution to my problem is not at the reference you cited. It states:
Quote
Now, the only potential problem is that if you wait approximatly 49 days, you will get into the range where it again waits for the timer....
Which is exactly what I need to avoid.  So far, my device has been running for 90+ days without the problems it was having at around 49 before this fix. I posted this because it was helpful to me, and may be to others as well.

Just because this dude said:
Quote
There is NO problem with overflow if you use unsigned long for the variables
Does not mean it's true.  Using the unsigned long type may eliminate the problem for some, but only lessens it for others.
2  Forum 2005-2010 (read only) / Syntax & Programs / Re: Reset Clock on: September 24, 2010, 10:59:26 am
What are the two other steps?  I haven't had any problems with this code so far?

3  Forum 2005-2010 (read only) / Syntax & Programs / Re: Reset Clock on: September 21, 2010, 09:25:52 pm
I'm sure this has been addressed elsewhere, but since this came up first when I googled the topic, I thought it might be helpful to post this solution here. It is absolutely possible to reset the millis() counter, and is absolutely desirable to do so in many situations.

If you're timing out a short event and aren't keeping track of timing elsewhere in your program, resetting the counter before you start your timer helps to avoid any possible overflows. I've seen some people post that 9 hours (or whatever it actually is) is way longer than what they need to time. But what if your 3 second event happens to start right before millis() overflows?  Unlikely? Yes. Possible? Extremely. Resetting the timer beforehand gives you 100% assurance that it won't.  

So, long answer short (no pun intended), you reset millis() by directly setting the variable that millis() uses to keep track of clock cycles to zero.

Make sure the variable is in the scope of your code by declaring it sometime after wiring.c is included and before loop():

Code:
extern volatile unsigned long timer0_overflow_count;

Then, whenever you need to reset the timer back to zero, just set:

Code:
timer0_overflow_count = 0;

...and then use millis() as you normally would (i.e.the offset examples above).
4  Forum 2005-2010 (read only) / Troubleshooting / Re: Random failure to upload code. on: September 25, 2010, 03:01:39 am
A lot of questions here.

Quote
do you know if I can make it send the debug output to a file?

If you run avrdude on the command line, this is simple, just pipe the output from avrdude into a file:
Code:
avrdude [your usual flags, files, etc] > output_file.txt

Quote
I can't figure out where avrdude 5.04 is installed

I have Windows Vista.  My current Arduino "root" is "C:\Arduino\arduino-0019".  AVRDUDE is under that directory in "C:\Arduino\arduino-0019\hardware\tools\avr\bin"
Arduino's root directory on linux usually installs into:
PATH/share/arduino-0019

On ubuntu, you'd probably find it in:
/usr/share/arduino-0019/hardware/tools/


Quote
I'm an ubuntu user after all Wink It's been a few years since I really had to use the command line
This seems backwards to me.

Quote
HAve u a linux OS?
Yes

5  Forum 2005-2010 (read only) / Interfacing / Re: Complicated project, need help. on: July 04, 2010, 10:44:35 am
You haven't been a pilot lately, have you? VOR isn't going away any time soon.  I agree, GPS is much better in many ways, but VOR technology is simply "good enough" in most cases.  Good enough to guide a plane to an airport with zero visibility down to 1000ft AGL in some cases.  The technology is implemented in almost every general aviation aircraft around, and most are not willing to upgrade to gps because of the lack of real benefit to GENERAL aviation pilots, and the high cost.  Technology in aviation outside of commercial planes moves very slowly, and it's always the same story: too expensive, and too difficult to bring into compliance with FAA standards.  The general attitude in aviation seems to be "if it's not broke, don't fix it".  Similarly, you'd be surprised what kind of engines most small aircraft are powered by.  I've seen lawn mowers with more advanced technology (literally).  Take a look at any aeronautical map, and you'll see how firmly VOR has its foot planted in our country. And as an aside, once GPS does finally take over (we may never live to see the day), the VOR legacy will live on.  Most of the airways in place now are based on and named after VORs.  GPS systems as they operate currently basically act as VOR emulators. Enough of my ranting; carry on.
Pages: [1]