ZBasic Forum

What's the highest frequency anyone's kept track of from a quad encoder?
I'm trying to speed up some encoder code. Assume there can be no external counter, and that this is the sole task of the zx24.

Any suggestions and tips? Such as direct register reads instead of getpin, etc. Ideally this would be 30rp*s* at 512/rev, which obvsiously is too high for the zx, but I'm trying to get as close as possible...

Hmm, I had not tried to get the maximum speed out of the ZX for such a purpose. There has been a good thread about this general topic several months ago.

I think I would try to do high speed quadrature reading in this way.... Interrupts.

One interrupt per quadrature channel. Usually 2 channels, otherwise I suppose it would be called "hexature" or more.

Both interrupts should be set to trigger on rising AND falling edge.

Then use a state machine to keep track of the progression and execute the logic.

BUT, probably you already know the direction, because it is the direction you are turning the motor. In that case you do not really need "quadrature" coding. You could use just one of the quadrature signals for the speed. Even 256 *30 Hz is a fair number of transitions, but not impossible.

In the previous thread, we had discussed for simple counting to determine speed, using one of the counters, then periodically checking the counter. Clocking of the counter will allow for very fast repetitions.

-Tony

> ... Even 256*30 Hz is a fair number of transitions, but not impossible.

Hmmm. 30RPSx512x4 = 61.44kHz. That is a challenging interrupt rate for
these machines, I believe.


Tom

GTBecker wrote:> ... Even 256*30 Hz is a fair number of transitions, but not impossible.

Hmmm. 30RPSx512x4 = 61.44kHz. That is a challenging interrupt rate for
these machines, I believe.


Tom

Yes that would be fast, but still feasible if using a timer/counter .

Maybe I misinterpreted his 30rps * 512. I had thought that maybe that represented the total number of counts coming out of the quadrature encoder.

If it represents the number of "count creating items" (I.E. magnets, teeth in a comb, slits to pass light, etc), then I would have guessed that it would be double that. 30rps x 512 x 2, and that is still a lot.

But, if he uses a timer/counter on the AVR, then the hardware could easily keep up with that.

He did not say if he already can predict the direction. If so, he might be able to have half that frequency because he would not need a full blown quadrature, but just a ticker.

Also, I bet that it might be possible to use some glue logic to create a state machine that has 2 outputs. A direction signal, and a counter. The counter could be hooked to a shift register or 2. The total counts might be aboe to be read in that manner too.

-Tony

> ... if he uses a timer/counter on the AVR, then the hardware could easily keep up with that...

Sure, the AVR timer hardware can count that fast (and much faster) but I'm not aware that it can decode quadrature to yield a single up/down counter value.

A 24- or 32-bit up/down counter driven by external quadrature or dir/count - heck, several of them - would be a nice feature, actually.

GTBecker wrote:A 24- or 32-bit up/down counter driven by external quadrature or dir/count - heck, several of them - would be a nice feature, actually.

I would think that using 2 external interrupt pins, the VM could have a reasonably fast quadrature decoder, with little consumption of total processor bandwidth. I have never tried to code it in ASM (or anything else), but I _think_ it is a simple state-machine procedure.

-Tony

> ... it is a simple state-machine procedure...

If the two quadrature phases are simultaneously sampled, it _is_ easy.

Simultaneity might be difficult - indeed, impossible, I think - with two independent interrupts, one from each phase. I believe external glue logic is required to reduce any quadrature edge to a single common event that latches the quadrature state, then code can evaluate the changed state to determine what that event means.

Maybe that's too strict. For quadrature rates that are sufficiently slow, independent interrupts can keep an accurate count. At speed, though, latency will introduce ambiguity that external hardware can avoid.

Thanks guys for the replies so far. I don't know the direction, and so actually have to decode. Yes, as you surmised, it is 30rps*512 counts/rev (including quadrature already)...sorry for not being clear.

The following runs in a seperate task.
Currently, two pin change interrupts are set in waitForInterrupt(). As soon as the function continues, the states are evaluated, and the old/new bits are XOR-d per standard procedure: to save time by avoiding branches, the same function increments or decrements using count=count -1 + 2*(Mnew XOR Nold)...but most likely this is still the most time consuming section.

GTBecker wrote:> ... I believe external glue logic is required to reduce any quadrature edge to a single common event that latches the quadrature state, then code can evaluate the changed state to determine what that event means.

Exactly. This is a problem currently.

I've not used waitForInterrupt() before. Shouldn't the ZX be able to read in the kHz range, assuming a simple do : waitForInterrupt() : loop ?

Let's still assume I can't use any external hardware...further thoughts? Can inline assembly be inserted?

I'm still wondering what is the fastest direct quad decoding anyone's reached...

pjc30943 wrote:I'm still wondering what is the fastest direct quad decoding anyone's reached...

It seems as if you have come up with some good solutions for the ZX platform.

Definitely latency is an issue for ALL hardware, and it is a bigger issue for multitasking OS's The question of interrupt latency has come up before, and some answers were given. A search of the forums should find the thread for you.

