Ok, thanks Charles! I got all development tool working now, I had to (re)compile the all machinekit directly on the BBB in the end but it is working now.
You may also want to look at the timer/capture modules, both in the > ARM system (with Linux drivers) and there's one module within the PRU > domain. You can use these to time pulses and you will get several > orders of magnitude better accuracy (~10 nS) vs. trying to monitor the > signal with PRU software (~1-10 uS), but that may or may not be > important depending on the PWM frequency range. This is to get feedback from those ClearPath motors <https://www.teknic.com/products/clearpath-brushless-dc-servo-motors/> (made by Teknic). The PWM frequency of the signal is 50Hz so measuring ~10us is already overkill ;) Because of to restrictive pinout for dedicated PRU input, I'm also using regular GPIO inputs which have a "slow" read time of ~170ns. Since I saw quite few videos of people using those ClearPath motors on their CNC, I'm sure many would also benefit from this PWM feature I'm implementing. I also want to contribute to Machinekit so I'm wondering how is the process/requirements for new features / pull requests to be included in futures Machinekit official releases? There are different implementation approaches I thought of. To integrate it at best in the current hal_pru_generic driver that would be great to have some feedback. @Charles, as you seem to have worked quite a bit on the PRU code, your feedback would be valuable&appreciated :) Since I'm reading out GPIO inputs state this adds ~170ns per GPIO port 1-3 (and ~190ns for GPIO port 0). For that reason it would be smart to read GPIO port(s) used by my PWM reader module only once per PRU cycle in a similar way as it is done in pru_wait.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p#L204> when writing to GPIO outputs. This could be achieved in 2ways: 1. read inputs globally (in a similar way as it is currently done for outputs) by adding some code in pru_generic.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p> and/or pru_wait.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p>. This leaves the possibility to use GPIO inputs read value in future potential new features/modules without adding a 170ns "long" read cycle(s) in every new module using GPIO inputs. 2. read input "locally" in the task scope without changing pru_generic.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p> and/or pru_wait.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p> . What do you think? In my opinion, the first solution is better from architecture/structure point of view since it leaves the possibility for any "hal pru module/driver" to use the GPIO inputs (the encoder could then possibly be modified to work with regular GPIO inputs). Looking further, I see that there are not much free space for registers to use globally. However I thought about this trick using GPIOn_Clr and GPIOn_Set to read GPIO inputs (the idea is to save us from the 170ns read time(s) if we don't use any GPIO inputs): - any module that want to read a GPIO pin set the corresponding bit to 1 in both GPIOn_Clr and GPIOn_Set (I believe this case would never happen when the GPIO is used as output by other hal pru module such as stepgen, pwm, ...). - somewhere around pru_wait.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p#L204>, if logical AND of GPIOn_Clr + GPIOn_Set is non null, it means we have a GPIO read request on the GPIO port n so we do the "slow" read (34pru cycles / ~170ns) and store the result in GPIOn_Set. To prevent potential conflict with other modules we only set GPIOn_Set bits of the initial read request. I believe I can manage to do that in ~4-6pru instruction per GPIO port with possibly some extra branching to completely skip this code if there is no GPIO input used on any port. What do you think about this idea? /Damien Le dimanche 17 février 2019 16:07:02 UTC+1, Charles Steinkuehler a écrit : > > On 2/17/2019 8:31 AM, Damien Dando wrote: > > Hi, > > > > Background: > > I'm building a CNC Lathe (see video here <https://youtu.be/bn6DsqG35MU>), > I > > use ClearPath motors to control Z&X axis and the spindle. Those motors > can > > be configured to give torque feedback by outputting a PWM signal. I want > to > > be able to read the torque info within Machinekit in real time so I > could > > display it but also take actions like trigger emergency stop if the > torque > > goes above certain threshold. > > > > I have started digging in the machinekit PRU code to develop some module > to > > read a PWM signal. > > I'm not stuck and I'm confident I will eventually manage to do all what > I > > want but if some have already work with the PRU they might have some > answer > > to those question that would save me quite some time: > > > > - Is there some (simple) way to test the PRU binary (pru_generic.bin) > > separately before&without doing the integration in Machinekit? (like > some > > script that configure the PRU/RAM shared memory the same way as > > the hal_pru_generic driver does?) > > Just start a HAL instance and manually (or use a small HAL file or > script) load the hal_pru_generic driver with "disabled=1". This will > load the driver and create all the HAL pins, but the PRU will be left > in the reset state. Make sure you also specify the correct path to > your (modified) PRU binary file (prucode=<path>): > > www.machinekit.io/docs/man/man9/hal_pru_generic/ > > Then you can use your favorite PRU debugging tool. The only one I've > used is the HAL based "debugger" Michael Haberler whipped up in > python. It will single-step and allow start/stop of the PRU, but > there's no support for breakpoints. It's been enough for my needs, > since the PRU code isn't that complex: > > > https://github.com/machinekit/machinekit/tree/master/configs/ARM/PRU-Debugger > > ...but I think there are now some others available. > > > - Is there some (simple) way to build&test the hal_pru_generic driver > > only without (re)compiling the all machinekit? > > Just tell make which file(s) you want (re)built. You may also find it > helpful to review the Submakefile in the hal_pru_generic source tree: > > > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/Submakefile > > > You may also want to look at the timer/capture modules, both in the > ARM system (with Linux drivers) and there's one module within the PRU > domain. You can use these to time pulses and you will get several > orders of magnitude better accuracy (~10 nS) vs. trying to monitor the > signal with PRU software (~1-10 uS), but that may or may not be > important depending on the PWM frequency range. > > -- > Charles Steinkuehler > [email protected] <javascript:> > -- 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.
