Sharing an arry of memory between gogs - Locks and confusion......

pacman

I _know_ this has been asked a few times, so I'm really sorry to ask it again... I have searched {numerous ways}, consulted the manual, and the 'Propeller bible' but I still can't find the answer, please someone help me....


two distinct areas of memory, each of about 5 longs. Lets call them FRED and BILL. Ideally they are arrays

Cog 1 reads FRED and takes action based on some of the values in FRED. Whilst doing this action Cog 1 updates BILL. When action is completed BILL is updated again.

Cog 2 deals with serial communications {Modbus RTU} and [noparse][[/noparse]if it gets a well formed massage] will write to FRED and will 'present' BILL to the outside world.


I'm getting all sorts of 'wrong' when I try to figure it out.... Is there a project (snippets of code?) that someone would like to share that shows me how to do this sort of thing, using semaphores properly?

I shan't post my code as it's very broken at this stage and you'd only laugh. ..(or spend way too long correcting it - show me a good example and I'll try to figure it out)


thanks heaps in advance.

Paul

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
=================
The future is in our hands.
Which way to the future?
=================

pullmoll

pacman said...
I _know_ this has been asked a few times, so I'm really sorry to ask it again... I have searched {numerous ways}, consulted the manual, and the 'Propeller bible' but I still can't find the answer, please someone help me....


two distinct areas of memory, each of about 5 longs. Lets call them FRED and BILL. Ideally they are arrays

Cog 1 reads FRED and takes action based on some of the values in FRED. Whilst doing this action Cog 1 updates BILL. When action is completed BILL is updated again.

Cog 2 deals with serial communications {Modbus RTU} and [noparse][[/noparse]if it gets a well formed massage] will write to FRED and will 'present' BILL to the outside world.


I'm getting all sorts of 'wrong' when I try to figure it out.... Is there a project (snippets of code?) that someone would like to share that shows me how to do this sort of thing, using semaphores properly?

I shan't post my code as it's very broken at this stage and you'd only laugh. ..(or spend way too long correcting it - show me a good example and I'll try to figure it out)


thanks heaps in advance.

Paul

FWIW I haven't seen anyone make use of the LOCKxxx opcodes. Most drivers rely on a single long in the hub RAM to act as the initiator of some action. Most of the times this is called "xyz_command" and the convention is that it can only be written when zero, and will be cleared to zero by the driver once the action is done. Of course this will only work in non-concurrent access to a driver. As soon as two cogs attempt to talk to the same driver, you would have to use the locking mechanism so exclusive access could be granted.

I have read the manual section on the LOCKxxx opcodes and must admit that I did not yet fully understand them, sorry.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.

MagIO2

Pullmoll's right. In your case you don't need locks, you only need to properly sync the two COGs.

1. Let's say COG 1 watches FRED[noparse][[/noparse]0]. If it contains 0 COG 1 simply waits. (This is how COG 1 is synced with COG 2)
2. COG 2 receives some data and writes it to FRED[noparse][[/noparse]1...x]. When all data which is needed by COG 1 is in place COG 2 sets FRED[noparse][[/noparse]0] to a value different from 0.
3. COG 1 detects this and starts working. For example it updates BILL. The last action of COG 1 is updating FRED[noparse][[/noparse]0] to 0 again and then continues with step·1 (wait)
4. In this time COG 2 can do other things or wait until FRED[noparse][[/noparse]0] becomes 0 again.·If it's·0·COG 2 knows that the BILL is ready to be send. (This is how COG 2 is synced with COG 1) Then COG 2 can go back to step 2 and feed COG 1 with new data.

A lock is needed, if for example 2 or more COGs want to use the same object. For example you have 1 COG receiving data from sensor 1 and 1 COG for receiving data from sensor 2. Both want to use the same serial interface to send the result to a terminal. Here you have to use locks.

In your case ... if 2 COGs want to use COG 1. Then you need to use a lock, so that not both start writing into FRED[noparse][[/noparse]1..x].

Wurlitzer

I use circular queues for this and have never lost any data. I just make sure the queue is large enough to allow for the free flow of data entering (write) while other processes are reading. In fact, because I pay attention to the processing time of the reading cogs, the cog entering data into the queue never bothers to see if the queue has been read but simply writes the new data then updates the Head pointer.

To do this you must take the worse case scenario of nonstop data entering a cog plus the data write times and updating the Head pointer and the longest time for another cog/cogs to read from the queue. In this manner, the cog handling the serial input never tries to pause the serial data stream. As long as you can always read the hub faster than you can possibly write to the hub the queue will never overflow.

Bill Henning

I use locks in my Morpheus video drivers - had to, to coordinate access to xmm reasonably efficiently between frame buffer burst reads and random access to the xmm by the graphics library and user programs.

' wait to obtain lock before using shared resource

llp      lockset mylock wc  ' loop until we have exclusive access
  if_c  jmp   #llp

        ' code accessing shared resource goes here

        lockclr mylock

' sometime later in the cog
        
mylock  long 0 ' can be between 0-7

Above code works great.

pullmoll said...

pacman said...
I _know_ this has been asked a few times, so I'm really sorry to ask it again... I have searched {numerous ways}, consulted the manual, and the 'Propeller bible' but I still can't find the answer, please someone help me....


two distinct areas of memory, each of about 5 longs. Lets call them FRED and BILL. Ideally they are arrays

Cog 1 reads FRED and takes action based on some of the values in FRED. Whilst doing this action Cog 1 updates BILL. When action is completed BILL is updated again.

Cog 2 deals with serial communications {Modbus RTU} and [noparse][[/noparse]if it gets a well formed massage] will write to FRED and will 'present' BILL to the outside world.


I'm getting all sorts of 'wrong' when I try to figure it out.... Is there a project (snippets of code?) that someone would like to share that shows me how to do this sort of thing, using semaphores properly?

I shan't post my code as it's very broken at this stage and you'd only laugh. ..(or spend way too long correcting it - show me a good example and I'll try to figure it out)


thanks heaps in advance.

Paul

FWIW I haven't seen anyone make use of the LOCKxxx opcodes. Most drivers rely on a single long in the hub RAM to act as the initiator of some action. Most of the times this is called "xyz_command" and the convention is that it can only be written when zero, and will be cleared to zero by the driver once the action is done. Of course this will only work in non-concurrent access to a driver. As soon as two cogs attempt to talk to the same driver, you would have to use the locking mechanism so exclusive access could be granted.

I have read the manual section on the LOCKxxx opcodes and must admit that I did not yet fully understand them, sorry.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system