QDEC - nRF52840

[Canadian_EE]

2022 July 12 - QDEC - Interrupt.zip

Hi,

I'm working through the QDEC using the nRF2840 evaluation board and I've run into some confusion.

1. I have trouble getting the ACC or ACCREAD registers to actually accumulate over time. If I want to keep track of increments, I have to record this manually using the interrupt and an external variable. I can't just rely on the system to increment ACC by itself.
2. The documentation says that the QDEC samples at a rate of 1MHz. I'm guessing the device uses oversampling, scaling this 1uS rate down to 128uS because the smallest SAMPLEPER you can select is 128uS.
   1. How does this change if I select debounce enabled?
   2. Given debounce enabled, does the system still evaluate a sample every 128uS? Or is it every 258uS?
   3. Given debounce enabled, is ACC still delayed by one sample, as mentioned in the QDEC documentation?
3. Does ACC and or accread get cleared every time I go to read it with a nrf_qdec_accread_get() function?

    I don't want to have ongoing interrupts to manage this hardware peripheral. I want it to accumulate on its own, requiring servicing perhaps only if there is an overflow or an invalid state transition. How does Nordic recommend enabling this behavior?

Also

I have been through the provided nRF52 example. I didn't find my questions answered by that example.

Also also, 

Is it possible to trigger an interrupt event given an invalid state transition? If so, how? What is the NRF_QDEC_EVENT_????? reference for it? 

[Kenneth]

Hi again,

My take on your questions:

The documentation says that the QDEC samples at a rate of 1MHz. I'm guessing the device uses oversampling, scaling this 1uS rate down to 128uS because the smallest SAMPLEPER you can select is 128uS.

1. How does this change if I select debounce enabled?

There is no oversampling if debounce is not enabled, ref: 

"The QDEC decodes the output from the off-chip encoder by sampling the QDEC phase input pins (A and B) at a fixed rate as specified in the SAMPLEPER register."

If debounce is enabled, then this changes, ref:

"When enabled through the DBFEN register, the filter inputs are sampled at a fixed 1 MHz frequency during the entire sample period (which is specified in the SAMPLEPER register). The filters require all of the samples within this sample period to equal before the input signal is accepted and transferred to the output of the filter.

As a result, only input signal with a steady state longer than twice the period specified in SAMPLEPER are guaranteed to pass through the filter."

Given debounce enabled, does the system still evaluate a sample every 128uS? Or is it every 258uS?

See above.

Given debounce enabled, is ACC still delayed by one sample, as mentioned in the QDEC documentation?

I can only find there is a delay when debounce is enabled yes:

"When the debounce filters are enabled, displacements reported by the QDEC peripheral are delayed by one SAMPLEPER period."

Does ACC and or accread get cleared every time I go to read it with a nrf_qdec_accread_get() function?

Looking at the implementation of nrf_qdec_accread_get() I can find it simply return NRF_QDEC->ACCREAD; 

According to documentation this register is only updated using either of the two tasks READCLRACC or RDCLRACC . Both these tasks also clear the ACC register, ref:

"The ACC and ACCDBL registers can be cleared by the READCLRACC and subsequently read using the ACCREAD and ACCDBLREAD registers.

The ACC register can be separately cleared by the RDCLRACC and subsequently read using the ACCREAD registers."

    I don't want to have ongoing interrupts to manage this hardware peripheral. I want it to accumulate on its own, requiring servicing perhaps only if there is an overflow or an invalid state transition. How does Nordic recommend enabling this behavior?

It's possible to read the ACC and ACCDBL register directly (instead of using executing above mention tasks that clear them), but be aware the max value for those two registers are +-1024. So I am not sure it's a good idea to let them run for a long time before clearing them.

Is it possible to trigger an interrupt event given an invalid state transition? If so, how? What is the NRF_QDEC_EVENT_????? reference for it? 

No.

Best regards,
Kenneth

[Canadian_EE]

