??? 03/18/10 14:10 Read: times |
#174273 - Special cases are special. General cases quite common. Responding to: ???'s previous message |
If the display is delayed a second, but happens to be a clock showing a running lock for a 100m race, a lot of people would mind a 1s delay. And a display that takes 1s to show an update after a keypress is very, very frustrating.
Next thing - having a tiny 8051 do many things semi-concurrently can result in a very complex application. Having a general-purpose processor with individual threads can solve the problem by having each task run stand-alone without addition of extra hardware. Always, when working with microcontrollers, it is important to keep an eye on all interrupt handlers - good use of interrupt handlers can help a lot when splitting the individual tasks in real-time critical and background jobs. With some good planning, a lot can be done with a single 8051 without too much sw complexity. Different problems have different solutions. But throwing more hardware on the problem is not a good general decision. It is something that should be done only when it is very obvious that there are very clear advantages and it is very clear that the advantages wins over then disadvantages. You may decide to run one processor for every 30000 LEDs in a display. Then it is obvious that implementing a 300,000 LED display you need more processors and some solution to keep them synchronized. But that is not a generally applicable solution to other problems. Multiplexing several tasks in a processor means that you have synchronization and timing issues. Using multiple processors, you still have synchronization and timing issues. But now you also have issues with the individual processors waking up from reset at different times. Or running with different baudrate (if using RC-based clock) or one processor being rebooted without the other processors being rebooted. Going from one processor to two adds quite a lot of extra complexity. Going from 6 to 7 processors adds very little additional complexity. Going from a single "state+graph master" to a two-processor "state master" and "graph master" does add quite a lot of extra complexity. And depending on what the state master has to do, and what the graph master has to do, it isn't obvious that the graph master gains something by not being a state master since it still needs state info to know what graph to draw. So in the end - there are situations for hw distribution. But in the general case it is normally easier to share data in RAM than to required two-port memory, serial links etc together with multiple processors. |