This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Fast encoder sampling rate for nRF52xx

We need to sample two digital inputs GPIOs at rate of 100khz-1mhz. How can we do that? The QDEC is only good for up to 128us (~7khz) which is too slow for us. Is there a way to sample GPIO with DMA? If not, is there a way to do that without using interrupt every 10us?

Parents
  • Hi,

    You should be able to do this using GPIOTE, PPI and a TIMER in counter mode. See this post for some more information.

  • Using the GPIOTE, PPI and a timer or two it should definitely be possible to implement something similar to the QDEC without requiring a lot of MCU involvement.

    At the very simplest you could configure a timer in counter mode, and connect one of the encoder signals to the counter through the PPI. This would only require a single GPIOTE channel, one PPI channel, and one timer, but it would only give you the distance, not the direction. Also, it would only captures every other step.

    To capture all the steps you would need a total of 2 PPI channels and 2 GPIOTE channels.

    Capturing direction is a bit more complicated, but if you can spare 4 GPIOTE channels and 5 PPI channels (in total) it should be possible. Then you can configure the system so that you get an interrupt every time the direction changes, and you would have to manually reconfigure the direction detection mechanism to detect the opposite direction of the one you are currently in when the interrupt happens. Assuming direction doesn't change very often this should work OK.

Reply
  • Using the GPIOTE, PPI and a timer or two it should definitely be possible to implement something similar to the QDEC without requiring a lot of MCU involvement.

    At the very simplest you could configure a timer in counter mode, and connect one of the encoder signals to the counter through the PPI. This would only require a single GPIOTE channel, one PPI channel, and one timer, but it would only give you the distance, not the direction. Also, it would only captures every other step.

    To capture all the steps you would need a total of 2 PPI channels and 2 GPIOTE channels.

    Capturing direction is a bit more complicated, but if you can spare 4 GPIOTE channels and 5 PPI channels (in total) it should be possible. Then you can configure the system so that you get an interrupt every time the direction changes, and you would have to manually reconfigure the direction detection mechanism to detect the opposite direction of the one you are currently in when the interrupt happens. Assuming direction doesn't change very often this should work OK.

Children
No Data
Related