timer0_overflow_count in 0012

I've been using timer0_overflow_count (microsecond timing) to drive a stepper motor but I gather that on v12 it's no longer available.

What can I do?

Thanks

Marcel

Beardy--

In porting most 0011-era code, you should be able to replace timer0_overflow_count (that's approximately millisecond timing, not microsecond, by the way, on a 16 MHz Arduino) with a call to the system function millis().

Mikal

Thanks for the reply Mikal.

I'm not understanding quite yet.

I acquired the code:

unsigned long hptime, mstime;
extern volatile unsigned long timer0_overflow_count;

unsigned long hpticks (void) //// FUNCTION
{
  return (timer0_overflow_count << 8) + TCNT0;
}

...to deliver microsecond timing so that I could drive stepper motor steps. (using an easyDriver board) I'll be honest and state here that I don't quite understand what it does but I know that it worked.

Does the millis() function now offer that resolution?

Many thanks

Marcel

I don't quite understand what [hpticks()] does but I know that it worked. Does the millis() function now offer that resolution?

My understanding is that it returns a value representing Timer0 ticks which occur at a rate of F_CPU / 64, much faster than milliseconds.

Take a look at this post which proposes a replacement for hpticks() that compiles for 0012. I experimented with it on a 20MHz Arduino-like device but it should compile and function correctly for 8MHz and 16MHz devices as well.

Yikes... pretty hectic stuff!! :wink: But if that works I'm a happy man! :smiley:

Forgive me, a couple of questions...

Where do I put this code? "extern "C"" - does that mean I stick it somewhere other that in my regular code?

All the #s... do I need to fiddle here to specify Diecimila or is that all taken care of automagically?

MANY thanks.

Marcel
This is just another example of the fact that I am (and I suspect a few other folks) standing on the shoulders of giants when I play with Arduino!!

Where do I put this code? "extern "C"" - does that mean I stick it somewhere other that in my regular code?

The simplest way is to replace the hpticks() implementation that you were using with all of the text in my post. All of the "stuff" preceding the implementation of hpticks() is needed for the code inside hpticks() to compile correctly.

An alternate method, perhaps somewhat cleaner, is to add the code that I posted to wiring.c (except that the extern "C" part wouldn't be needed since it is a .c file) and then add the line below to wiring.h somewhere near where millis(), delay() and delayMicroseconds appear. This will allow you to use hpticks() in any sketch with no further ado. The disadvantage of doing it this way is that you'll have to edit those files again when a new build of the Arduino IDE becomes available.

unsigned long hpticks(void);

Here is an excerpt from wiring.h showing how it would look after the line above is added.

unsigned long hpticks(void);
unsigned long millis(void);
void delay(unsigned long);
void delayMicroseconds(unsigned int us);

All the #s... do I need to fiddle here to specify Diecimila or is that all taken care of automagically?

I believe that it should compile correctly for any 8, 16 or 20MHz Arduino-like device (provided it uses the 0012 build) without any changes.

I feel I have split an otherwise perfectly good thread. I posted the sub-millisecond thread after reading this thread. I misread the date of the post and thought it was old (I thought 7-11-2008 was July).

Sorry about that.
/Daryl

Dear Don,

YOU THE MAN!!

All credit to you!!

THANK YOU!! It works a treat! ;D

I just got to work out the other bugs in my code now - but I think it's stuff I can get my head around! (like keeping track of my variables!)

God bless you Don. When my project comes together I'll give you a shout. The basics of it can be seen at Arduino MoCo 1 - YouTube. FYI

[m]

Any idea why the following:

void setup() {
  Serial.begin(9600);
  char ticks[10];
  int i;
  for (i=0;i<100;i++) {
    sprintf(ticks,"%lu",hpticks());
    Serial.println(ticks);
  }
}

Would result in something like this?

Well the slopes all look the same, so the change in tics over time is pretty consistent. Something is taking a variable amount of time in your loop, maybe disable all interrupts except the timer interrupt.

Looks like the value is wrapping only when you start with something over about 255. (See sample 89.) Since it's not every time you go over 255, my money is on an interrupt handler updating your multi-byte value WHILE you are reading it.

That's not the result I get when I run the program:

22
562
1862
3422
4982
6542
8102
9662
11222
13042
14862
16682
18502
20322
22142
23962
25782
27602
29422
31242
33062
34882
36702
38522
40342
42162
43982
45802
47622
49442
51262
53082
54902
56722
58542
60362
62182
64003
65822
67642
69462
71282
73102
74922
76742
78562
80382
82202
84022
85842
87662
89482
91302
93122
94942
96762
98582
100402
102482
104562
106642
108722
110802
112882
114962
117042
119122
121202
123282
125362
127442
129522
131602
133682
135762
137842
139922
142002
144082
146162
148242
150322
152402
154482
156562
158642
160722
162802
164882
166962
169042
171122
173202
175282
177362
179442
181522
183602
185682
187762

Why do you need to sprintf() the value before printing it?

Mikal