Shop OBEX P1 Docs P2 Docs Learn Events
Writing variables in a cog and reading it in another cog — Parallax Forums

Writing variables in a cog and reading it in another cog

Cats92Cats92 Posts: 149
edited 2007-07-09 08:35 in Propeller 1
Hello,
I meet problems with a program which reads data from 3 Sharp GP2DO2 IRdetectors and uses this data to modify servocommands.
Three variables (irdetectleft, irdetectright,irdetectfront) are used by 2 cogs : one cog reads the IRdetectors in a repeat loop , with a shiftin function and updates the 3 variables , the other cog reads this variables in another loop and modify servo commands accordingly.
This works well with 2 IR detectors (left and right) but when I add front , this Irdetector gives an irdetectfront value which remains 0 .
(each Irdetecor works well when tested alone and I used 2 different batteries : one for the propeller, one for motors and detectors. The cog is declared with a long stack3[noparse][[/noparse]50] var)
Is it a problem of concurrent read/write access to the 3 shared variables?
A problem of timing ? or electricity consumption ?
Beginning with Propeller, I dont understand well what to do when updating a variable in a cog and reading its value in another cog.
When is it usefull to lock ? and how to do it efficiently ?
Here is the program I use.
Thanks for help.
·

Comments

  • CardboardGuruCardboardGuru Posts: 443
    edited 2007-07-08 11:07
    Locks are for when you have a series of variables that are accessed/changed by more than one cog and must be kept as an atomic unit. Say you had a series of characters in a buffer, that change from "THE QUICK BROWN FOX JUMPED" to "OVER THE LAZY DOG". You'd use a lock to ensure that whilst one cog was changing the characters, another cog wouldn't read them as "OVER THE LAROWN FOX JUMPED".

    In your case, presumably your detector samples are independant. If they are read as 3 LONGs (or words or bytes) it doesn't matter if one has been updated to the latest sample but the other two are still on the previous sample. So you don't need a lock.

    Did you mean to attach your code?
  • Cats92Cats92 Posts: 149
    edited 2007-07-08 15:12
    My detectors values are in three long , i dont need to use a lock ?

    This time i try to join my code
  • CardboardGuruCardboardGuru Posts: 443
    edited 2007-07-08 15:50
    Your values are in bytes. But either way is OK. I see no reason why you'd need a lock. I'd look elsewhere for your problem.
  • Mike GreenMike Green Posts: 23,101
    edited 2007-07-08 15:53
    I don't think you need a lock. You have two cogs. One reads the sensors and sets the three variables and the other cog reads the three variables and does something with them. The only synchronization problem you can have is where some of the variables have been changed, but not all of them (the first cog is still reading the last sensor or is reading the second one, but is done with the first). This would cause your routine in the second cog to use some data that's not up to date, but that is not the problem you're seeing.

    I don't know why you are having problems with the 3rd sensor.
  • Cats92Cats92 Posts: 149
    edited 2007-07-08 20:44
    Thanks for this quick answers, it is now clear that my program dont need locking variables.
    It remains that with three detectectors the last read did not work , if i use only two of them they give good readings.
    Any idea about what may happen ?
  • John AbshierJohn Abshier Posts: 1,116
    edited 2007-07-09 01:50
    I have looked at you code and nothing stands out. Are you sure that IRfront is on pins 7,6? Does the front IR have a good power and ground? I would try a simpler program that just reads the front IR and sends the value to the debug screen.
  • Cats92Cats92 Posts: 149
    edited 2007-07-09 08:35
    You are right it is not the code.
    Finally I changed the pins for the third IR detector (put it on 9,8 instead of 7,6) and after that it works.
    Perhas a pin has some damage with a previous program or connection ?
    Thanks for your help
Sign In or Register to comment.