PSoC 5LP 32-bit Quad Decoder

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Nano
Level 1
Level 1
First question asked Welcome!

I'm using the 32-bit Quad Decoder in PSoC 5LP (CY8C56LP family).

It works based on a 16-bit Quad Decoder in hardware and the PSoC generated code for the corresponding 32-bit counter.

I've selected "counter resolution 1x" and "Use input index" (but not "Enable glitch filter").

The maximum clock for the component based on the datasheet is about 30 MHz depending on the selections,
and the maximum input data rate for AB signals is always one tenth of the clock.

Having used the chip at maximum master clock frequency (80MHz), the closest clock I can provide to the Quad Decoder component is 80/3 = 26.66 MHz,
and so 2.66 MHz is the maximum input data rate for AB signals.

The PSoC generated code (ISR) updates the most significant 16-bits of the 32-bit counter value upon receiving an interrupt from the 16-bit component.

The interrupt is be triggered when there is either an overflow, an underflow or a reset event in the 16-bit counter.

There is only one Interrupt output signal from the hardware component for the three possible events,
which makes it almost impossible to put together a 32-bit Quad Decoder purely in the hardware.

There are a few questions which I can't find an answer for in the datasheets.

1. What happens if there is a number of phase changes in AB signals in fractions of micro seconds when the 16-bit counter is 0 or 65535?
I expect the interrupt signal can still catch up with these changes but doubt it whether the ISR can catch up with all of the events?
In every ISR the status register is read and cleared, and it's set again if there is a second event in the middle of the ISR being executed,
but if there is a third event as well and overwrites the status register, would we loose the second event in the status register?

2. How long (maximum) the ISR would take to complete (for master clock at 80MHz)?

3. If I decide to use a 16-bit Quad Decoder and implement the 32-bit counter myself in firmware,
I need to know how long does it take for each Write to the 16-bit counter? does it loose the incoming AB signals during the write?

4. There is note in the datasheet that the Quad Decoder might work with higher clocks but it's up to the user to confirm it,
how can I confirm it? If I provide to the Quad Decoder component with 80/2 = 40 MHz clock, how and how long I need to run a test to confirm it's all working?

4. My project gets even more challenging as I have three of these 32-bit Quad Decoders,
and at the same time use all 6 HID USB interrupts (of course at lower priorities).
Finally, based on the challenges I described, any ideas why my 32-bit counter value jumps up or down by 65535 a few times during a 24 hours test?

Thanks in advance for any advice/solution.

0 Likes
1 Solution
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Nano,

I'll do what I can to answer your questions and try to reproduce your results.

However to best answer your questions and to try to replicate your results I have a few questions:

  • What is your minimum pulse width for each of your inputs to the QuadDec?  
  • Are the source for the QuadDec inputs
    • Mechanical switches? 
    • Hall Effects?
    • Optical encoder?
    • Other?

Here's my attempt to answer your many questions without having the above answers:


I've selected "counter resolution 1x" and "Use input index" (but not "Enable glitch filter").


The QuadDec component is a HW state machine.   It is designed to operate as fast as the HW logic and the input clock will allow it.

The QuadDec has the ability to decode based on 4 (hence Quad) states of the two inputs A and B.  =>

State Input A Input B
0 0 0
1 0 1
2 1 1
3 1 0
0 0 0

Each state MUST transition from one state to the next state above or below.  Any skipped state transitions will be flagged as a Invalid State event.

When you select 1x resolution you are only select one of the states (state 1) transition to increment/decrement the count.   At maximum Input clock (26.66MHz) and supported A/B frequency (2.666Mhz) , you will get an over or under flow interrupt every 12.3 msecs for the 16-bit QD and 1610 secs for the 32-bit QD.

When you select 2x, your are selecting two states (state 1 and 3) transitions increment/decrement the count.   At maximum Input clock (26.66MHz) and supported A/B frequency (2.666Mhz) , you will get an over or under flow interrupt every 6.1 msecs for the 16-bit QD and 805 secs for the 32-bit QD.

Selecting 4x will select ALL transitions to increment/decrement the count.   At maximum Input clock (26.66MHz) and supported A/B frequency (2.666Mhz) , you will get an over or under flow interrupt every 3.0 msecs for the 16-bit QD and 402.5 secs for the 32-bit QD.

Using 1x will maximize when the counter over/under flows. 2x will over/under flow 2s sooner and of course 4x will over/under flow 4x sooner.


The maximum clock for the component based on the datasheet is about 30 MHz depending on the selections,
and the maximum input data rate for AB signals is always one tenth of the clock.


