overwrite the hub manager

Landry

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

deSilva

@Landry,

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

Landry

Hi DaSilva,

Thanks for the reply. I'm not quite sure where to insert the command line you gave me

CON
  _CLKMODE = XTAL1 + PLL16X
  _XINFREQ = 5_000_000

  '_clkmode = xtal1 + pll8x
  '_xinfreq = 10_000_000

  'ZERO = 48
  'NINE = 57

  MAX_LENGTH = 400
  'DELIMITER = 13

  'PLUS = "+"
  'MINUS = "-"
  
  PIN_ENCODER_BOX_A = 3
  PIN_ENCODER_BOX_B = 4
  'PIN_ENCODER_BOX_I = 5
    
  'PIN_ENCODER_PP_A = 5
  'PIN_ENCODER_PP_B = 6
  'PIN_ENCODER_PP_I = 8

OBJ
  '_Numbers      : "Numbers"
  '_Keyboard     : "Keyboard"
  _Encoders     : "Quadrature Encoder"
  '_TV          : "PC_Text"
  '_TV           : "VGA_Text"
  _BS2          : "BS2_Functions"
  _Serial       : "Extended_FDSerial"
  
VAR
  byte _dataIn
  long _position        
                     
PUB Main | triggerPosition, invalid, triggerSign, input

  _BS2.start(31, 30)
  '_Keyboard.start(26, 27)
  _Serial.start(1, 0, 0, 9600)

  _Serial.str(string("Position calculator..."))  
 
  _Serial.SetDelimiter(" ")

  _Serial.str(string("Enter the trigger position value:"))
  repeat
    triggerPosition := _Serial.RxDec 
    if triggerPosition 
      _Serial.dec(triggerPosition)
      quit
    
  'Encoder   
  _Encoders.start(PIN_ENCODER_BOX_A, 1, 1, @_position)
  repeat
    if _position[noparse][[/noparse]0] == triggerPosition 
      _BS2.PULSOUT(6, 500)

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

deSilva

The program looks a little bit different than what I read from your first description.

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...

hippy

@ Landry : The 80us delay is simply the time it takes to process the Spin commands to do what you want, those commands which run as a result of _Encoders.start() and within _BS2.PULSOUT().

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).