overwrite the hub manager
Hi,
I wrote a small program in spin using two cogs, one is there for reading the encoder (Quadrature encoders) and the other one retrieves the position and compare it to a given value input by a user. In case they are equal, a pulse is generated using the BS2_Functions object. Using an oscilloscope, i can check that every thing is working.
My problem is that i constantly have a delay of 80 microseconds between reading the encoder position and generating the pulse.
I think that this delay might be due to the fact that un the round Robin, all the eight processor are taking turns.
In order for me to lower the delay, I would like to know if it possible to overwrite the hub manager in such a way that instead of 8 processors it does the same work with the number of processors that I'm currently using. If yes, I would I do it?
Thanks,
Landry
I wrote a small program in spin using two cogs, one is there for reading the encoder (Quadrature encoders) and the other one retrieves the position and compare it to a given value input by a user. In case they are equal, a pulse is generated using the BS2_Functions object. Using an oscilloscope, i can check that every thing is working.
My problem is that i constantly have a delay of 80 microseconds between reading the encoder position and generating the pulse.
I think that this delay might be due to the fact that un the round Robin, all the eight processor are taking turns.
In order for me to lower the delay, I would like to know if it possible to overwrite the hub manager in such a way that instead of 8 processors it does the same work with the number of processors that I'm currently using. If yes, I would I do it?
Thanks,
Landry
Comments
you have a funny view of the Propeller world....
The HUB manager is a part of the fastest hardware possible...The worst schedule time between two COGs is 100ns.
But this has nothing to do with the internal working inside each COG. They work all absolutely in parallel!
The delay 80µs you observe is the time delay between the two COGNEW instructions you issue.
You can easily compensate for it by setting a future timemark ( = CNT + CLKFREQ/100) for both COGS and let them wait upto this before they start their (synchronized) work-
---
Edit: rearranged some lines..
Post Edited (deSilva) : 3/10/2008 9:40:05 AM GMT
Thanks for the reply. I'm not quite sure where to insert the command line you gave me
I don't specifically call the COGNEW myself. I know that I have two of them because, my program runs on one and the encoders starts a new in the its start function,
I you can tell me how where I can integrate the instruction you gave, that would be nice.
Thanks
Landry
You are mainly using "building blocks", and I should recommend you stay with this, and not try to tinker with them.
The "theory of operation" of your program is fully asynchronious: You have a free running loop which outputs the pulse. This loop is quite slow; I should think it would take 40µs at least (and more when it triggers), so there is not any chance to come closer to any other event.
I have not looked into the encoder module, so I do not know how fast this works, but iz should be able to update the _position each µs if it is an assembly program.
I see two ways forward:
(1) Include the pulse in the encoder module - this will be very precise then!
(2) Write a small assembly program with just the three last lines of your program translated to machine code. This is basically the same as (1) but does not require a modification of running software...
You can as deSilva says optimise that code so it runs faster, by moving code from one place to another and simplifying the code or rewriting it in Assembler (PASM).