We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi, I want to implement following job in C code with Keil C51. (1) jump to a place (function entry) after an interrupt occurs. I know how to implement it in assemble, but I don't know how to implement it in C ? Following is the implementation in assemble, JUMP_HERE: CLR A ... ... Int1: MOV DPTR,#JUMP_HERE PUSH DPL PUSH DPH RETI Does following C code works ? void main() { while(1) { JUMP_HERE: func1(); ... } } void Int0_ISR (void) interrupt 0 using 1 { // C code here .... #pragma asm MOV DPTR,#JUMP_HERE PUSH DPL PUSH DPH #pragma endasm } I know you can only use the goto statement within same function in C. Any idea ? Thanks. Daniel
No, this is not possible in 'C'. Anyhow, why would you want to do such an unstructured thing?! Interrupts can be hard enough to debug anyway, without random jumps all over the code! The usual approach is: 1. The ISR recognises the interrupt, and sets some flag; 2. Code in the "main loop" recognises the flag, and takes the appropriate action. All without random jumps all over the code!
>1. The ISR recognises the interrupt, and sets >some flag; >2. Code in the "main loop" recognises the >flag, and takes the appropriate action. Hello, A (Andy ?),If my memory is correct. Yes, my code currently works this way. However, to achieve this, there are two requirements: (1) ISR must be short enough, if the egularly interrupt, such as timer interrupt interval is about 10ms, my oppion is ISR should not last over 2ms(20%), 8 ms (80%)leave to main loop. (2) The task(function) is not time critical, but unfortunately, this task is very time critical, you have to serve it within 3-5 ms, my main loop is pseudo-multitasking, some task(function) may be longer than 10ms or even more, if you use strcpy() it is even longer, So when the right function is called, the 3-5 ms is already elapsed. Then, there is another way, use ISR to process this task, however, this task may last one second (worst case), for ISR it is too long, this is why I try to use jump between functions, I am not sure whether this can be achieveable by mixing C and assembler, if not, the only choice is ISR, the cost is it may take about one second, that is trade-off! thanks
"I am not sure whether this can be achieveable by mixing C and assembler" Your basic problem is that labels in the 'C' programming language cannot have global scope; ie, they are never accessible from outside the function in which they are declared. This is defined by the language; nothing specifically to do with Keil - see a 'C' textbook. Therefore, you will have to implement both the ISR and the "target" of the jump in assembler. You might possibly be able to use setjmp and longjmp, but I think these are implemented as functions - so that'd be no good here. :-( http://www.keil.com/support/man/docs/c51/c51_lib_misc.htm Again, this is fundamentally contrary to the principles of 'C' so, if your really must do it, you need to do it in assembler.
SCRAP THE TASK SWITCHER my mathod: Put the time critical "main" portion in an unused ISR Set all "real" ISRs to high priority When the time critical "main" portion is to run set the bit that trigger the "unused" ISR. Erik
You might consider reimplementing your lengthy tasks (functions) as state machines so that each one does a little bit more work on each call. You can then test the flag set by the ISR each time round the main loop, or between each function call if necessary. This may require a fair bit of work to get the timing right, but should prove to be a more robust solution than tricks with low priority ISRs or the infamous setjmp/longjmp. It sounds as though you are using library function calls from your 'slow but low latency' function, this pretty much rules out calling it from an ISR.
but should prove to be a more robust solution than tricks with low priority ISRs or the infamous setjmp/longjmp. Nothing not "robust" about "low priority ISRs", setjmp/longjmp is asking for a disaster. Erik
"Nothing not "robust" about "low priority ISRs"," In the context of the OP's problem there would most definitely be 'not robust' things going on if your low priority ISR strategy were employed. Incidentally, I was unable to see any reference made by the OP to a task switcher?
"I was unable to see any reference made by the OP to a task switcher?" See his post of 4/11/06 1:58:24: "... my main loop is pseudo-multitasking ..."
In the context of the OP's problem there would most definitely be 'not robust' things going on if your low priority ISR strategy were employed. Such as??????????????????? Erik
"See his post of 4/11/06 1:58:24: "... my main loop is pseudo-multitasking ..."" Quite.
it is a bit difficult to find replies that appear OVER the question. anyhow "... my main loop is pseudo-multitasking ..."" If you have the capability to read from "my main loop is pseudo-multitasking" what exactly he means and based on that state "there would most definitely be 'not robust' things" please tell me where you got the glasses that enable you to read the information on which you base that statement. I have seen a simple workloop called "pseudo-multitasking" and I have seen many other schemes named so. The naming of something "pseudo-multitasking" is quite popular since "multitasking" makes anything sound more impressive. If you have just one ISR you can claim that you are "multitasking" and in one sense (not the common one) you would be right. The "unused ISR trick" is "priority multitasking" since the action in the "unused" ISR will have priority over the main. If you check on some multitasking OSs for some processors (e.g. the XA) that have several software interrupts, you will see it is done exactly this way. Erik
"Such as???????????????????" Keyboard trouble?
Keyboard trouble? and how would a low priority ISR give trouble to a high priority timer ISR (standard procedure for debouncing keys)? Erik
If you have the capability to read from "my main loop is pseudo-multitasking" what exactly he means and based on that state "there would most definitely be 'not robust' things" please tell me where you got the glasses that enable you to read the information on which you base that statement. Perhaps you'd like to explain where you got the idea I based my statement on his main loop being pseudo multitasking? I have seen a simple workloop called "pseudo-multitasking" and I have seen many other schemes named so. The naming of something "pseudo-multitasking" is quite popular since "multitasking" makes anything sound more impressive. If you have just one ISR you can claim that you are "multitasking" and in one sense (not the common one) you would be right. Do you understand what 'pseudo' means? Do you really think it tells us there is a 'task switcher' involved? Not from your paragraph above, it would seem.
and how would a low priority ISR give trouble to a high priority timer ISR (standard procedure for debouncing keys)? You have quite a talent for misunderstanding, don't you? I was enquiring whether you had keyboard trouble as your '?' key appears to be sticking.