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've have to return in a specified point where a funcion call is executed.
Let me point out that for someone who's still quite new to the whole field of embedded SW, you hold some awfully firm beliefs about how you "have to" do things. That doesn't feel right.
And no, you almost certainly (a) don't have to do that, nor (b) should be be trying to at this point on your learning curve. Stick to simpler designs until you really know what you're doing.
And no, you almost certainly ... should [not] be be trying to at this point on your learning curve.
I would say this has nothing to do with the "point on your learning curve". I know of no technique that can do this safely, at least in C. I can visualize some "monkey code" in assembler that might make it 'work' in a non-mainatinable way.
Erik
So I should implement a context switch to a specified point in assembly and add it to the c code? In the assembly code I should save the state in the specific point where I want to retur if specific messagge is received. Then if the messagge arrives I should Pop the stack with the saved information for the state where the interrupt wants to come back and load the state saved and set the program counter to the address of the saved state? Does This work and recover main from hangs? Don't care about the manteinment and portability of the code.
So I should implement a context switch to a specified point in assembly and add it to the c code?
No, you shouldn't. And I find it really hard to see how you arrived at that conclusion from the advice you've been given here. It's a Bad Idea(no TM).
You appear to be going at this from entirely the wrong angle. The cure you're trying so very hard to administer is almost certainly worse than the possible problem you're worried about. It's quite possible that this crazy technique not only won't help if main is unstable, but it's actually going to make it unstable.
I understood all of your suggesttions and i'm gratefull to all. However my supervisor insist to force me to the inyours opinions bad solution... So i'll have meeting with it tomorrow where I can spek with it about other possible solutions... Thanks to all Matteo
10 tips.
1 state machine. 2 state machine 3 state machine 4 state machine 5 state machine 6 state machine 7 state machine 8 state machine 9 state machine 10 stat machine
The loop running the state machine steps will not hang unless you introduce bugs or the hardware suffers problems.
Long tasks can be splitted into multiple steps, making them breakable before they are fully done.
Task switches are for running multiple jobs concurrently - most environments cant survive that you kill/restart at arbitrary place becauce of atomicity reasons.
If you still manage to.hang your main loop, then you have no real option but a (watchdog) reset. The reason is that you have then managed to put the processor in a state where it can't be trusted.
The choice is yours. Solving a problem the established way, or assume your problem is unique and implement a spaghetti failure you will spend the next couple of years trying to get reliable.
View all questions in Keil forum