Angular Tracking with Encoder

TheOutfield

I recently made a post on another thread about having another counter that would act the same as the system counter.· I wanted the capability to have·one Cog manage a counter that tracks angular position·then trigger events off of it from other Cogs.· I kind of wanted to do something in the nature

translate from waitcnt(time)··to ·---> waitang(angle)

Any ideas for the most efficient way of doing this?· I am working with an encoder that has 1024 PPR and 8000 RPM.· Therefore I have to deal with events in the 140kHz range.

Ken Peterson

The counters in a cog can be set up for pulse counting, but they apparently only count in one direction if left unattended by code. It would be ideal if you could get one to count up on the rising edge of pin A while the Pin B is high, and count down on the rising edge of pin A while pin B is low. Then your position could be reflected in PHSA. Not sure yet how simply you can do what you are trying to do using the counters.

You should be able to keep up with it in assembly. Set the FRQA register to 1 or -1 based on your direction input. I was going to suggest waitpeq for the direction pin, but you will need to keep a loop to copy your PHSA register to HUB so other cogs can access it, so you you probably need to poll the direction pin.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


The more I know, the more I know I don't know.· Is this what they call Wisdom?

Post Edited (Ken Peterson) : 10/14/2007 3:44:30 PM GMT

OzStamp

Hi "Outfield"

There is an Object for encoders by Jeff Martin "Parallax snr software guru"
It is in the object downlaod section
We have used it and it works..
Does tracking of clock and anti clockwise ( Cw/CCW) rotation of multiple encoders.

cheers
Ronald OZ

Graham Stabler

I wrote a compact object for high speed reading of a single encoder as part of this thread. I got max read speeds of 1.6Mhz if not writing to hub ram and 1.31mhz when writing to hub ram.

http://forums.parallax.com/showthread.php?p=617168

This is the body of the code:

'************************************************************
'* Reading an encoder the Skogsgurra and Chip Gracey way    *
'************************************************************
                        
entry                   mov   combined, #0
                        mov   p, par
                        mov   pinmask,#3           ' Create pinmask
                        shl   pinmask,_pin                                                  
                                                
:loop                   mov   look, lookyup        ' load look up table
                        mov   state, ina           ' Read inputs
                        and   state, pinmask       ' Mask
                        shr   state, _pin           ' shift into bits 0 and 1              
                        shl   combined,#2          ' Shift old bits left
                        or    combined,state       ' combine to provide 4 bit word
                        and   combined,#15         ' mask off really old bits
                        mov   shift,combined       ' Make ready to use as index 
                        shl   shift,#1             ' Shift to multiply by two
                        shl   look,shift           ' Use to shift look up table bits to bits 30,31                                       
                        sar   look,#30             ' Shift to bits 0 and 1 keeping the sign                        
                        
                        adds  count,look           ' Add the result to the count

                        wrlong count,p           '          
                        jmp   #:loop 

count                   long    0
combined                long    0
pinmask                 long    0

'                                 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
lookyup                 long    %00_01_11_00_11_00_00_01_01_00_00_11_00_11_01_00
_pin                    long    0  

state                   res     1
look                    res     1
shift                   res     1
p                       res     1

Find attached a version with a demo program. Obviously you would want to alter this for waitencoder type operation.

Graham

TheOutfield

Thanks for the suggestions. If you can handle 1.3Mhz to hub ram this means that another cog could also read cog ram at this rate. That would give me about 1uS resolution from another cog reading hub ram after the angle is updated.

How many reads from hub ram can each cog execute per access?

I'm going to give this a shot when I get my demo boards shipped.

Graham Stabler

One read per access.

An even faster way to signal between two cogs is an IO pin, one has it as an output the other an input.

Graham

TheOutfield

Graham,

That is a great idea.· Taking your idea to the next logical step.··I'm not going to be using all of the IO pins·so I could use 10 of them to act as a register.· This would give me a·range of 0 to 1023 the same as the·encoder.· The encoder tracking Cog would write to these 10 bits and the other Cogs would simply read it.· This should bring me to sub uS resolution.

Cheers.

Graham Stabler

I assume you are not rotating the encoder more than a full turn?

Graham

TheOutfield

Correct, I am only interested in an angular position from 0-360 even though the engine is continuously rotating. I'm not really concerned with how many times it rotated.

Graham Stabler

Should work a treat then, you will have to keep the accumulator within 10bits and ensure that the encoder turns in the positive direction.

I assume this is for some sort of ignition timing then?

Graham

TheOutfield

Graham,

You've got it. I'm hoping this will work out. It provides a low cost alternative to the TPU in the Freescale microcontrollers. And a much quicker way to experiment. I've been looking at using an Xilinx FPGA with a bunch of PicoBlaze processors but the solution would be very similar to what the Propeller provides and cheaper as well. If this works the debugging should be much simpler. The only other thing I'll need to setup is a link to another micro or a PC which will schedule the pulses.

Graham Stabler

Why must another micro schedule the pulses?

OK I get what you mean, set it up. Could just add TV and keyboard out.

Graham

Post Edited (Graham Stabler) : 10/15/2007 9:23:45 PM GMT

Harley

TheOutfield,

FYI, there are several debuggers. One is PASD which resides on the Prop and uses the USB (for example, the PropPlug programmer device) i'f to one's PC for control/display.

And as a DSO/logic analyzer there's ViewPort; 32 channels and at least down to 50 nsec sampling resolution.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

evanh

TheOutfield said...
I'm not going to be using all of the IO pins so I could use 10 of them to act as a register. This would give me a range of 0 to 1023 the same as the encoder. The encoder tracking Cog would write to these 10 bits and the other Cogs would simply read it. This should bring me to sub uS resolution.

You can go to 4096 steps (12 bit) if you fully decode the quadrants.

On another note: Be careful with the I/O pins, I don't know what the timing is like on clocking out and in for the Cogs, but there may exist the possibility of miss-reading the value of binary numbers even though they are coming from the same synchronous clock. Might want to get Chip to comment on whether it's safe to do this or whether you should be using Gray code.

Graham Stabler

it's fine

evanh

I wouldn't mind a pointer to a page number on the I/O propagation timings.
I found a hint on page 28 of datasheet saying 1.5ns plus heaps more for unknowns ...
Then there is the question of pipelining or at least which tick of the instruction is used for both the inputs and outputs and alignment of the instructions in the various Cogs ...