i am trying to synchronize 10 pics(PIC16F873) which send out data through InfraRed to 1 receiving pic. 10 pics are using the same oscalator( will cause problems?) ;
Different pic has to send out data in sequence. pic 1 sending out at time slot 1; pic 2 sending out at time slot 2;pic 3 sending out at time slot 3;pic 4 sending out at time slot 4;pic 5 sending out at time slot 5;............. A sending process takes about 30ms;.
The receiver has no way to send back signal to the sender, so the sender has to be well synchronized.
My way of doing this is each pic is started at the same time(connectted a same reset button; using the same oscalator). Each pic has timer running. It will interrupt every 50ms to check if it is time for him to send.
Main procedure of sender like this;
Intterrupt_processs(){
timeslot = (timeslot+1)%10;
if (it is my timeslot)
Send data;
}
Main(){
Set up interrpution every 50ms and enable interruption;
while(1);
}
But now the PROBLEM is it will work only for the first few seconds- up to 10 minutes(sometimes long, sometimes short). Then some pics seems to be restarting themselves and they are out of sync then after.
Any explanations? Suggestions? Thanks.
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
Posted: Wed Dec 29, 2004 1:02 pm
That should work fine as long as they all keep running. Is there any chance the common line with the reset button could be on a port pin so it could be used as a system sync line? For example unit #1 could pulse this line whenever he transmits so everyone knows what time it is. If unit #1 sees the line pulse and he didn't do it, it must have been the pesky humans using the pushbutton so he would cause an extra long pulse which makes everyone reset. _________________ The search for better is endless. Instead simply find very good and get the job done.
rnielsen
Joined: 23 Sep 2003 Posts: 852 Location: Utah
Posted: Wed Dec 29, 2004 3:31 pm
Have you thought about doing something like having an I2C bus and a Master controlling when each PIC will send it's data.
Master tells PIC 1 to send it's data.... PIC 1 sends data and then signals the Master that it's finished. Master tells PIC 2 to send it's data..... and so on.
This would compensate for anything that might get out of sync. You could have each PIC running from different oscillators if you needed. If one PIC died you could detect it with the Master and have it skip that PIC or signal that there is a problem.
Ronald
Smile, you're one day closer to retirement!
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
Posted: Wed Dec 29, 2004 5:19 pm
I2C looks good. This way you have 2 way communication and a way to tell when things are wrong/out of sync.
Another idea would be to do it with a master/slaves.
master uses the timer and on the timeslot it throws a pin low.
---Use a pull-up to keep the noise out. ---
This pin is tied to all other pics on an external int. ( if you have one)
Then in the slave pics the eternal interupt ISR is a state machine that just
counts up and rolls over.
master transmits on count==0
pic1 (slave) transmits on count==1
pic2 (slave) transmits on count==2
...
picN
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum