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.
