RTX51Tiny process restart

Next Thread | Thread List | Previous Thread Start a Thread | Settings

Details	Message
Read-Only Author Paul Blase Posted 13-Mar-2006 03:45 GMT Toolset C51	RTX51Tiny process restart Paul Blase Is there a recommended method for restarting an RTX51Tiny process in case of hoseup - something less drastic than restarting the entire processor (e.g. via a watchdog)? I have several interlocking processes that may lose synchronization, and want to be able to restart them as a last resort, say from a monitor process or long-duration timer interrupt.
Read-Only Author Hans-Bernhard Broeker Posted 13-Mar-2006 11:20 GMT Toolset C51	RE: RTX51Tiny process restart Hans-Bernhard Broeker You're asking for the impossible. It's basically the definition of a "hose-up" that nothing less drastic than a hardware watchdog bite will get you out of it, because everything else has been tied in the hose-up. You're effectively asking the wrong question. It's unimportant how you get out of a hose-up --- the trick is never to get into one.
Read-Only Author Paul Blase Posted 13-Mar-2006 14:56 GMT Toolset C51	RE: RTX51Tiny process restart Paul Blase Well, when you have multiple processors trying to communicate, sometimes things can go askew. For instance, I have an embedded system trying to talk to a host system over an RF link. It is possible that the host can drop off in the middle of a tranmission, in which case I have to reset the protocols and go back to waiting for contact initiation. I could put tests into every point where I wait for a reply (basically where the interchange handler sends something and then calls os_switch_task while it's waiting for a reply) or I could just set a long duration (say 10 second) timer and have the timer ISR reset the protocol handler.
Read-Only Author A.W. Neil Posted 13-Mar-2006 16:48 GMT Toolset C51	... the trick is never to get into one! A.W. Neil "Well, when you have multiple processors trying to communicate, sometimes things can go askew." This is precisely why protocol stacks are expensive! It has been said that only, say, 10% of the development work goes into handling the case where everything goes right - the other 95% goes into handling all the possible failure conditions! "I could put tests into every point where I wait for a reply" There is no "could" about it - you must have those tests! "or I could just set a long duration (say 10 second) timer and have the timer ISR reset the protocol handler" Well, if you're happy that your comms keeps locking up for 10s at a time...
Read-Only Author Hans-Bernhard Broeker Posted 13-Mar-2006 19:39 GMT Toolset C51	RE: RTX51Tiny process restart Hans-Bernhard Broeker It is possible that the host can drop off in the middle of a tranmission, in which case I have to reset the protocols and go back to waiting for contact initiation. Well, that's not a hose-up. That's just a plain vanilla protocol time-out. How exactly that has to be handled depends on the details of the protocol, and potentially on the reasons for the time-out. Other than that, the only possible comment is that well, all the trivial things have long since been done by others, so guess what's left for you ;-)
Read-Only Author Reinhard Keil Posted 15-Mar-2006 07:42 GMT Toolset C51	RE: RTX51Tiny process restart Reinhard Keil See: http://www.keil.com/support/docs/307.htm

Next Thread | Thread List | Previous Thread Start a Thread | Settings