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.
Hello all, I am working on a personal project - an RTOS for a XC167. It is fun and all goes well (still need to cut off some time of a context switch duration though - currently around 118 micro) and I am hoping to write one more system call to allow a task to wait for an interrupt to occur. I was going to allow this type of call: rtos_interrupt_wait(int32u interrupt) which puts a task in a seperate queue (out of the ready list) until the interrupt occurs. but in order to catch an intercept, you must always compile your code with a function that declares itself as an ISR, not? that implies that I should write some kind of macro to catches an interrupt, and copy-paste it with different interrupt numbers to handle all possibilities. but is there a better, more code efficient way? I failed to program my interrupt vector table (at least when its beginning was located at memory 0x0). Thanks in advance, Tamir
some kind of macro to catches an interrupt, and copy-paste it with different interrupt numbers to handle all possibilities. but is there a better, more code efficient way? You could always use one single interrupt handler for all your interrupts. But then, that routine is going to have to check the source of the interrupt, and do different things depending on the interrupt source. That is, it will have a table or switch statement to branch based on interrupt number to different bits of code. This is exactly what the interrupt vector table already does. The extra overhead for many routines is really just the function entrance and return code. This is normally small compared to the body of the function that does actual work. Perhaps you can write your own dispatch code that is smaller than the sum of all the prologue/epilogues. But it seems unlikely.
hi, thank for your reply! I am going to make my system call a macro that expands the right ISR. the expanded code will then orginize everything with the kernel. I haven't tried it yet, but that seems much easier than rewritting the interrupt vector table...I have two simple questions though (out of curiosity): can I modify the contents of the interrupt vector table while the program is running? my instinct says NO... do you know where I can find the source of Monitor166? thanks again, Tamir
can I modify the contents of the interrupt vector table while the program is running? Yes, you can. It's standard technique when you need to remap memory which contains the interrupt vector table. my instinct says NO... You don't need to rely on your instinct. It's all in the manuals. Regards, - mike