Le lundi 25 février 2019 17:46:06 UTC+1, Charles Steinkuehler a écrit : > > On 2/25/2019 9:17 AM, Damien Dando wrote: > > Hi Charles, thanks! > > > > Note: I tried to post this answer in the public google group but for > some > > unknown reason google keep deleting my answer right after I post. I also > > tried to leave Machinekit group to re-join hoping it would reset > something > > but no luck.. fuck google! If you happen to known how to solve that let > me > > know. > > > > 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. > > Just fork the repo on Github, make your changes, and submit a PR. > Ok
> 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. > > There are quite a few unused registers. See the scratch/reserved > registers (used to talk to the hardware multiplier): > > > https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L81-L85 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmachinekit%2Fblob%2Fmaster%2Fsrc%2Fhal%2Fdrivers%2Fhal_pru_generic%2Fpru_generic.p%23L81-L85&sa=D&sntz=1&usg=AFQjCNGtE7qNE5nZEm2ZmCXPIOs4GE6JFg> > > I was actually wondering if those were used as they are marked as reserved for multiplier... is there any code using those? You could also use the per-task registers (R4-11) and a chunk of the > scratchpad registers. > > > 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? > > Personally I don't really want to see hal_pru_generic code reading > from the fabric, it eats up too much time. I'd rather see "slow" code > like this running on the other PRU, leaving the hal_pru_generic code > as-is. > > That said, you're free to do what you want. If I was going to write > something like this, I'd probably create a "GPIO read" tasklet that > reads the input pins from the gpio bank(s) and stashes the data either > in the register bank or in one of the scratchpad banks. Then you can > have other tasklets that process GPIO input pin data as needed. > That last suggestion seems like a good idea to me. I will look in that direction. Was it the intended purpose of the pru_read.p <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_read.p#L4-L6> file? ...but really I think you'd be best off just using a PRU direct input > pin. IIRC you said you're using a CRAMPS board. If so, several of > the SPI signals function as direct PRU inputs and are already tied to > a connector via a FET bus level translator so they are bidirectional > and 5V tolerant: > > P9.28 SPI_CS0 > P9.29 MISO > P9.30 MOSI > P9.31 SCK > > P503 on the CRAMPS board. > I'm not using a CRAMPS board, this does not fit my need. I made my own board (with opto-isolated "satellite" boards): https://youtu.be/bn6DsqG35MU?t=58 PRU direct inputs are indeed easy to use from software point of view. However from a practical point of view, in a real scale project it's another story.. In my case, with all hardware I have connected to the BBB, I don't have so much choice regarding the pinout/connections (which I have already been thinking&reflecting quite a lot when doing the electronic design). 35 IOs seems quite a lot at first but in my project they are already all used, and many have specific need that cannot be exchanged with others (encoders, UARTs, SPI). I could possibly free up 2IOs at max (by grouping some enable signals) but that's all. And most of those PRU input are shared with the hardware encoder which I'm using, and same thing for the SPI0 pins :/ Performance wise, there is no gain of using PRU inputs (in my case) since I read a few millisecond signal. I use a PRU period of 5000ns of which at the moment 4000ns are spent in the wait loop so that's only ~1000ns of active time to run the all PRU period... thanks to your well optimized code :) ! If I ever had need to go down to ~1000ns PRU period, I would be more concerned about hardware limitations than the software ones :) /Damien -- 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.
