Dave,
I saw a number of issues with your design.
1: Won't count up or down
Your clock to Counter_Logic is the same as Pin_encoder_A. Both upCnt and downCnt need to have TWO clock transitions to detect the 'rising' edge needed to increment or decrement the counter. Since the clock input is the same as one of the encoder pins you only get at most ONE clock. This is not enough. You need another clock source to use the counter component.
2: The Count will be WRONG even if you fix 1:
You use the inverted signal of upCnt to generate downCnt from the AND gate. In this case, either Cnt input will be active much longer (for many clock cycles) than intended.
Recommendation:
Cypress/Infineon provides a Quadrature Decoder component. It has the appropriate logic and glitch filtering in the case you are using a mechanical switching encoder.
I've made changes to your project to substitute a 32-bit QuadDec component in place of the Counter component.
I've attached this project. I've made some codes changes as well. I have not tested it since I don't have an encoder. However, your code is fairly straight forward and should be easy to debug.
I've also enabled the glitch filter.
Use this component. Cypress did much of the work for you.
3: Avoid using blocking functions in an ISR
You use the UART_PutString() in the ISR. This is a potential blocking function. This might cause unintended delays. In your case, you are trying to print up to 14 characters to the UART. Since the UART only has a byte-character FIFO, the first 4 chars are immediately loaded but the remaining 10 bytes block return of the function until the last byte is loaded into the FIFO. At 115.2Kbps, this means t will block for 868us.
In my project mods, I left the UART_PutString() in the ISR. It shouldn't be a "show-stopper" in your project as it currently stands.
Dave,
I saw a number of issues with your design.
1: Won't count up or down
Your clock to Counter_Logic is the same as Pin_encoder_A. Both upCnt and downCnt need to have TWO clock transitions to detect the 'rising' edge needed to increment or decrement the counter. Since the clock input is the same as one of the encoder pins you only get at most ONE clock. This is not enough. You need another clock source to use the counter component.
2: The Count will be WRONG even if you fix 1:
You use the inverted signal of upCnt to generate downCnt from the AND gate. In this case, either Cnt input will be active much longer (for many clock cycles) than intended.
Recommendation:
Cypress/Infineon provides a Quadrature Decoder component. It has the appropriate logic and glitch filtering in the case you are using a mechanical switching encoder.
I've made changes to your project to substitute a 32-bit QuadDec component in place of the Counter component.
I've attached this project. I've made some codes changes as well. I have not tested it since I don't have an encoder. However, your code is fairly straight forward and should be easy to debug.
I've also enabled the glitch filter.
Use this component. Cypress did much of the work for you.
3: Avoid using blocking functions in an ISR
You use the UART_PutString() in the ISR. This is a potential blocking function. This might cause unintended delays. In your case, you are trying to print up to 14 characters to the UART. Since the UART only has a byte-character FIFO, the first 4 chars are immediately loaded but the remaining 10 bytes block return of the function until the last byte is loaded into the FIFO. At 115.2Kbps, this means t will block for 868us.
In my project mods, I left the UART_PutString() in the ISR. It shouldn't be a "show-stopper" in your project as it currently stands.
Dave,
I'm glad it's working ... a kinda ... sorta ...
The component is capable of operating with a clock input up to 28 MHz. In your case, with A and B pulsing at 600 Hz seconds, you theoretically only need an input clock of 6000 Hz according to the spec sheet. Your applying 1 MHz is in theory 167x overkill. And yet it appears to miss pulses.
According to your previous post: "... but at high speed it loses a lot of pulses."
This assumes that at slow speeds you are not losing pulses.
Let's try some experiments.
Experiment #1
Increase the clock input to 28 MHz. Does it lose any pulses at high-speed AB inputs? If not, you're AB frequency might actually be higher than 600 pps.
Experiment #2
Connect the "interrupt" output of the QuadDec component to a pin.
The interrupt output goes active on the following events:
▪ Counter overflow and underflow
▪ Counter reset due to index input (if index is used)
▪ Invalid state transition on the A and B inputs
In a properly operating AB inputs you should only get the "Counter overflow and underflow" event. With the counter depth being 32-bits this should occur relatively rarely.
If you are getting 'other' interrupt events, you might want to check your AB inputs. Also, there is a API to read the Status register to determine what type of event occurred.
Experiment #3
Have you captured your AB inputs on a scope? Are the signals clean? I don't know what you are using for an encoder, but you might need to condition the AB inputs which might be at a different threshold than the digital GPIO inputs being used.
