Go Down

Topic: delayclockcycle() (Read 749 times) previous topic - next topic


It would be a nice addition it there would be a delay smaller than delaymicroseconds() that deals directly with clock cycles.
Anybody else thinks so?


Personally I wouldn't use clock cycles for timing since a clock rate can be changed, except for very small intervals for which rounding is an issue, and then I'm going to need to integrate it with operations around it.

You can't get in and out of a function in much under a microsecond, so if you are looking for better resolution it will need to be inline. For very short delays you can...
Code: [Select]

__asm__( "nop\n\t"

... for as many nops as you need at one cycle per nop. That could be a significant code size burden for longer delays. If you have a register to spare there are probably two cycle instructions that will make better code density. At some point it is better to loop and count.

If you are needing this sort of resolution, then you will also want to use objdump to disassemble your code and see what the compiler did. It has some amusing reordering rules that can put initialization computations inside your time critical areas.


Thank you Jims!
That is exactly what I was looking for.
Really helpful for precise timing protocols.


Apr 09, 2007, 01:37 am Last Edit: Apr 09, 2007, 01:38 am by HL-SMG Reason: 1
How would other ASM code be included? Could I write a byte to a port in one clock, then NOP for a while, and then loop, all in ASM?

I want to make very precise timing (I will be generating between 30 and 60 khz plus 60-120hz) for VGA, and if I have some spare uC time, I'd muck around with other stuff. I just want this stuff to be über efficient.

(I dont have freq counter so I have to use sillyscope)


Yes, you can do such things when time is critical (turn off the interrupts while you are at it). Check the GCC Inline Assembler HOWTO. http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html and the Atmel AVR-8 instruction set.

Go Up