I'm quite new to context switch and embedded software development. I'm developing a standalone application (no OS) with aduc7026 and keil uVision3. My problem is that at the end of an uart messagge, which I must receive by interrupt, depending on the content of the messagge I've to return return in main in the state saved before entering in the ISR or I've have to return in a specified point where a funcion call is executed.
Hoping that I've been clear. Does anyone have suggestions?
Thank ìs in advance,
Matteo
I try to explain better. When i receive a messagge i must restart from a specifc pOint since the messagge work like a reset command but due tO strict time requirements i can not perform a reset.
So you should then use a state machine. Let the states represent the task at hand. And when you receive commands, you can decide if the commands should be queued (or may even be processed instantly) or if the received command should place the state machine back into an initial state again.
There just is no reason for trying to jump to absolute positions in the code. It is just an example of "I have a problem and want to run on the first idea I get even if it is a bad - or even nonworking - idea.
I agree with the others: this sounds like an awful way to structure a program.
I understand that it isn't the best way to structure a program but using state machine what happens if the main loop hang?
Thanks to all for the useful messages and suggestions.
but using state machine what happens if the main loop hang?
If understand this correctly, your main loop is too slow to ensure a fast enough response to a message. Use interrupts then. Structure the fast message handler as an ISR and trigger the corresponding interrupt when you receive the message. Assign interrupt priorities accordingly.
"If understand this correctly, your main loop is too slow to ensure a fast enough response to a message. "
The problem isn't the speed but the fact that receving a messagge is more important than executing other task.
" Use interrupts then. Structure the fast message handler as an ISR and trigger the corresponding interrupt when you receive the message. Assign interrupt priorities accordingly. "
This is a nice solution, however doesn't meet the requirements to restart from that function because after the interrupt the execution restart from the point where the code was executing...
This is a nice solution, however doesn't meet the requirements to restart from that function because after the interrupt the execution restart from the point where the code was executing.
If you have this kind of a problem, then your program is a mess already. Adding another layer of mess might make it work, but the whole thing won't be pretty. A clean rewrite is not an option, is it?
This is a nice solution, however doesn't meet the requirements to restart from that function because after the interrupt the execution restart from the point where the code was executing... yes, it does for ONE instruction and then it executes "the fast message handler as an ISR "
Erik