??? 03/18/10 18:04 Modified: 03/18/10 18:05 Read: times |
#174283 - making the specific general Responding to: ???'s previous message |
I see you, Per making the specific general
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. a second was used to put "immediacy" into perspective, the longest I have had for a non-critical display has been on the order of 50ms 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 hardwar no it can not "solve the problem", it will just replace some problems with others. 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. agreed, just there is a giant fear against distributed processing among many. Would Toyota have the problem if a small processor handled the gas pedal and nothing else Multiplexing several tasks in a processor means that you have synchronization and timing issues. Using multiple processors, you still have synchronization and timing issues. .. so far so good ... 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. for multiple processors it would be crazy not to have a common clock and a common reset. Different baudrates would not be a problem unless they "talked to each other via UART" and if that was the case, different baudrates would be a coding error. Going from one processor to two adds quite a lot of extra complexity. AND sometimes it simplifies enormously. 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. I find multiprocessors when properly implemented often have an advantage over multitasking. Erik |