In the end, the best way to determone the bandwidth it to test it. It sounds as if you have the program (and hardware too?) operational to some degree. So run the encoder slowly if possible. Have minimal other tasks running, so that the decoder has all the CPU resources available.

Maybe have the program output the low byte of the counter to a port, LEDs on the port could show the counting. An oscilloscope might also be helpful on an an output pin.

Then ramp up the speed until the counting gets erratic, or the pulse width on an output pin gets erratic. There ought to be a point at which you are clearly missing transistions and getting erroneous results.

See what quadrature frequency this is. You will know that this is effectively the maximum speed for your implementation of the decoding, with minimal bandwidth left for other processes.

Then add the rest of your software and see at what quadrature speed you start to get erroneous results. It might be best to expect to run the quadrature signal at half the measured maximum in order to be very reliable.

This is an interesting subject, and as far as I know, on one has tested the limits of the decoding.

As I said before this speed will apply to your decoding algorithm. I am sure you have a very efficient one, but sometimes non-intuitive changes can make measureable improvements in processing speed. One way to check is to look at the p-code output. Don Kinzer is also an extremely valuable resource for optimizing the ZBasic code.

When I was working on software SPI, I had a lot of help from people here, and I eventually DOUBLED the speed of what I had thought of as very efficient code! It was OK, but not optimal for the ZBasic platform. Un-rolling a loop help immensely. Some methofs to manipulate an output pin are slightly more efficient than others, etc.

So post your code and post your results! We are all waiting to help!

-Tony

pjc30943 wrote:to save time by avoiding branches, the same function increments or decrements using count=count -1 + 2*(Mnew XOR Nold)...but most likely this is still the most time consuming section.

This code IS probably the rate-limiting step (other that interrupt latency and the call overhead, which are likely to be at least as significant as the code you show here).

BUT

Maybe a state machine will be faster. Maybe a couple of branches will process faster than a 32 bit subtract, a 32 bit add, an 8 to 32 bit conversion, and an 8 bit XOR. I am assuming a 32 bit counter

Using a state machine, off the top of my rather flat head, you would have a 32 bit increment or decrement , but no other math, just branches for the states.

The state machine code would definitely be LONGER, but it might be more efficient.

-Tony

spamiam wrote:Definitely latency is an issue for ALL hardware...

I don't believe that's true, Tony. Latency is only an issue if time separates observation of an event from the event; that permits an undiscoverable change in state during the latent period.

Hardware that preserves the event state at the event time edge does not suffer from latency. That method still has an upper speed limit but it is due to event processing overlap, not latency.

This is slightly off topic since it is a hardware solution, but it is much faster than needed for most practical applications

http://www.lsicsi.com/pdfs/Data_Sheets/LS7366R.pdf

These chips don't seem to be in distribution (if anyone finds them let me know) but can be obtained directly from the factory.

Instead of having the uP do all the work, have you considered offloading the workload to a chip that does most of the decoding for you? Have a look at this:
http://www.usdigital.com/products/inter ... ucts.shtml

For example, the LFLS7166 - Quadrature encoder to microprocessor. RoHS compliant.

I have used a HP chip similar to this some years ago in a commercial product with excellent results. I even experimented with it and a BX24 with good results. The chip was the HCTL-1000 which has been superseded by the HCTL-1100. I was clocking the 1000 with a 1MHz oscillator at the time.

Vic

GTBecker wrote:Hardware that preserves the event state at the event time edge does not suffer from latency. That method still has an upper speed limit but it is due to event processing overlap, not latency.

OK, I see how you are separating the timing issues. I was including both of these concerns under one "latency" name.

I think that the two issues are still linked. Even with external hardware, the speed is not instantaneous, and if two quadrature events are too closely spaced, they still will not be resolved into separate events. It is just that external hardware can operate several orders of magnitude faster than anything on the ZX hardware.

So, how fast does the event measurement need to be in the scenario as given by the OP?

He said that it will be 30*512 = 15,390 Hz _total_ for encoder signals. For the typical quadrature encoder, the ON time and OFF time for each channel are equal. Also, they are 50% offset. Again, for a typical quadrature encoder. I am no expert on quadrature encoders, but all the ones I have seen seemed to operate this way.

If I understand the OP's description, and triggering events are on both rising and falling edges, then as long as the edge is processed and the system is ready for the next in less than 0.065mS then it will work.

But that time is about 958 clock ticks on the 14.7MHz ZX clock. I can not see how the ZX can task switch, process the interrupt, and task switch back in that few clocks. Especially not if anything else needs to get done!

If the OP was only referring to single edges on the events, then the processing may only have about 479 clocks. Not much time at all. Tom, I think this is where you were getting the 4x in your math? 30*512 events per second per channel * 2 edges per event * 2 channels?

If I understand the OP, then he has 30 * 128 events per second per channel * 2 edges per event * 2 channels.

No matter.... I think some external hardware is necessary for the OP.

I still would be interesting to see what bandwidth the software decoder can achieve anyway.

-Tony