I would not recommend pushing the QuadDec input clock higher than 30MHz (26.66Mhz should be safe).  Faster could violate setup and hold time specs for the logic latches needed.

At 30MHz, the fastest A and B cycle frequency it can support is 3MHz.  


The PSoC generated code (ISR) updates the most significant 16-bits of the 32-bit counter value upon receiving an interrupt from the 16-bit component.

The interrupt is be triggered when there is either an overflow, an underflow or a reset event in the 16-bit counter.

I don't understand.  Are you planning on using the 16-bit or 32-bit QuadDec?


There is only one Interrupt output signal from the hardware component for the three possible events,
which makes it almost impossible to put together a 32-bit Quad Decoder purely in the hardware.

The 32-bit QuadDec component creates a 100% HW state machine counter for the least significant 16 bits and uses an interrupt to increment/decrement the most significant 16 bits for the upper part of the counter.

1. What happens if there is a number of phase changes in AB signals in fractions of micro seconds when the 16-bit counter is 0 or 65535?
I expect the interrupt signal can still catch up with these changes but doubt it whether the ISR can catch up with all of the events?
In every ISR the status register is read and cleared, and it's set again if there is a second event in the middle of the ISR being executed,
but if there is a third event as well and overwrites the status register, would we loose the second event in the status register?

Using the 1x resolution on a 16-bit QuadDec , you will only get one counter inc/dec per the state 1 transition.   If you have other phase transitions FASTER than the input clock /4 than you will get state invalid interrupts and the HW state machine connected to the counter will possibly give wrong results.   Note:  You can only get interrupt events:

  • Overflow when the counter wraps from 32767 to -32768.
  • Underflow when the counter wraps from -32768 to 32767 
  • Reset when the index pulse is detected and the counter resets (if used).
  • Invalid input when the state machine detects an invalid state transition from the above table.

2. How long (maximum) the ISR would take to complete (for master clock at 80MHz)?


I don't have an exact answer to this but the general rule of thumb is the faster BUS_CLK, the faster the ISR processing.

Remember as I stated above, you only get ISRs from the QD, on interrupting events which don't happen quite that often unless you are getting loads of Invalid input events.  If so, you're clocking the QD too slow or you're getting AB transitions too fast.


3. If I decide to use a 16-bit Quad Decoder and implement the 32-bit counter myself in firmware,
I need to know how long does it take for each Write to the 16-bit counter? does it loose the incoming AB signals during the write?


It's your choice about using the 16-bit QD and implementing 32-bit in FW.  Apparently, the QD component always does that for you.  It uses an interrupt to increment/decrement the Most Significant 16 bits of the 32-bit counter.

Finally, based on the challenges I described, any ideas why my 32-bit counter value jumps up or down by 65535 a few times during a 24 hours test?


Are we talking about "jumps" when using 3  16-bit QDs or 3 32-bit QDs?

If you're talking about 16-bit QDs, you will get what appears to be jump every over or under flow (due to counter wrap-around).   The same will be true for 32-bit QDs except 130,900x less often.

Update: 1/11/22

If you're getting these "jumps" using 32-bit QDs, it could be that you are seeing a occasional coherence issue with the component since the upper 16-bits are modified in an ISR.

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

0 Likes
2 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

That are a lot of questions digging deeply into the component which I cannot answer, you need a real expert.

But what I can say is:

The quad decoder was designed for mechanical created movement signals which are usually in the kHz range thus giving any ISR time enough to handle events.

A simple decoder can be implemented using a state-machine and the outputs could be connected to a counter. No need for interrupts. Could be of interest to generate an interrupt when a given position (count) is reached

So my questions are:

Where do the signals come from

Why is such a high frequency needed

Are there better solutions for your problem

 

Happy coding

Bob

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Nano,

I'll do what I can to answer your questions and try to reproduce your results.

However to best answer your questions and to try to replicate your results I have a few questions:

  • What is your minimum pulse width for each of your inputs to the QuadDec?  
  • Are the source for the QuadDec inputs
    • Mechanical switches? 
    • Hall Effects?
    • Optical encoder?
    • Other?

Here's my attempt to answer your many questions without having the above answers:


I've selected "counter resolution 1x" and "Use input index" (but not "Enable glitch filter").


The QuadDec component is a HW state machine.   It is designed to operate as fast as the HW logic and the input clock will allow it.

The QuadDec has the ability to decode based on 4 (hence Quad) states of the two inputs A and B.  =>

