From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f849b,167419cb5887cd4c,start X-Google-Attributes: gidf849b,public X-Google-Thread: 115aec,5495dac456fa22ef X-Google-Attributes: gid115aec,public X-Google-Thread: 103376,5495dac456fa22ef X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Processor Synchronization Date: 1999/01/20 Message-ID: <36A602E0.DA6E298F@pwfl.com>#1/1 X-Deja-AN: 434854983 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <36A509DB.95F62C0B@pwfl.com> <36A51F3A.2207F91@west.raytheon.com> To: Ken Keys Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada,comp.realtime,comp.arch.embedded Date: 1999-01-20T00:00:00+00:00 List-Id: Ken Keys wrote: > > How did you do it when did it in-house? Did you use an RTC or some other > common (hardware) time reference? > We have a cross channel sync discrete that enables the two processors to signal each other. Each processor has a watchdog timer that ticks off 1ms interrupts to drive the software and the wdt outputs a synchronization signal at 12.5ms intervals (programmable, of course, but this is what we use.) The wdt has a restart feature used for synchronization. So it becomes a matter of each channel looking at the other guy via the discrete to determine when he is in his 12.5ms frame and agreeing on who will reset so that they are both in the same frame at the same time. That gets you into coarse sync. From there, you've got to execute small delays with a real time counter so that both channels are at the leading edge of the 12.5ms signal at the same time. Then you've declared you are "in sync" and the system initialization can continue on to control active mode. Periodically in the course of operation, you've got to make fine tuning adjustments to keep yourself in fine sync. This is again a matter of both channels signaling each other via the sync discretes. What I am curious about is if anybody has done any study of algorithms for this sort of synchronization. I imagine there are methods of doing synchronization by sharing opinions about what time it is or with other sorts of semaphore setups and so on. (I know in the radio business you've got to account for propogation delays and other problems if you want the radios to sync up. Someone might have some studies of this sort as well.) What I'm hoping to do is explain to my class what it is that we do now for this sort of channel synchronization and then present some alternatives which might be used in future designs. Would we be better off if we got our hardware built with a time-of-day clock and traded opinions on what time it is? Are there other algorithms that work better at getting things in sync faster and keeping them in sync with less waste of CPU time? (delays are bad news when you're running real slow processors and have a 1ms cycle time!) In other words, is someone out there more clever than ourselves? If you know of any references or sources of information, I'd appreciate hearing about them. Thanks. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 Ph: 561.796.8997 Fx: 561.796.4669 ***To reply, remove "bogon" from the domain name.*** "Airplanes are interesting toys but of no military value." -- Marechal Ferdinand Foch, Professor of Strategy, Ecole Superieure de Guerre.