[PATCH 0/1] Adds QEP driver to Beaglebone BSP

Chris Johns chrisj at rtems.org
Sat Aug 22 08:34:30 UTC 2020


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
> 


More information about the devel mailing list