Timer traps

[Resilient]

I know there are a whole ton of bugs you can run into when using timers on AVR microcontrollers. Particularly with the 16 bit timers where you can clobber a register when it is only 1/2 read or written to.

Is there a good source of documentation on how one can mess up these timers and then how one can write code to avoid said mess ups?

edit: I meant to put this in software. If a mod feels it is appropriate feel free to move it.

[newInRobotics]

Microcontroller datasheet is a good place to start.

I don't know which uC You are using, but ATmega ones allows writing to the register only when lower 8 bits are read. I'm not sure what You problems are, but if You are new to timers and happen to use ATmega - Newbie's Guide to AVR Timers is an excellent starting point 

Good luck.

[joe61]

I know there are a whole ton of bugs you can run into when using timers on AVR microcontrollers. Particularly with the 16 bit timers where you can clobber a register when it is only 1/2 read or written to.

Which registers are you talking about? If you mean OC1A and OC1B you'd have to go out of your way to make that happen. The datasheet specifies the order for reading, but if you're using C just read the whole thing at once and the compiler will do the reads in the right order for you.

Is there a good source of documentation on how one can mess up these timers and then how one can write code to avoid said mess ups?

I'm still not clear on which mess ups you're talking about. Can you give an example?

Joe

[Resilient]

It has been awhile since I have worked with timers... Too much time writing high level code.

But if I recall, I had some variety of wheel encoder that triggered an interrupt on a rising edge. During this interrupt it would read one of the 16-bit timers. I also had an interrupt that was triggered when the timer overflowed to update a counter in the program for longer time keeping.

I think the types of problems I encountered included:
The temporary register used for writing and reading 16 bit timer values getting clobbered by another interrupt.

An off by one error with the value in the software if the encoder triggered an interrupt in the middle of that value being written.

Keeping in mind I was a much worse programmer back when I was doing these things so it may be obvious to me now how to avoid these problems. I just remember them being very frustrating and hard to debug. Ill just start writing code and post when I run into some current problems.

[joe61]

Yeah, sorry I'm still not clear, but it sounds like that was in the past. You might find it helpful to look at the avr-libc site. They have good information there. Also take a look at the avrfreaks site. The tutorial section of the forums has a lot of good information there too.

And don't forget the data sheet for your processor. There's a section for each timer a chip has in the data sheet which gives information about how to access registers, setup for input capture, etc.

Good luck.

Joe

[Soeren]

Hi,

Yes, it really should go in software.

An off by one error with the value in the software if the encoder triggered an interrupt in the middle of that value being written.

I don't see how that should happen.
When an interrupt arrives, the present instruction is finished, only  then the PC is pushed to the stack and the interrupt is serviced, so no fault as you describe can happen.

Programming in a HLL, you shouldn't need to worry about it at all - this is a job for the compiler.

Keeping in mind I was a much worse programmer back when I was doing these things so it may be obvious to me now how to avoid these problems. I just remember them being very frustrating and hard to debug. Ill just start writing code and post when I run into some current problems.

In Software please

One thing that might go wrong is, if you have several instructions that need to be executed in succession. But then you could disable interrupts while doing this and an eventual missing count from eg. an encoder can be extrapolated from the average frequency of these interrupts.
Another way to deal with such is, to let the interrupt just set a flag and return control to the main program, then do the deeds in the main program at the first available moment.