Peter C. Wallace wrote: > I think a good way to do this is simply a set of architecture specific > wrappers around the lowest level I/O, and perhaps initialization code so the > driver itself is not forked. > While in theory this could be done, it won't take advantage of the fact the PRU is a computer. The ppmc driver has a "cache" that reads all the registers that need to be read in one block right after the servo thread is invoked, and accumulates all registers that need to be written to the device, and writes them all at the end of the thread. It makes the most sense to move the whole "cache" logic out to the PRU, and having the data just be at a particular location in the PRU's data memory, available to the ARM. My idea is the driver will create a "work list" of registers to be written and where to put the results, and registers to be written and where the values come from. This would be created once, and the PRU would follow the list to perform the above actions.
Also, I'd like to have the ppmc device set the timing of the servo thread, use an interrupt to trigger the PRU program to perform its work, and then signal the ARM to perform the PID, etc. part of the servo thread. This will reduce jitter to sub-nanosecond levels, as the ppmc hardware will sample all encoder positions, etc. on the ppmc's timer. (rtapi was not set up to use this feature, but now that we are striding off in a new direction, I'd like to see if we can do it.) Jon ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
