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
_______________________________________________
devel mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/devel
