LOCKSET problem
dnaddor
Posts: 26
I have been troubleshooting an obscure problem where it looked like two cogs got the same resource at the same time. Two different cogs seemed to be adding to the same circular buffer at the same time. Locking seemed to work perfectly nearly all of the time, but once in a blue moon both cogs seemed to get the resource at the same time. I have finally reached the point of even considering the possibility that there could be bug in the chip. I know what you are thinking -- I'm thinking it too -- the bug has to be on my end. But the code is almost too simple to not work.
To lock, I was doing this:
lock1 lockset 1 wc
if_c jmp #lock1
and then clearing with this:
lockclr 1
No, I didn't forget the wc flag at the end.
To work around the problem, I abandoned LockSet and LockClr and instead did this:
Read a hub location. If not zero, keep reading until it is.
Write the cog's special number (1 for one cog and 2 for the other)
Read back the number written
If not what was expected, start over, otherwise the resource is granted and continue
This seemed to completely fix the problem. Now this is way less efficient, and perhaps introduces some kind of timing shift.
I was only using LOCKSET and LOCKCLR, not LOCKNEW and not LOCKRET. That's because the only object I use is the serial object and it doesn't use locks, and this application is for a closed vision system. I thought in a configuration like this, I can
choose any lock ID from 0 to 7 and use it consistently, right?
Has anyone seen any issues like this? If not, I will probably try to create the simplest test program which demonstrates the problem.
Thanks!
To lock, I was doing this:
lock1 lockset 1 wc
if_c jmp #lock1
and then clearing with this:
lockclr 1
No, I didn't forget the wc flag at the end.
To work around the problem, I abandoned LockSet and LockClr and instead did this:
Read a hub location. If not zero, keep reading until it is.
Write the cog's special number (1 for one cog and 2 for the other)
Read back the number written
If not what was expected, start over, otherwise the resource is granted and continue
This seemed to completely fix the problem. Now this is way less efficient, and perhaps introduces some kind of timing shift.
I was only using LOCKSET and LOCKCLR, not LOCKNEW and not LOCKRET. That's because the only object I use is the serial object and it doesn't use locks, and this application is for a closed vision system. I thought in a configuration like this, I can
choose any lock ID from 0 to 7 and use it consistently, right?
Has anyone seen any issues like this? If not, I will probably try to create the simplest test program which demonstrates the problem.
Thanks!
Comments
Also, you really should use locknew to automatically allocate a new lock instead of picking one yourself.
PUB Example '' NOTE: lockid only gets loaded into the cog if modified after cog launch. '' Modifying it after launching the cog will change the hub version/instance '' of the variable but not the cogram version lockid := locknew cognew(@entry, 0) DAT entry loop lockset lockid wc if_c jmp #loop 'do stuff lockclr lockid jmp #loop lockid long 0-0 ' the id of the lock used is stored here, set to real number by spin function Example var1 res 1 ' put your res's after the longs var2 res 1 etc res 1I'll bet that explains it. I'll try it -- thanks!