• State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 22 subscribers
  • Views 2527 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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.

Parents
  • 0 in reply to HansBernhard Broeker

    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.

Reply
  • 0 in reply to HansBernhard Broeker

    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.

Children
  • 0 in reply to Paul Blase

    "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...

  • 0 in reply to Paul Blase

    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 ;-)