Jon Elson wrote: > Sebastian Kuzminsky wrote: >> If I disable the steppers on the 7i43 (with config="num_steppers=0") and >> run it with 4 servo channels (and 24 accessible GPIOs), I get these figures: >> >> read time=191, tmax=203 >> write time=190, tmax=239 >> >> That's about 1 KHz. >> > Very interesting! I wonder if you can improve this by > streamlining the driver. I can do 4 axes on my USC or UPC board > at about 100 us, on a 600 MHz Pentium II through the motherboard > parallel port. A safe 5 KHz.
Yeah something's not right there, 190 us is way too long. Hm, these numbers come from 'halcmd show param hm2_7i43.*.time', which I thought was in nanoseconds, but looking at hal_lib.c I see that it's in CPU clock cycles. Is that intentional? In hal_lib.c's thread_task(), it calls rtapi_get_clocks() instead of rtapi_get_time(). <http://cvs.linuxcnc.org/cvs/emc2/src/hal/hal_lib.c?rev=1.59> Mine's a 2.6 GHz CPU, so 190 cycles is about 74 microseconds. With the 50% margin we've been working with that's 3 KHz, which is a little better. Each EPP cycle takes right around 1 us on my test system. read() does this: 2 write-address cycles (address gpio data register) 8 read-data cycles (read two 4-byte gpio registers, 24 pins on each) 2 write-address cycles (address encoder count register) 16 read-data cycles (read four 4-byte encoder count registers) That's 28 EPP cycles total, so even counting time correctly it should be *much* faster than 75 us... Oh, hm, I had two threads running, both doing EPP I/O (with the spinlock & cli functions Paul suggested). If I move all the I/O into one thread it's much faster. Strange. Oh I think I see, if a function in a slow thread is preempted by a faster (higher-priority) thread, then the time that the lower-priority function spends blocked still counts. Oh yeah, and I was doing some I/O to the 5i20 at the same time, that'll worsen the preemption perturbation some. Ok, nice to have all that out of the way. Now here are some new numbers for just the 7i43, with all I/O from one thread (so there should be little or no time spent blocking on faster threads), and the numbers are actually reported in microseconds now instead of cycles. 7i43: pet_watchdog(): 21 us read() 4 encoder counts & 48 gpios (only 24 usable): 43 us write() 4 pwmgen duty-cycles & 48 gpios (only 24 usable): 40 us So that's 4-channel servo control at 4.8 KHz, with 50% of the CPU time left over for pid in emc2, GUIs, etc. Drop the watchdog (not that you should) and it goes up to 6 KHz. For GPIO only: pet_watchdog(): 21 us read_gpio (48 gpios): 15 us write_gpio (48 gpios): 15 us So that's just under 10 KHz, or 16+ KHz if you dont need the watchdog. Whew, that's a bit better.... -- Sebastian Kuzminsky Cryogenic travel has improved since then... I woke screaming in a translucent box. “There, there,” said the box. “Everything will be all right. Have some coffee.” -- Ken Macleod, "Who's afraid of Wolf 359" <http://outofthiseos.typepad.com/blog/files/KenMacleodWhosAfraidofWolf359.htm> ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
