Beaglebone QEP driver design question

[Chris Johns]

On 21/7/20 7:49 pm, James Fitzsimons wrote:
> Hi all,
> 
> I have a very basic version of the QEP driver for the Beaglebone black working now. 

Nice.

> I will tidy up my code and submit a patch in the next few days. For first
> patches that are likely to require a bit of discussion etc, is the best idea to
> still submit them to this list per the normal process, or is there an
> alternative approach that would be better? (The patch adds several files and
> modifies several existing ones).
> 
> Secondly, I have an RTEMS style question. The driver would work best if I had a
> small struct that contained a few properties about the driver configuration. One
> such property is difficult to intuit from the state of the registers and so
> would be better in a separate data structure. This would mean that the code
> might look something like this:
> 
> typedef struct {
>   BBB_PWMSS pwmss_id;
>   BBB_QEP_COUNT_MODE mode;
> } bbb_eqep_t;

The _t on a struct is reserved for standards. We are slowly removing it's use in
RTEMS.

> 
> rtems_status_code beagle_qep_init(bbb_eqep_t* eqep);
> 

What about _open and then you could add a _close?

> int32_t beagle_qep_get_position(bbb_eqep_t* eqep);
> 
> Is that in keeping with the RTEMS approach? Looking at some of the other BSPs I
> see similar approaches for other drivers that need to track state for multiple
> instances of hardware.

The interface seem simple enough so I think it is fine.

Chris