> We need a smaller delay procedure (100ns). I'm sure we can come up > with a better procedure then we have both posted.
I agree on a "smallest possible delay", but it should not be named delay_100ns(). When running at 32kHz, the smallest possible delay is longer than 30us, which is not even in the same magnitude as 100ns. How about delay_1tcy() ? For clocks 4MHz and below, doesn't _usec_delay(1) serve the purpose already? Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