State Input A Input B
0 0 0
1 0 1
2 1 1
3 1 0
0 0 0

Each state MUST transition from one state to the next state above or below.  Any skipped state transitions will be flagged as a Invalid State event.

When you select 1x resolution you are only select one of the states (state 1) transition to increment/decrement the count.   At maximum Input clock (26.66MHz) and supported A/B frequency (2.666Mhz) , you will get an over or under flow interrupt every 12.3 msecs for the 16-bit QD and 1610 secs for the 32-bit QD.

When you select 2x, your are selecting two states (state 1 and 3) transitions increment/decrement the count.   At maximum Input clock (26.66MHz) and supported A/B frequency (2.666Mhz) , you will get an over or under flow interrupt every 6.1 msecs for the 16-bit QD and 805 secs for the 32-bit QD.

Selecting 4x will select ALL transitions to increment/decrement the count.   At maximum Input clock (26.66MHz) and supported A/B frequency (2.666Mhz) , you will get an over or under flow interrupt every 3.0 msecs for the 16-bit QD and 402.5 secs for the 32-bit QD.

Using 1x will maximize when the counter over/under flows. 2x will over/under flow 2s sooner and of course 4x will over/under flow 4x sooner.


The maximum clock for the component based on the datasheet is about 30 MHz depending on the selections,
and the maximum input data rate for AB signals is always one tenth of the clock.


I would not recommend pushing the QuadDec input clock higher than 30MHz (26.66Mhz should be safe).  Faster could violate setup and hold time specs for the logic latches needed.

At 30MHz, the fastest A and B cycle frequency it can support is 3MHz.  


The PSoC generated code (ISR) updates the most significant 16-bits of the 32-bit counter value upon receiving an interrupt from the 16-bit component.

The interrupt is be triggered when there is either an overflow, an underflow or a reset event in the 16-bit counter.

I don't understand.  Are you planning on using the 16-bit or 32-bit QuadDec?


There is only one Interrupt output signal from the hardware component for the three possible events,
which makes it almost impossible to put together a 32-bit Quad Decoder purely in the hardware.

The 32-bit QuadDec component creates a 100% HW state machine counter for the least significant 16 bits and uses an interrupt to increment/decrement the most significant 16 bits for the upper part of the counter.

1. What happens if there is a number of phase changes in AB signals in fractions of micro seconds when the 16-bit counter is 0 or 65535?
I expect the interrupt signal can still catch up with these changes but doubt it whether the ISR can catch up with all of the events?
In every ISR the status register is read and cleared, and it's set again if there is a second event in the middle of the ISR being executed,
but if there is a third event as well and overwrites the status register, would we loose the second event in the status register?

Using the 1x resolution on a 16-bit QuadDec , you will only get one counter inc/dec per the state 1 transition.   If you have other phase transitions FASTER than the input clock /4 than you will get state invalid interrupts and the HW state machine connected to the counter will possibly give wrong results.   Note:  You can only get interrupt events:

  • Overflow when the counter wraps from 32767 to -32768.
  • Underflow when the counter wraps from -32768 to 32767 
  • Reset when the index pulse is detected and the counter resets (if used).
  • Invalid input when the state machine detects an invalid state transition from the above table.

2. How long (maximum) the ISR would take to complete (for master clock at 80MHz)?


I don't have an exact answer to this but the general rule of thumb is the faster BUS_CLK, the faster the ISR processing.

Remember as I stated above, you only get ISRs from the QD, on interrupting events which don't happen quite that often unless you are getting loads of Invalid input events.  If so, you're clocking the QD too slow or you're getting AB transitions too fast.


3. If I decide to use a 16-bit Quad Decoder and implement the 32-bit counter myself in firmware,
I need to know how long does it take for each Write to the 16-bit counter? does it loose the incoming AB signals during the write?


It's your choice about using the 16-bit QD and implementing 32-bit in FW.  Apparently, the QD component always does that for you.  It uses an interrupt to increment/decrement the Most Significant 16 bits of the 32-bit counter.

Finally, based on the challenges I described, any ideas why my 32-bit counter value jumps up or down by 65535 a few times during a 24 hours test?


Are we talking about "jumps" when using 3  16-bit QDs or 3 32-bit QDs?

If you're talking about 16-bit QDs, you will get what appears to be jump every over or under flow (due to counter wrap-around).   The same will be true for 32-bit QDs except 130,900x less often.

Update: 1/11/22

If you're getting these "jumps" using 32-bit QDs, it could be that you are seeing a occasional coherence issue with the component since the upper 16-bits are modified in an ISR.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes