Hi Kelvin, Wow, that is quick!
Well, I am working on a port for the ARM1026EJ an embedded core that my company is using in an ASIC. There shouldn't be too much difference between this and an ARM9 though. The ARM port is a little more complicated because of the various processor modes. Either I have to run the whole scheduler in IRQ mode and use the IRQ stack, or switch to system or user mode in the ARM's interrupt handler (In case I go for nested interrupts this is a must anyway.) Anyway, thanks for the explanation. Well, I thought that the timer interrupt would never return and just switch to another thread, so that nested interrupts were a must in order to keep getting timer interrupts. Perhaps I should further check your code to see when and where the timer interrupt returns coz I still don't understand the mechanism on how to switch. When the timer interrupt returns when the original thread is scheduled back in, then something, some interrupt, should cause that. Since interrupts are disabled during the timer interrupt (unless I used nested interrupts) I don't see how is working. Thanks, Kees. > Hi Kees, > > Good to hear from you. > > A user has reported some success on ARM9 but I haven't yet integrated > that port into the official tree and completed all automated tests on > it. I am planning to work on an ARM7 or ARM9 port myself within the > next couple of weeks but meanwhile I'll help out wherever I can. Which > ARM device are you using? > > >> - I guess the ARM interrupt handler must be able to do 'nested' >> interrupts right? >> > Both of the current ports (ATmega and STM8) currently run in > non-nested mode. Changes may be necessary for nested interrupts and I > will make any kernel changes necessary for that when I add support for > nesting. Meanwhile there is no reason why you would need to use nested > interrupts for the benefit of the kernel, only if your application > requires it. > > >> - Does the timer interrupt (the one in atomport.c) ever return? I mean, >> this interrupt calls the scheduler and that switches to one of the >> thread routines isn't it? >> > This will depend on the port, but the way the ATmega and STM8 ports > work is that any interrupt handlers (including the timer interrupt) > which cause a thread switch, will immediately switch execution to the > new thread. The final instructions of the interrupt handler are not > executed until the original thread is scheduled back in. This is OK on > both of these architectures because it is possible to "complete" an > interrupt by regular return calls rather than "return-from-interrupt" > calls. There is some detailed discussion of this in the new STM8 port > (ports/stm8/atomport-asm.s). There may be more appropriate schemes for > other architectures. > > Please let me know if I can help with any further porting issues. > > Thanks, > Kelvin. >