The documentation says that the QDEC samples at a rate of 1MHz. I'm guessing the device uses oversampling, scaling this 1uS rate down to 128uS because the smallest SAMPLEPER you can select is 128uS.

1. How does this change if I select debounce enabled?

There is no oversampling if debounce is not enabled, ref: 

"The QDEC decodes the output from the off-chip encoder by sampling the QDEC phase input pins (A and B) at a fixed rate as specified in the SAMPLEPER register."

If debounce is enabled, then this changes, ref:

"When enabled through the DBFEN register, the filter inputs are sampled at a fixed 1 MHz frequency during the entire sample period (which is specified in the SAMPLEPER register). The filters require all of the samples within this sample period to equal before the input signal is accepted and transferred to the output of the filter.

As a result, only input signal with a steady state longer than twice the period specified in SAMPLEPER are guaranteed to pass through the filter."

If the system is sampling at a rate of 1MHz or .5MHz, than why is a sample generated only every 128uS? That would suggest some processing is occurring in the additional 126 or 127uS; depending on whether it is sampled once or twice with debounce. 

*********

Given debounce enabled, does the system still evaluate a sample every 128uS? Or is it every 258uS?

See above.

Given debounce enabled, is ACC still delayed by one sample, as mentioned in the QDEC documentation?

I can only find there is a delay when debounce is enabled yes:

"When the debounce filters are enabled, displacements reported by the QDEC peripheral are delayed by one SAMPLEPER period."

When I read ACCREAD, is ACCREAD off by up to one increment given debounce enabled? 

******** 

Does ACC and or accread get cleared every time I go to read it with a nrf_qdec_accread_get() function?

Looking at the implementation of nrf_qdec_accread_get() I can find it simply return NRF_QDEC->ACCREAD; 

According to documentation this register is only updated using either of the two tasks READCLRACC or RDCLRACC . Both these tasks also clear the ACC register, ref:

"The ACC and ACCDBL registers can be cleared by the READCLRACC and subsequently read using the ACCREAD and ACCDBLREAD registers.

The ACC register can be separately cleared by the RDCLRACC and subsequently read using the ACCREAD registers."

    So then what you are saying is for "nrf_qdec_accread_get()" to get the most recent value, in must be clearing ACC in the process...? 

***************

    I don't want to have ongoing interrupts to manage this hardware peripheral. I want it to accumulate on its own, requiring servicing perhaps only if there is an overflow or an invalid state transition. How does Nordic recommend enabling this behavior?

It's possible to read the ACC and ACCDBL register directly (instead of using executing above mention tasks that clear them), but be aware the max value for those two registers are +-1024. So I am not sure it's a good idea to let them run for a long time before clearing them.

    I would like the system to accumulate, but not require an interrupt for it to update ACCREAD every time a movement occurs. Are you saying this isn't possible without interrupts? For instance, I couldn't get the DMA to update ACCREAD? Not simply just to copy ACC into ACCREAD then  clear ACC, but to add the current value of ACC into ACCREAD then clear ACC. 

******************

Is it possible to trigger an interrupt event given an invalid state transition? If so, how? What is the NRF_QDEC_EVENT_????? reference for it? 

No.

The documentation mentions a "DBLRDY" event in the occurrence of one or more invalid transitions. How do I make this event trigger an interrupt? If it is an event, shouldn't that mean I can make it cause an interrupt...?

Let me know, thanks. Also, please see the documentation at Nordic Semiconductor Infocenter regarding the DBLRDY event. 

[Kenneth]

I don't want to comment on why it's implemented the way it is. Have in mind though that the implementation ensure no movement is lost when using the READCLRACC or RDCLRACC tasks.

Canadian_EE said:

Is it possible to trigger an interrupt event given an invalid state transition? If so, how? What is the NRF_QDEC_EVENT_????? reference for it? 

You can connect the DBLRDY event to the EGU peripheral to trigger a EGU interrupt, then when you receive this interrupt you will then know that it is triggered by the DBLRDY event.
https://infocenter.nordicsemi.com/topic/ps_nrf52840/egu.html

Kenneth