Hi,
I'm working on a library which manipulates a timer.
I want the library to be independent of the Processor-speed
and use the function clockCyclesPerMicrosecod() from wiring.h to adapt to different boards.
Question :
Can I use this function safely or is there a risk that someday it will be dropped as its not an official part of the arduino language?
Hi Eberhard, clockCyclesPerMicrosecond is a macro and my (unofficial) view is that it is safe to assume it will always be there (it makes no sense to remove it or change its definition). But if you want to be absolutely sure, you could add the following to your header file
// this defines clockCyclesPerMicrosecond if its not already defined #ifndef clockCyclesPerMicrosecond() #define clockCyclesPerMicrosecond() ( F_CPU / 1000000L ) #endif
There is currently no official support for microseconds based timestamps however, so don't be suprised if it doesn't work in the next version. I am trying to get more official microseconds support considered at the moment.
Hi dcb, I don't think Eberhard is asking for official support for timestamps. He wants something that will return the number of clock cycles per microsecond and unless you see something I have missed, the above should meet his needs.
It's not official, we don't have anything official in the microseconds scale aside from delayMicroseconds. Having chased microseconds for a few versions now, I would like to see something more official, not people saying "this is good enough for you".
You have to make some assumptions about F_CPU. And worth noting that the macro, despite its name, cannot officially be used to convert clock cycles to microseconds or vice versa as we have not arrived on an "official" microseconds method or clock cycles tracking method.
You can base it off another timer, but again no guarantees that timer interrupt won't get assimilated by the core. And you have essentially lost a timer at that point too.
Hi,
all I want to do is to select the prescaler for a timer to have it overflow after a fixed number of clockcycles (which should match more or less a fixed numbner of µs). Since I use more than one interrupt source I'm aware that there will be a deviation. But for my application (remote control receiver) it dosen't really matter anyway. People will push the same button again if they get the impression nothing is happening...
You have to make some assumptions about F_CPU...
after running
grep -R "F_CPU" arduino-0012/*
I'm quite convinced that we will have moved to a new hardware-hype before anybody will decide to change anything about the semantic meaning of F_CPU
Eberhard
The macro does assume that F_CPU will continue to be defined as the frequency of the CPU in cycles per second, and although anything could in theory change, I would be surprised if you are saying that you don't think that is a safe and reasonable assumption.
?the macro cannot officially be used to convert clock cycles to microseconds or vice versa as we have not arrived on an "official" microseconds method or clock cycles tracking method.
That was not the OP's requirement
edit: composed before but posted after Eberhard's replay above. I was also having a poke around to verify how pervasive the F_CPU definition was.
Now are you sure wiring.h will always be included before your definition?
And how sure are you that your timer interrupt won't be overwritten in a new version? Mem, I know you would not be happy if timer1 were confiscated, but it gets discussed occasionally. I wound up on timer2 myself for all my timing needs (and using timer1 for pwm), timer0 is currently disabled.
Now are you sure wiring.h will always be included before your definition?
Although I would expect any library intended for the arduino environment would directly or indirectly include wiring.h, in the case being discussed here it doesn't matter. The Eberhard's code would work as long as F_CPU is defined. The value used to define this comes from the board preferences file. ( see http://www.arduino.cc/en/Hacking/BuildProcess)