Please keep replies on-list. On 3/3/2017 11:46 AM, Chris Albertson wrote: >> When loaded, the driver takes the command line arguments and builds a >> task list in PRU memory to implement the desired function(s). This >> list also contains any parameters and local storage required for each >> "tasklet". The PRU runs through the linked list of tasks then waits >> for a timer tick to start all over again. The code should be >> reasonably easy to follow, but ask if you have any questions. > > This sounds like a good general purpose method for running a set of > hard-realtime tasks that could be generalized to any uP that is > connected to a larger processor that runs Linux. Of course the > advantage of a PRU is the integration with the Ti ARM chip that you > already have it at zero cost.
Yes, a "main loop" is a very common strategy with micro-controllers when you don't need a full OS or the complexity of multiple threads. The configurable task-list and jump table is perhaps a bit novel, but not particularly unique or original. > Are there any plans to generalize this? If I were doing it I'd use > an ARM Cortex M of some type and maybe SPI. The Cortex M is lots > cheaper then a Mesa FPGA card I don't particularly have plans to generalize the code. Most of the code is really either tweaked for the operating environment (see the PRU step/direction generator for example) or relates to communicating between the PRU and ARM (and would totally change if you didn't have shared memory available), so I'm not sure how particularly useful the code would be on an SPI connected Cortex M. ...and yes, a Cortex M is less expensive than a Mesa card, but you can get some of the low-end parallel/SPI Mesa cards for $60-70, and they are *WAY* more powerful than anything you can do on a Cortex-M unless there's lots of specialized hardware already (like encoder inputs and PWM outputs). > One question? What is the loop period in the PRU? I suppose one > might be able to adjust it based on the number of tasks that are > linked? But what's typical? I'm just curious about PRU > performance. The loop period is programmable at load time. It defaults to 10 uS, but that is very conservative. I typically run with a 2-3 uS period (still very safe with my typical 3D printer mix of stepgen & pwm), which allows step rates up to a few hundred KHz. If you need to, there's a way to see the CPU load on the PRU via one of the direct output pins (see the hal_pru_generic man page for details), so you can make sure you don't set the cycle value too low. -- 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.
