Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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.

List of 25 messages in thread
TopicAuthorDate
Seperate display processor            01/01/70 00:00      
   Is the display the master?            01/01/70 00:00      
      Bottlenecks?            01/01/70 00:00      
         I disagree            01/01/70 00:00      
            Both            01/01/70 00:00      
               not necessarily            01/01/70 00:00      
                  Special cases are special. General cases quite common.            01/01/70 00:00      
                     making the specific general            01/01/70 00:00      
                        well, specialisation means loss of generalisation :p            01/01/70 00:00      
                           what is this            01/01/70 00:00      
                              And if it doesnt?            01/01/70 00:00      
                                 Seperate display processor            01/01/70 00:00      
                                    never seen a better reason            01/01/70 00:00      
                                       To Per            01/01/70 00:00      
                                          Did you read the first post in the thread?            01/01/70 00:00      
                                             an example, please ...            01/01/70 00:00      
                                                Divide-and-conquer requires reasonable split percentages            01/01/70 00:00      
                                             Seperate display processor            01/01/70 00:00      
   What kind of display?            01/01/70 00:00      
      Cross-reference            01/01/70 00:00      
         Seperate display processor            01/01/70 00:00      
            How does it work currently...            01/01/70 00:00      
               Seperate display processor            01/01/70 00:00      
            dirt cheap            01/01/70 00:00      
               Seperate display processor            01/01/70 00:00      

Back to Subject List