> On 25 Feb 2019, at 16:04, Damien Dando <damien.d...@gmail.com> wrote: > > 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 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 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.
Hi Damien, Have a read thru this: http://www.machinekit.io/community/contributing/ > > 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: > read GPIO inputs "globally" (in similar way as it is done for GPIO outputs in > pru_wait.p). This requires to add some code in pru_wait.p and/or > 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). > 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 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 > > 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 >> cha...@steinkuehler.net > > -- > 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. -- 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.
