Skip to content

Possible optimization for encoder PIO #65

@Tricopetaurus

Description

@Tricopetaurus

Hello,

I've started playing with my own XRP in Rust as a good excuse to pivot my embedded C knowledge to something "fresher". While doing this I was reviewing the PIO implementation for the encoders.

First off, I really like the jump table solution to the stateful problem. I think it's clean. The only thing I was confused by was the python accessor around it. I think that code add aligns with this comment from another issue post:

#31 (comment)

If I'm understanding the accessor and PIO right, on this line the latest values are always pushed to the RX buffer. This also has the useful benefit of zeroing out ISR, necessary for the jumptable. But, if the buffer is already full we're dropping the latest value on the floor. That has led to this block of code which must read the buffer until it's emptied.

I'm curious if instead we could leverage the STATUS register. The PIO documentation wasn't exactly clear on its use here, but on a forum post someone has checked out the header files and teased out a decent definition: link.

I don't know off-hand if we have a convenient accessor to this in Py-land, but it sounds like one could configure STATUS to check for an "RX Buffer Empty" condition, and only then push the latest data out. In either condition, one would then need another MOV to zero out ISR before continuing the existing flow.

Please let me know if my understanding is wrong on any of this. I'm just doing an initial read of how your team has solved this problem so I can do something similar.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions