??? 03/18/10 18:41 Read: times |
#174286 - well, specialisation means loss of generalisation :p Responding to: ???'s previous message |
If multiple processors are mounted on the same PCB, then it's natural that they are run from the same PSU and share the reset signal. Depending on processor type, they may share the same clock signal too.
If each processor is in it's own box, and you have a connection cable between the boxes, then it is porbably more common to have each box fully stand-alone. But another thing - if you have multiple processors on the same board, then you may do it for one of several reasons. - a processor is quite cheap, so you may settle for many I/O processors instead of having a single processor with external interface chips. - one processor hasn't enough computation capacity - one processor hasn't enough amount of data to store the full state information, and it isn't practical with an external serial FRAM or similar - one processor hasn't enough code space to store all required algorithms - the construction exists, and a processor can function as protocol converter and leave the original product unchanged. - ... If the problem is lack of CPU power, then you can often get a more powerful processor for a similar price as that underpowered processor - and for less money than you need to pay for two, three, four small processors. When connecting multiple processors in some form of cluster, the communication routes - bandwidth, addressing etc, are decided by the topology, unless you have a generic cross-bar switch in the middle. Having a single processor capable of running multiple tasks means that you can change the interprocess communications whenever you like - you have almost infinite data bandwidth, full addressing options including "multi-cast". Replacing the application can almost totally redesign the product, for solving a completely different problem. In the end, a well designed application can get a 8051 to do perform a huge amount of actions every second, despite the lack of address range, or limited amounts of RAM or pointer manipulation. Integration of instruction set and peripherials is quite good, so adding more processors tends to not scale so well unless the specific problem happens to be very pipelineable or where multiple processors can do the same job, but for different input data. But learning how to implement a program so that it can perform multiple semi-concurrent tasks while still having the code for each individual task be easy to read and maintain requires a bit of experience. Many students regularly post on this forum. "I have this code for a keyboard. It does work." "I have this code for a display. It does work." "How do I make them work together." The PC has a keyboard processor, so it is trivially easy to think - use one processor for the keyboard. The PC has a graphics processor, so it is trivially easy to think - use one processor for the display. But in the end, it is quite important to be able to analyze the interaction between different tasks, and see how the different task can be integrated efficiently and elegantly into a single processor. It can save money in lower component costs. It can give a smaller footprint. It can consume less power. It can allow easier redesign. For the general case, it's a question of analyzing the tasks at hand - how do they interact, and what resources do they need. For special cases, extra hardware may be advantageous but it really isn't one of the early steps when analyzing a problem. So in the end, we are still back at identifying the problem - what the reason is for 6 slaves * long distance to sensors? * each slave performs a lot of computation on sensor data? * the slaves are I/O expansions? * the slaves are protocol converters? * something else? - is the communication consuming significant amounts of processing power? - does the state master has to crunch a lot of data? - is the state info needed to send between state master and graphics master similarly sized as the info sent to the state master? - do the graphics master have to perform a lot of computations before deciding what to draw? - does outputting of display data consume a lot of CPU capacity that is needed for communication or computations? And |