hc12,can i return from interrupt and jump elsewhere?

Hello from Milan ,Italy, i'm programming a 9s12 uC in C language,with occasional assembly inserts;

the question is:

a function myfunc() is runnin,and an external events calls an interrupt service routine,is it possible,once the interrupt did its job,to avoid to continue with my func() from the point where it was interruptd,and going back to main() instead?It is not important if i have to run another couple of line in myfunc().Important is that i can go out from it soon;

Can anyone suggest me the most elegant way? Once more forgive my English.

Many thanks, Diego.

Reply to
blisca
Loading thread data ...

If all you want is to restart your code, i.e. re-enter main from the start, then you can use a watchdog reset. Just stop toggleing your watchdog when you get your event. The watchdog will trigger, and restart your micro. If you want to resume a sepcific function on reception of an interrupt event, then this is less trivial. Unless you want to write your own RTOS, the simplest is to use either one of the many open source ones, or a commercial one.

formatting link
seem to have a port for your micro.

Regards Anton Erasmus

Reply to
Anton Erasmus

And if he is simple seeking to abort an operation setting a flag in the interrupt routine and checking it in the routine you are interrupting is fairly straightforward.

It seems an odd requirement. To the original poster, what is the effect you are trying to achieve? Tell us what you are trying to do rather than how you are proposing to do it. We might be able to suggest better approaches.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

That's an odd thing to do, and while you could probably do it one way or another it would be difficult to get all the bugs worked out.

Why exactly are you trying to do this strange thing? Perhaps there's a better way to achieve your higher-level goal than the method you're investigating -- let us know, and we may be able to suggest it.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

"blisca" vrote

to

instead?It

Ok,thanks again. I kept my question generic just because i thought that what i'm doing specifically is less interesting. .I'm trying to implement an USB protocol using a 9s12 microcontroller,that i call uC

formatting link

and a PDIUSBD12,a parallel to USB chip

formatting link

It is raccomended that anytime an USB device receives a bus reset it has to accomplish it,signalling by an interrupt to the uC,even at the price of letting loose what is remaining of the current function.then it should stay in an idle loop waiting for another request.

Well ,being honest it should be better if any request could wake the uC from idle loop by an interrupt,then once the specific request is decoded it has to be accomplished,but in case of another interrupt(and it could happen) if this comes from a bus reset(and once more the uC has to discover it by decoding)the current function has to be stopped.

I did the question in that way with the aim to keep it simpler,and to learn things step by step,and i'm aware that it should not be the best approach to the problem

Hoping that what i wrote about USB is correct and not misleading(please,correct me in this likely case) i wish you a nice Saturday night.

Diego

Reply to
blisca

OK, that makes sense but don't take interrupt too literally in this case. The key is that you want to stop the current function when a bus reset occurs. How you accomplish that is a design decision.

One way is I suggested and set a flag in the interrupt and watch it in your routine. Actually this sounds like a good place for a statechart implementation.

A second approach would be to use an RTOS and 'kill' the thread performing the function.

The biggest problem I see with the second approach and your originally proposed solution is that you could leave the hardware in an unknown state.

I have no idea if you have the USB requirement correct, but there will be others here who do.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

I think you're confusing USB functions with microprocessor functions. Unless _all_ you're doing is shuttling USB traffic around you don't want to flush the whole micro's state -- you just want to flush the USB state.

I'd look at how to do this gracefully. This is the sort of thing that cries out for a state machine, one implemented in a big switch statement and with a USB bus shutdown unconditionally forcing the machine's state to a 'reset' state no matter what it was before.

--
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html
Reply to
Tim Wescott

interrupt

avoid

you

is

effect

better

microcontroller,that i

formatting link

formatting link

has to

stay

from

has

if

learn

approach

Saturday

Many thanks again to you all for your hints and for being interested.

Why do you talk about the entire micro's state?I dont want to do a total reset,just like after a power on,i just want to return to the initial idle loop I figure that important data may be saved in global variabiles,having no need to keep tracks of the "message queue",as windows does. I say this keeping in mind that i'm a newbie compared to most of the people in this newsgroup.

Reply to
blisca

That is what your original post implied.

See Tim's comment below. That's what state charts and state machines allow you to do in a relatively straightforward fashion. Just make sure you break operations into small enough chunks to keep latency in respose to a bus reset low.

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

Many thanks to Anton Erasmus,Robert Adset and Tim Wescott. You gave me some useful hints,and lot of articles to download and read carefully.

Have a nice week you all.

Diego from somewhere in Italy between Milan and the Alps.

Reply to
blisca

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.