Retreiving Variable Values from other Cogs

Harrisracing · 2011-07-10 12:49

Well I finally made my jump from BS2 to propeller. This was a HUGE jump for a mechanical engineer with very limited programming education. BS2 was intuitively "easy" to learn especially with the online labs and ease of "linear programming" but for my end project I know that I will need the Propeller's capabilities.

So, I started with the labs, learned about objects, methods, cogs, etc. and moved towards making my "test stand" for my next project.

My end goal project is to make a programmable fuel-injection computer for my racing go kart engine (4-stroke, 9000 rpm redline). I have done the math and the propeller is a great piece of hardware as far as running what I need for this and I do believe it will be capable of running Fuel, Ignition and datalogging as I get it going. I started by creating different objects to interface with different sensors and so far have been able to get the following components working:

RCTIME - I am using a 10k Pot to find decay time and returning value to my 4x20 LCD screen

Melaxis Hall trigger - I have retrieved RPM data like a charm with this and also display on LCD

So I was using a battery, POT, and electric motor w/ pickup wheel completely separate for my hall to trigger off of to test it. But I decided that I would try to make a PWM command using the onboard L293D Half H bridge on the prop professional development board and drive my electric motor with it. Then I thought it would be easy to use RCTIME to get my POT value, then output this in a cog running a PWM to the L293D.

Well I managed to make the L293D PWM pretty dang well using the piece of code titled "main" below. It basically continuously pulses pin 4 on and off for certain amounts of time that is divided by duty cycle input (oscfreq was found to work well at 800 for my application).

PUB main
cognew (control, @stack)   'this is the RCTIME decay part of routine that doesn't feedback into main yet.

dira[4] :=1

outa[4] :=1                         'this is to "jump start" the electric motor at low duty cycles.
waitcnt(clkfreq/100 + cnt)

repeat
  duty := 10                   'input duty value here from 1-100%. Would like RCTIME result read here
  ontime := (duty * oscfreq) 
  outa[4] :=0
  waitcnt(clkfreq/ontime + cnt)
  waittime := ((100 - duty) * oscfreq)
  outa[4] :=1
  waitcnt(clkfreq/waittime + cnt)

PUB control

  DISPLAY.display
  
  repeat
    RC.start(5,1,@decaytime)
    waitcnt(clkfreq/10 + cnt)

    RC.stop
    waitcnt(clkfreq/100 + cnt)
    
    DISPLAY.displayval(decaytime)
    waitcnt(clkfreq/10 + cnt)

The "control" portion is where I am getting RCTIME value and returning it as decaytime and then displaying on an LCD screen. That part of it works great. While the motor is running the duty value I have typed in the code, I can change the pot and watch RCTIME change from 0 - 293 on the screen. I haven't, however, figured out how to return this 0-293 into the "duty" value in my code for the PWM.

I'm sure someone has some ideas. I'm so close to getting this to respond correctly!

Thank You,
Patrick Harris

Duane Degn · 2011-07-10 13:14

This should not be hard to solve.

It will be a lot easier if you use code blocks. Follow this link.

attachment.php?attachmentid=78421&d=1297987572

Either edit your original post or provide formated code in a new post. It will make it much easier to answer your question.

Duane

Harrisracing · 2011-07-10 13:33

Thank you for the advice. I was wondering how to do that!

Duane Degn · 2011-07-10 14:29

I think we (at least I do) need to see all of the code.

In the Propeller Tool select File | Archive | Project...

Then attach the zip file.

All global variables within an object should be available to all the Spin methods in that object even if the methods are running in a different cog.

Duane

Harrisracing · 2011-07-10 19:10

Any example.

Really I just need ANY example of one cog constantly running RCTIME and passing the value to another cog performing a function using this RCTIME value. A good example is reading RCTIME and making an LED stay "on" for that many milliseconds maybe.

In my example if I make "duty := decaytime" in my first repeat loop of my main program, I *should* be running my PWM with that decaytime as my modifier for my duty cycle. But as soon as I put it there the program hangs.

I have lots of pointers going everywhere with the way I put this code pointing to so many places, so I will clean it up first then post it.

Thanks,
Patrick

kuroneko · 2011-07-10 19:24

Admittedly it's not using RCTIME but it feeds something repeatedly into a global variable which is evaluated somewhere else. HTH

VAR
  long  storage
  long  stack[32]
  
PUB null

  cognew(feed, @stack{0})

  dira[16..23]~~
  repeat
    outa[16..23] := storage

PRI feed

  repeat
    storage := cnt + frqa++
    waitcnt(clkfreq + cnt)

DAT

In your case the feed method would have to run RCTIME and store the relevant value (possibly scaled) back into storage.

Mike G · 2011-07-10 19:36

Take a look at this too

CON
  _clkmode = xtal1 + pll16x     
  _xinfreq = 5_000_000

DAT
  value       byte    $00
  statusSemId byte    $FFFF

VAR
  long StackSpace[20]
    
OBJ
  pst           : "Parallax Serial Terminal"


PUB Main
  pst.Start(115_200)
  pause(200)

  statusSemId :=  locknew


  pst.str(string("Semi Id: "))
  pst.dec(statusSemId)
  pst.char(13)
  
  cognew(StatusMonitor, @StackSpace)
  pause(200)
  
  repeat
    repeat until not lockset(statusSemId)  
    value++
    lockclr(statusSemId)
    pause(1000)

PRI StatusMonitor | temp
  repeat
    ifnot(temp == value)
      repeat until not lockset(statusSemId)
      temp := value
      pst.str(string(13, "Value: "))
      pst.dec(value)
      lockclr(statusSemId)


PRI Pause(Duration)  
  waitcnt(((clkfreq / 1_000 * Duration - 3932) #> 381) + cnt)
  return

Harrisracing · 2011-07-10 20:00

GOT IT!

Thanks for the info. I think the problem was I was changing the decaytime to a string in my other object to send to the LCD display. You guys are right, variables are easily passable in this manner.

I will post my cleaned up code later.

Thank You,

Patrick

bozo · 2011-07-10 21:05

OK ... so, under what conditions is it preferable to pass the address of the shared variable when the cog is started,
and read or write to the variable using long[]/word[]/byte[] etc?

e.g. start the code in the new cog with cognew(cogName(@varName), @stack)
and manipulate it with something like:

PUB cogName(passedParam) | localVar
...
localVar := long[passedParam]
long[passedParam += 1
and so on ...

i suspect the answer is only when the code for the new cog sits in a separate object file ??

kuroneko · 2011-07-10 21:09

bozo wrote: »

i suspect the answer is only when the code for the new cog sits in a separate object file ??

Let's make that: the code can't access the relevant variable by name. Which is true for separate object files and also for e.g. local variables in the same file but different method.

Harrisracing · 2011-07-11 12:30

Thank You all so much.

Great advice here and two great examples of code back to back with the two methods to do what I needed to do. This was critical learning to getting my project up and running.

Patrick

courtens · 2011-11-30 17:12

Harrisracing wrote: »

GOT IT!
I will post my cleaned up code later
Patrick

do you still have that code? thank you

Retreiving Variable Values from other Cogs

Comments