Chris Albertson 12:28 PM (0 minutes ago) to Damien In general, the way I'd read a PWM input signal is to measure the length of the high and the length of the low parts independently. Almost all small CPUs now days have external hardware that you can program to measure pulses then in software you can read the pulse lengths after each pulse. You need two timer channels, one to read the low and one to read the high. After every two pulses (one high, one low) you have a fraction and then can convert to floating point or whatever you need. Typically you get to choose the counter rate and so get any resolution you need. Set it as fast as you can but not so fast that a 90% duty cycle would overflow the 16-bit counter.
The details of how to do this depend on the exact chip so few people bother stuffing registers and instead use the manufacture's PWM library function. 30 years ago processors just had simple digital pins and everything had to be done in software. Today even the $1 uP chips have just tons of peripheral hardware, so you can do things like read A/B quadrature or generate PWM with on-chip hardware. My experience is mostly with STM32 but TI works as well and TI has a software development kit. Anyone using TI chips needs to know TI's SDK. then just use their PWM input function. On Tue, Feb 26, 2019 at 11:33 AM Damien Dando <[email protected]> wrote: > In response to > https://groups.google.com/forum/#!topic/machinekit/5TIA7b-7Q1k > Note: I'm trying to create a new post to answer because for some unknown > reason google keep deleting my answer right after I post it in the original > thread. I also tried to leave Machinekit group to re-join hoping it would > reset something but no luck.. fuck google! If anyone known how to solve > that let me know. > > 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 > > -- > 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. > -- Chris Albertson Redondo Beach, California -- 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.
