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.

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. 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. 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.

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.

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.

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.

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.


The thing is - a robust solution will get them in sync even after their inputs have differed. "Sorry boys - we will now have to reastart our 500 processors because one processer lost sync..."


One single asynchronous signal used anywhere in the system only needs ps variance between the different listeners to send them out of sync.

And if all input signals are always synchronous and identical - throw out the processors and use logic chips. Or probably: Stop and consider if you are solving the wrong problem in the first place.