Hi James, Thank you for the patch and adding this functionality.
On 21/8/20 8:01 pm, James Fitzsimons wrote: > This patch adds driver support for the eQEP (enhanced Quadrature Encoder > Pulse) > module within each of the PWMSS units in the AM335x. The eQEP module is used > for > hardware decoding of rotrary encoders, motor encoders etc. > > Because the PWMSS module includes several components some of the existing > code in > the pwm driver could be reused. To make this common I have added a pwmss.h > header > and moved some of the pwmss specific defines and enum to this file. The > pwmss.c > file contains a refactored (simplified) version of the clock configuration > method that was previously in the pwm.c file. The pwmss_module_clk_config will > now be shared by both the pwm and eqep drivers (and eventually the ecap > driver if > that is ever added). > > The approach taken with the qep.h header was to move some of the qep specific > defines from the am335x.h header to this file. They are specific to the qep > function and would likely never be referenced by anything other than this > driver. > Doing this keeps these definitions with the driver code and reduces clutter > in > am335x.h header. > > The driver supports two primary modes of operation. A polled mode (which is > the > default mode), and an interrupt event driven mode. > > The one area of the patch that I am least happy with and could do with some > advice on > is the callback approach I have used for the interrupt event driven model. > Here a > unit timer is configured with a set time period (in nanoseconds) and on > expiry the unit > timer raises an interrupt. The interrupt handler calls an optional callback > function that > the user can supply when setting the unit timer period via the > beagle_eqep_set_timer_period. Although this works ok, I realise that calling > a user > function from a OS level interrupt is not desirable. Better suggestions for > this would be > gratefully received. I am fine with the callback happening in the interrupt context if it is clearly documented. Users are free to implement any event or thread sync model they want. Chris > > I will send a follow up email including some sample test programs with their > associated > output. > > Regards, > James > > James Fitzsimons (1): > Adding QEP driver to Beaglebone bsp > > bsps/arm/beagle/headers.am | 2 + > bsps/arm/beagle/include/bsp/bbb-pwm.h | 11 - > bsps/arm/beagle/include/bsp/pwmss.h | 54 +++ > bsps/arm/beagle/include/bsp/qep.h | 331 ++++++++++++++++++ > bsps/arm/beagle/pwm/pwm.c | 64 +--- > bsps/arm/beagle/pwmss/pwmss.c | 64 ++++ > bsps/arm/beagle/qep/qep.c | 435 ++++++++++++++++++++++++ > c/src/lib/libbsp/arm/beagle/Makefile.am | 6 + > 8 files changed, 896 insertions(+), 71 deletions(-) > create mode 100644 bsps/arm/beagle/include/bsp/pwmss.h > create mode 100644 bsps/arm/beagle/include/bsp/qep.h > create mode 100644 bsps/arm/beagle/pwmss/pwmss.c > create mode 100644 bsps/arm/beagle/qep/qep.c > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
