next topic »

[on:]

Hi,

I recently finished a library that uses one of the internal timers. Since I want to make my code as portable as possible, I started thinking about how my library could be used with other ones that used the internal timers. Obviously, some libraries use Timer1 and some use Timer2, but if a user wanted to use two that used the same timer, they would be stuck. However, since it is laughably easy to make a series of #ifdefs that can select between each timer, I thought it would be great if every library that used a Timer, and perhaps other resources, to just include a #define TIMER1 at the top. Then, library writers could do things like:

Code:

#if not defined TIMER1 && defined TCCR1A
#define TIMER1
ISR(TIMER1_OVF_vect)
#elif not defined TIMER2 && defined TCCR2A
#define TIMER2
ISR(TIMER2_OVF_vect)
#else
#error No timer available
#endif
{
//do isr
}

Of course, if this is to happen, there has to be a standardized define to "use up" each timer. Is there already something like this in place? Is this a good idea?

[Reply #1 on:]

I'd rather see a system where a lib can request a certain function to be callbacked every x milliseconds. That way all libs can use the same timer(s). The only problem with this is that it causes quite some overhead so it wouldn't work for very fast timer interrupts.

[Reply #2 on:]

The TimerOne library does a nice job of that, and doesn't have much overhead. The main problem with that is the lack of Arduino support for including one library in another.

[Reply #3 on:]

It doesn't need 2 libs to interface with eachother. That would be bad design. You could have a function in your lib called something like void update() or void tick(). Then you specify in your documentation that that function needs to be called atleast every x (milli)seconds. That way you allow people to easily integrate it in their code whatever it may be. And even makes your lib easily usable outside of the arduino software.

I haven't looked at the timer lib you speak about really. Does it use a timer interrupt or does it attach itself to the main loop? Because using an interrupt for anything more then a few assembly calls is generally a bad idea. If the interrupt happens faster then the cpu can execute the code inside, your stack will overflow. "Not much overhead" is relative here. So it would be a be a good idea for that to be inside of the main loop, where it just checks how much time has passed and based on that calls the appropriate callbacks. Those can still be interrupted though so they wont qualify as realtime.

I don't use the arduino ui. Just it's hardware and some of it's libs, but i'm pretty sure it should be possible.

[Reply #4 on:]

It doesn't need 2 libs to interface with eachother. That would be bad design.

How is that bad design? Is it bad design to not start from scratch every time someone builds a new brand of car? Of course not, building on other things is essential to progress.

You could have a function in your lib called something like void update() or void tick(). Then you specify in your documentation that that function needs to be called atleast every x (milli)seconds. That way you allow people to easily integrate it in their code whatever it may be. And even makes your lib easily usable outside of the arduino software.

That would make it extremely difficult to use the library.

I haven't looked at the timer lib you speak about really. Does it use a timer interrupt or does it attach itself to the main loop?

Interrupt.

Anyway, I don't think the solution to this problem is to have what is essentially an operating system that keeps us from messing with any of the hardware. It would be nice, and simple, to just have a standardized way to have librarys work together.