I was able to easily exceed the max physical hardware step rate for a DRV8825, which is 250kHz, on 9 channels simultaneously, using a BBB/BBG/BBGW. PRU based stepping is pretty darn fast. The maximum it can do would be based on the internal path it takes (crossing PRU boundaries), the rate you choose for things, and how many. But that should give you an idea. I changed basically nothing to do this other than picking my pins carefully. You'll likely never hit the stepping limit before your physical hardware can no longer cope.
On Wednesday, April 17, 2019 at 7:47:17 PM UTC-4, justin White wrote: > > OK, that actually clears up some of my confusion. I didn't realize the > GPIO was that fast, there's generally some latency on GPIO then again I'm > really not up to snuff on the BBB. Any Idea what step rates the BBB will > support on GPIO? Looks like I run around 52kHz accelerations on my current > setup. > > I saw that spreadsheet before but I was a bit confused looking at it, but > it makes more sense now that I know the stepgens aren't really targeting > the PRUs. I'm still a bit sure of how the modes work because it looks like > the "BeBoPr Function" for example is using the analog inputs tor a > thermocouple but analog inputs are only available in mode 0 but GPIO on > header2 is only available in mode 7. I assumed that the modes were set for > the whole header or PRU but now I'm guessing that each pin can be mode set > individually? > > On Monday, April 15, 2019 at 6:37:55 PM UTC-4, Charles Steinkuehler wrote: >> >> On 4/15/2019 5:28 PM, justin White wrote: >> > >> > I started tossing around the idea of making a shield that is compatible >> > with both the BBB and the DE0/DE10 nano. Seems completely feasible >> since >> > the BBB headers physically sit inside of the DExx nano headers. The >> concern >> > becomes 90% about the BBB pinout because there seems to be alot of >> special >> > considerations for the BBB based on what you're willing to give up, >> whereas >> > the nano can just be configured pretty much however necessary. >> > >> > Looking at it I was starting to get a headache trying to figure out >> exactly >> > what the constraints are in regards to the "modes" and the PRUs. From >> all I >> > could dig up it looks like I wouldn't have enough PRU I/O left over to >> > really do anything with. I don't so much care about losing HDMI, but >> I'd >> > actually like to keep the emmc if possible. I'm pretty verse with >> LinuxCNC >> > but the BBB thing and how it all ties into the hal PRU driver is a bit >> > complicated. >> >> You don't really need to use PRU direct I/O for anything but encoder >> inputs (assuming you want to use PRU based encoders). The performance >> difference between using a GPIO pin as an output for step/dir or PWM >> is negligible vs. using the PRU direct outputs. >> >> > Is there any info on the machinekit images for the standard pin >> configs? >> > Ideally I'd like to get 4 step/direction, 1 ABZ encoder, and at least a >> > couple of PRU inputs/and outputs the rest I can just use the slower >> GPIO. >> > I'd like to get ahold of a pin config that is verified to work so I >> know >> > what I'm working with >> >> There are lots of choices. :) I have a number of board pinouts >> listed in spreadsheet form which you may find helpful: >> >> >> https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods >> >> >> -- >> 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.
