Forum 2005-2010 (read only)
Bugs & Suggestions
(Read 749 times)
Apr 04, 2007, 05:29 pm
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?
Apr 04, 2007, 10:00 pm
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...
... 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.
Apr 06, 2007, 08:16 pm
Thank you Jims!
That is exactly what I was looking for.
Really helpful for precise timing protocols.
Apr 09, 2007, 01:37 am
: Apr 09, 2007, 01:38 am by HL-SMG
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)
Apr 09, 2007, 02:16 am
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.
and the Atmel AVR-8 instruction set.