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?

  • Hi,

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

  • thanks you for the response. we need to sample 2 gpios that are inputs of a stepper motor encoder. We there for need to know per every rising or falling edge of each io compared to the other io. In other words we need a repeated pattern like this: io0 rise, io1 rise, io0 fall, io1 fall. We thus cannot sample count of events in 1 second. We need to sample the combination of BOTH io's every time each toggles. This is exactly what the QDEC does, but the QDEC is too slow for us. what i did is attached both to GPIOE interrupt and sample the data to a buffer in the interrupt context. This is working but very waste full in real time. Can i still use the link you added for these purposes some how?

  • 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.

  • cant i clock the the counter in rising & falling mode instead of just rising edge? if i have to manually change direction then i may just as well use a simple interrupt every rising/falling and read the gpio's to a buffer in the interrupt (simulate DMA). The interrupt just reads io to buffer and thats it.

  • Yes, GPIOTE can generate an event on any change(rising & falling), and the event can trigger the TIMER task to increase the counter.

Related