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