Re: Pulse Gen

dave engvall wrote:

>
> I might rephrase that: profile the system in software and find out what take the most time. Recode that 10% or so that is taking
> 90% of the time and then if that isn't fast enough do it in hardware.

In this case, profiling it for time spent in a particular section of code
may not really spot the problem. In this case, the resolution of the
pulse timing is what is critical, not necessarily the amount of CPU
resources it takes to do that part. I can easily see an interrupt-driven,
"pulse or no pulse this tick" type of routine that would NOT take much
CPU resources, but would give very poor step pulse timing.

Jon