Hi Atom fans, hi Kelvin

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, ...).

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
?

* 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?

* 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.

Thanks for reading and have a nice day!
    Romain

Reply via email to