7
$\begingroup$

PSOC4 provides a quadrature decoder functionality but I was unable to find specifics on its performance in the datasheets. Sure I know I need to read and utilize the count until the 16 bits of its counter overflow, but that's some 32k per iteration of the main loop of my program. If a precise encoder is attached to a fast motor, that produces lots and lots of pulses in a very short time, and I'm worried the decoder module won't be able to keep up.

So, does anyone know what is the maximum performance of the decoder block - the minimum timings of its input?

Improve this question
$\endgroup$
0

2 Answers 2

Reset to default
6
$\begingroup$

Quadrature decoder

Looking at the PSoC 4 TCPWM datasheet the maximum operating frequency of the counter block is 48MHz, with a counter resolution of 21ns.

Assuming that you have a high resolution incremental rotary encoder with 10,000 counts per revolution, and spin the rotor at 15,000 rpm, that's 2,500,000 counts per second (2.5MHz), comfortably less than the 48MHz max. sampling rate.

Sadly, it is not clear if the PSoC 4 TCPWM suffers the same 10x sampling requirement as the PSoC QuadDec mentioned in Simon Jenkins' answer. I suspect not, as the datasheet doesn't include the clock signals on the timing diagrams. This implies that PSoC 4 TCPWM is edge driven (limited by the counter clock), while PSoC QuadDec is driven by level at each clock edge and thus limited by the sampling at the clock frequency.

Even if the PSoC 4 TCPWM does require over sampling, then the max 2.5MHz pulse train is still less than both 10x at 48MHz for the PSoC 4 TCPWM and 28MHz for the PSoC QuadDec.

If you only need 2000 PPR at 6000 RPM (as suggested in your comment), then you only need to support 200 KHz (2000*6000/60), so a 2MHz clock should be sufficient.

Interrupt handling

Another concern is whether the CPU will be able to cope with the interrupts this could generate.

If we assume that you are running the quadrature right at the limit of the decoder block, i.e. 48MHz with a 16bit counter you will be getting 1465 overflow interrupts per second, so unless you can service your interrupt (including any context switching required) in less than 682 micro seconds, then you are going to struggle.

Luckily, it looks like the the Cortex-M0 processors have very efficient ISR handling (See A Beginner’s Guide on Interrupt Latency - and Interrupt Latency of the ARM® Cortex®-M processors) so unless your ISR is very inefficient, it should be able to handle this.

Resolution

Incidentally, it looks like you will need to use X4 mode if you want to count individual quadrature state transitions. If you use X1 then you only see whole quadrature cycles (4 states), while if you use X2 then you only see half of the states.

Improve this answer
$\endgroup$
2
  • $\begingroup$ I agree, it looks like this is different from the data sheet I found, isn't sampled hence doesn't have the 10x sampling requirement. No clock on timing diagrams as you say, they just show which edges trigger the counter. Also the de-glitching (which was based on sampling the inputs) is not present. $\endgroup$
    – Simon Jenkins
    Commented Jul 30, 2015 at 11:33
  • $\begingroup$ The interrupt handling can be quite efficient; all it needs is to offload the count by adding it (with sign) to a 32-bit or 64-bit variable. So, one 32 or 64 bit addition, one write (zero), and the interrupt can end. $\endgroup$
    – SF.
    Commented Jul 30, 2015 at 11:36
5
$\begingroup$

This doesn't get mentioned in some documentation for the PSoC quadrature decoder component, but in other versions (e.g. here) it states that:

The clock input frequency should be greater than or equal to 10x the maximum A or B input frequency.

Given that AFAICT you can clock the decoder at multi-MHz frequencies, I think it can likely keep up with most plausible motors.

EDIT: It seems the component I found the data for isn't quite the one the question was about so, whilst this answer may be useful to someone some day, it probably shouldn't be the highest voted nor the accepted one here.

Improve this answer
$\endgroup$
4
  • $\begingroup$ 2000 PPR at 6000RPM is already 12KHz of the signal, so the clock should be 120KHz to handle that. Still, I believe even 1MHz was available. $\endgroup$
    – SF.
    Commented Jul 29, 2015 at 23:10
  • $\begingroup$ Hi @SF. if that is part of your system spec, it would be good to edit into your question. I had to make far too many assumptions last night when writing my answer without this information. $\endgroup$
    – Mark Booth
    Commented Jul 30, 2015 at 10:41
  • $\begingroup$ @MarkBooth: That would make the answer awfully specific. I'd much rather prefer one that gives the top ratings instead of one bit of data "you're within / outside the tolerances". The system can be throttled to fit within the specs, at no great loss. $\endgroup$
    – SF.
    Commented Jul 30, 2015 at 11:27
  • $\begingroup$ On stack exchange it's generally better to ask more specific questions and then allow more generalised answers to flow out of them. That's how we handle duplicates. We don't close a question as a duplicate when the question duplicates another question so much as when a question has already been answered by another question. $\endgroup$
    – Mark Booth
    Commented Jul 30, 2015 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.