This sounds like a job for an FPGA. 1MHz loops are hard to do in software. Even with custom PRU code, if it worked yours have job for life maintaining it as new versions of the CNC software, OS and toolchain come out over the coming years and decades.
Mesa cards are not that expensive and other FPGA cards can be 1/2 their price. So, just move the 1MHz loop into hardware. One problem with software is that when you look at results at the sub-microsecond level differences is the dynamic code path lengths matter. For example does it ALWAYS requires 15 clock cycles to turn on a bit? No, likely there is an "if" statement some place where one branch is longer. At low speeds this is a 0.01% effect at higher speeds this might be a 10% effect. You don't know the magnitude of the problem until after you write the code and see if you were able to make every execution path the same length. Likely not so you have jitter at the XX% level. This is where FPGAs work best because you can clock the output pluses relative to a divided down crystal oscillator On Mon, Jun 12, 2017 at 7:03 AM, Charles Steinkuehler < [email protected]> wrote: > On 6/10/2017 1:06 PM, Sag ich Dir nich wrote: > > Hello, > > > > if i want to drive 5 axis with each 1 MHZ steprate, do i need to reach 5 > MHZ > > Stepgen or 1 MHZ? > > You need to a 2 MHz base thread (or 500 nS PRU period) which will give > you a 1 MHz maximum step rate (1 thread period high, one thread period > low). > > This is very easy to do if you're using hardware, but not so easy in > software. I doubt an x86 can run interrupts anywhere close to that > fast, and an ARM certainly can't. > > The PRU on a BBB can probably be coerced into running this fast, but > you'll need to optimize the code. The existing hal_pru_generic was > written for flexibility more than absolute speed, and probably won't > go faster than several hundred KHz step rates with 5 stepgens. To get > into MHz step rates, you'll probably need to hard-code the PRU logic > (instead of building a chain of "tasklets" as is done now) and keep > all of the state information in registers. It should be fairly simple > to do, but you still might not quite make it to a 1 MHz step rate (the > 500 uS task period only gives you 100 instructions to do step/dir > generation for 5 channels, or 20 instructions per channel. The > step/dir code isn't super complex, but is more than 20 instructions > through the worst-case path, and some of the instructions take more > than 1 clock (5 nS). Getting rid of the memory accesses (required for > the current "tasklet" structure) and putting everything in registers > ought to get you close to the required speed. > > -- > Charles Steinkuehler > [email protected] > > -- > website: http://www.machinekit.io blog: http://blog.machinekit.io github: > https://github.com/machinekit > --- > You received this message because you are subscribed to the Google Groups > "Machinekit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/machinekit. > For more options, visit https://groups.google.com/d/optout. > -- Chris Albertson Redondo Beach, California -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
