Angular Tracking with Encoder
TheOutfield
Posts: 7
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.
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.
Comments
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
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
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 1Find attached a version with a demo program. Obviously you would want to alter this for waitencoder type operation.
Graham
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.
An even faster way to signal between two cogs is an IO pin, one has it as an output the other an input.
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
I assume this is for some sort of ignition timing then?
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.
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
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
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.
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 ...