| ??? 10/09/09 23:34 Read: times |
#169605 - MCU is a component, not a computer system. Responding to: ???'s previous message |
Per Westermark said:
That is a completely different issue.
In this thread, you are arguing that the processors need to run from the same crystal etc to tick instructions at identical speed. That is a borked design from the start. And it is also a ridiculous suggestion for a thread where the OP has only indicated that he has a PC and two microcontrollers and in some way wants them to exchange information. That's one sticking point. He hasn't said that clearly at all! What he did say is that he wants to send them a start command from a PC. Now, until he expands on his "requirement" to include whatever communication there is to be between the two MCU's, specifically, how he intends to effect the communication (UART, parallel, bit-banged serial, etc.) there's really not much to go on. But the next thing is that counting clock cycles is hardly ever needed for this type of problem. With a sound design, you can ignore the relative speed of the processors as long as they have enough safety margin. [/quote}
Who's said anything about counting clock cycles? If the RESET is synchronously timed and triggered from a single source, that being the same source that clocks the MCU, the two MCU's will remain in sync until external stimuli cause one or the other to change phase. All processors waits until they receive the command. Whatever speed they had, they will still manage to pick up the last character in the message within a very short time interval since they can - if needed - deactivate lower priority tasks (including deactivating other interrupt sources) when they see the start of a message. Depending on processor, you could start them from random state and get them to pick up the last byte within maybe one or two machine cycles from each other. It depends on what you mean by very short. I'm thinking in terms of femtoseconds, while you're thinking in terms of tens of milliseconds. Synchronization can mean only one thing, and that's that they're EXACTLY the same. If the computation step is then 100us, the precision of the oscillator will only matter for the computation step. After handling a message, the processor can resynchronize again with next message. Maybe, but nobody said it could vary that much. Many of my recent code sets (for a microsequencer, not 805x) execute in their entirety in well under 100 us since they have only a 4 ns cycle and only an 8-bit PC. 100 microseconds is a VERY long time in some contexts. This way, it will be trivial to have 1000 processors synchronize with received data and perform an action in better than 1us with standard components and fully distributed oscillators. And if one processor for some reason gets noise on the input or restarts, it can directly lock into the next message again.
Since the OP has never really told hes needs, there would be no reason to ever consider how to design a system when needing ns or ps resolution. It is way more likely that ms response times is fine. My point in bringing the synchronization issue up in the first place was the the O/P hadn't made much sense with his synchronization requirement. Perhaps it's "good enough" to call someone at the second location and have them push the reset button. Perhaps half an hour is close enough. I doubt it, based on what O/P has said. Don't relive old problems based on whatever technical limitations you may have suffered 20 years ago. Lock-step is a relative term very much depending on the relation between processor speed, amount of work to do, and allowed jitter. Those technical limitations still exist. Synchronization must be absolute in some cases, and a few ps here and there aren't tolerated at all. Jitter isn't tolerated either. But the situation is that any design should be implemented in a way that it is robust and self-synchronizing. Counting clock cycles since release of reset is an extremely bad way to run processors in lock-step. If they really need to run the program machine cycle for machine cycle in sequence, then you should most probably throw out the processors. It sounds more like a problem you could solve with discrete logic and lookup memory. It's seldom necessary to have true synchronization, but when necessary, it must be precise. A millisecond is seldom close enough. While I have never had Pentagon require me to control 500 MCU in lock-step, I have on a number of occasions had multiple processors run serial interfaces where the individual processors has one-bit or one-byte slots to pick up or emit data at quite high data speeds and where the individual processors are hot-plugged into the cable. That obviously does not allow the synchronization to be based on concurrent release of the reset signal.
You are mentioning the space shuttle. Are you claiming that the space shuttle would do something as stupid as ticking machines cycles in sync? It is not uncommon to have multiple redundant systems for fault tolerance, but normally done with each system having a suitable percentage of excess capacity and the system self-clocking to get the individual modules to keep the pace. And in 99.99% of all cases, this can be done with simple programs and simple off-the-shelf components as long as no PC-class OS gets involved. For most situations, you might even manage well with RC oscillators. Richard said:
[...] number of MCU's will be in exact lock-step, so long as their inputs and code are exactly the same, again, based on that same timebase. The thing is - a robust solution will get them in sync even after their inputs have differed. "Sorry boys - we will now have to restart our 500 processors because one processer lost sync..." That would have been no problem at all. However, it was clear within less than half a minute that the system under test had failed that particular test. Restarting was entirely automatic, and rerunning the test was only a matter of restarting the system under test, waiting for it to signal to all the MCU's that it was "ready" and then having the master processor tell it to "go." Richard said:
Your assertion that, "It is 100% impossible to guarantee that you can run two processors in lock-step."
is totally off-base, as a microcontroller is merely a piece of synchronous hardware. Given exactly the same clock, exactly the same code, and exactly the same external stimuli, if two of them don't behave in exactly the same way, it's reasonable to conclude that one of them is broken. Naturally, the external outputs will vary to the extent to which they're specified, but no more. One single asynchronous signal used anywhere in the system only needs ps variance between the different listeners to send them out of sync. That's why clock and other critical signals are distributed with carefully routed and meticulously driven and terminated coax cable of precisely controlled length. All they had to do was to start simultaneously. Once that was done, they could free-run ... for only half a minute, as it turns out, but anyway ... And if all input signals are always synchronous and identical - throw out the processors and use logic chips. The MCU is a logic chip! Or probably: Stop and consider if you are solving the wrong problem in the first place. Fact is, we've no idea what the problem is. The only thing he made clear is that he wants 'em to start at exactly the same time. That's what those 512 single-chippers did back in '86. All they had to do was to wait for an interrupt and then regurgitate a script. That's why the absolute synchronization was necessary. It was a response to a questionable requirement, but that's what the Pentagon specified. It made my employer happy, as there was lots of labor and little complex hardware. Mostly racks and patch panels, and many man-hours moving cables from one rack to the other. RE |
