Re: Port to 32 bits architecture and context switches
Kelvin Lawson <info@...
2010-06-01 19:05:21 GMT
Good to hear from you.
> I'm an embedded software and research engineer in Switzerland and I'm
> currently working on a project involving a ultra-low power CPU/SoC.
> This chip has a 32 bits architecture and common peripherals found in
> many other architectures (timers, UART, vectorized interrupts,...) and
> some more advanced features (DMA, RF radio, ...).
Sounds very interesting.
> We already have a working toolchain (GCC, binutils, ...) for that
> architecture as well as a working libc (newlib). We can currently
> develop bare-metal/standalone applications but we would really
> appreciate to have a small-footprint RTOS also running on it. Googling
> around AtomThreads sounded a well suited alternative (compact, easy to
> port, ...). I carefully read the online documentation and comments in
> sources but some questions remain open for moment. Perhaps you can
> clear some of them ?
> * 32 bits architecture
> AtomThreads is currently officially supported on AVR and STM8
> platforms. Both of them are 8 bits architectures. I read that a
> Cortex-M3 port is on road or at least planed. I didn't find any
> obvious reason why AtomThreads could not run on a 32 bits architecture
> and assume that ( provided that I correctly implement the architecture
> specific functions ) AtomThreads would run correctly on 32 bits
> arch. Did you already try to run AT on a 32 bits CPU (even a
> "quick&dirty" port) ? Are there any caveats to take into consideration
I did some early work on a Cortex M3 port (STM32) but put it on hold
briefly to add support for the IAR STM8 compiler. That support is
almost complete so I should get back onto the Cortex M3 port shortly.
Meanwhile I have heard that others are working on Cortex M3 and ARM9
I expect that a 32 bit architecture port would require no changes to
the core kernel, except that thread stacks are not forced to 32-bit
alignment. I was planning to add a macro to atomport.h (something like
ATOM_STACK_ALIGN) which could be set differently for each
architecture. The atomThreadCreate() function could then apply a
fix-up if badly aligned stack pointers are passed in.
Other than this I don't see any other likely issues with 32-bit
architectures, but I have yet to get one going myself.
> * context switches
> I'm still not sure I understood correctly how context switches really
> work especially how they return back to the "scheduled in" thread. I
> read Kelvin's explanations in his post to the list on 7 Apr 23:15
> (http://permalink.gmane.org/gmane.os.atomthreads/9) but I'm still a
> bit confused ...
> If I understand correctly archContextSwitch is *always* called from
> atomThreadSwitch() and this independently of the type of context
> switch (cooperative: atomTimerDelay(), or preemptive: through timer
> interrupt handler). Therefore archContextSwitch will *always* return
> through atomThreadSwitch() and then roll-out the call tree saved on
> stack when the thread was scheduled out. Is that correct?
Yes that is how it has worked out on the two architectures currently
completed (AVR and STM8), however it is unlikely to be the best way to
do it on all architectures (for example there is specific support for
operating systems in Cortex M3 that would not match the scheme used on
those ports). There may be slight changes required to the kernel for
FYI the general scheme with AVR and STM8 is that because
archContextSwitch() is always called from C code, it does not need to
save scratch registers (those registers which the compiler does not
expect to be preserved by a called function). This works out quite
nicely on AVR and STM8, limiting the number of registers which need to
be saved for cooperative context switches (where a thread schedules
itself out). It can work out that only a subset of registers end up
being saved on the thread's stack. For preemptive switches (caused by
any interrupt, not just the timer tick) all of the registers need to
One of the convenient features of the AVR and STM8 that helps toward
this is that the port can use standard RET-type assembler instructions
to exit archContextSwitch(), whether entered via an ISR or thread.
This is not going to be the case on all architectures.
I wrote some of this up at the following page in case that helps,
otherwise let me know if you have any questions:
> * nested interrupts
> As far as I read nested interrupts are currently not supported by the
> current AtomThreads design. My SoC could support nested interrupts but
> in a first step I will disable this feature by disabling interrupts on
> each interrupt handler entry and activate them back at the end of the
> handler. Do you have any hints on nested interrupts support ? Did
> already one of you try to run AT with nested interrupts enabled ? I
> know that these low-level details are really architecture dependent
> but any input is welcome.
I don't expect nested interrupt support to be complicated, but I
haven't yet implemented it. I have been focusing on adding support for
a wide range of architectures before moving on to adding more advanced
functionality. Once a 32-bit architecture is complete I expect to
verify nesting supporting then.
Keep me posted on how you get on, I will be happy to help out wherever I can.
> Thanks for reading and have a nice day!