Thanks Charles! In the end I did recompile the all Machinekit on BBB, took a while but it eventually worked and I got the dev. env. 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. 10uS is already overkill for my needs ;) I'm reading feedback signal from ClearPath motors <https://www.google.com/url?q=https%3A%2F%2Fwww.teknic.com%2Fproducts%2Fclearpath-brushless-dc-servo-motors%2F&sa=D&sntz=1&usg=AFQjCNEvOk7R_8YKWL7kTygoqgTooMdbWA> and the PWM frequency is only 50Hz. Also I'm using regular GPIO inputs because there is too much constraint with dedicated PRU inputs pinout. Since I saw quite few video with people using those same ClearPath motors <https://www.teknic.com/products/clearpath-brushless-dc-servo-motors/> on their CNC, I'm sure many would benefit from having this feature in Machinekit. Also I would be happy to contribute to Machinekit project so I was wondering what are requirements/process to add a feature/push request to Machinekit official source code. In order to integrate it at best into Machinekit source code, that would be great to have feedback on some question: @Charles: As it seem you have done a lot of work in the hal_pru_generic driver, your feedback would be valuable&appreciated :) Since I'm not using dedicated PRU inputs, reading a regular GPIO input pin takes ~170ns (~190ns for GPIO bank 0). For this reason, I aim to read GPIO bank(s) not more that once per pru period and only if needed. I see 2ways of doing that: 1. read GPIO inputs "globally" (in similar way as it is done for GPIO outputs in pru_wait.p <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmachinekit%2Fblob%2Fmaster%2Fsrc%2Fhal%2Fdrivers%2Fhal_pru_generic%2Fpru_wait.p%23L204&sa=D&sntz=1&usg=AFQjCNGBlHA8xVFFCtUPIZQH1MTHfStebA>). This requires to add some code in pru_wait.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p> and/or pru_generic.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p> and therefore extends a bit the overall pru period. The major advantage is that it would allow any others hal pru "modules" to use any GPIO inputs (the hal pru encoder could then be updated to work also with regular GPIO inputs). 2. read GPIO inputs "locally" in the PWM reader pru task I'm implementing. The drawback we will need to re-read GPIO input bank in every hal pru "module" that use them and therefore wasting PRU period time. I see the first solution as the best one. Looking further, I saw that there is no much unused/free space in PRU register (r0-32), there are pretty much all used for something. However, I thought about this solution (using GPIOn_Clr and GPIOn_Set): - every time a PRU module/task want to read a GPIO pin, it set the corresponding bit both GPIOn_Clr and GPIOn_Set registers. (I believe pru module/task using GPIO as output never set both GPIOn_Clr and GPIOn_Set for the same pin at the same time since that would be a non sense). - somewhere around pru_wait.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p#L204> check if the result of logical AND (GPIOn_Clr + GPIOn_Set) differs from 0. If it is then, perform a "long" (~170ns) reading on GPIOn and store the result in GPIOn_Set. To avoid conflict with other GPIO outputs, only store bits/pins where a read was requested. Then the PRU module/task that requested the reading can read the pin state in GPIOn_Set on the next pru period. or maybe there is some easier solution allocating/using PRU RAM instead of direct PRU register r0-32 (GPIOn_Clr / GPIOn_Set)... What are you thought? Do you have any better implementation idea/suggestion? /Damien PS: I'm using another account to post because of some unknown reason when I answer with my original google account my response got deleted right after I post it ( I tried 5times). I also tried to leave Machinekit group to re-join hoping it would reset something but now it seems I have no option to join&post again. fuck google! If anyone known how to solve that let me know. On Sunday, February 17, 2019 at 4:07:02 PM UTC+1, Charles Steinkuehler wrote: > > 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 > cha...@steinkuehler.net <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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
