QDEC - nRF52840

RE: QDEC - nRF52840

Kenneth — Thu, 14 Jul 2022 17:26:13 GMT

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.

[quote user="Dude_eh"]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? [/quote]

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

RE: QDEC - nRF52840

Canadian_EE — Wed, 13 Jul 2022 21:01:59 GMT

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.

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.

RE: QDEC - nRF52840

Kenneth — Wed, 13 Jul 2022 20:21:38 GMT

Hi again,

My take on your questions:

[quote user=""]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.

How does this change if I select debounce enabled?

[/quote]

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

[quote user=""]Given debounce enabled, does the system still evaluate a sample every 128uS? Or is it every 258uS?[/quote]

See above.

[quote user=""]Given debounce enabled, is ACC still delayed by one sample, as mentioned in the QDEC documentation?[/quote]

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

[quote user=""]Does ACC and or accread get cleared every time I go to read it with a nrf_qdec_accread_get() function?[/quote]

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

[quote user=""] 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?[/quote]

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.

[quote user=""]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? [/quote]

No.

Best regards,
Kenneth

RE: QDEC - nRF52840

Canadian_EE — Wed, 13 Jul 2022 18:16:53 GMT

Hi,

I have gone through the QDEC description but that was lacking in the area of my questions.

thanks

RE: QDEC - nRF52840

Kenneth — Wed, 13 Jul 2022 17:21:10 GMT

Hi,

I believe the QDEC peripheral is described in the product specification for the nRF52840?
https://infocenter.nordicsemi.com/topic/ps_nrf52840/qdec.html

Best regards,
Kenneth