kelvinlawson/atomthreads

Lightweight, Portable RTOS Scheduler

---

• Library: Atomthreads
• Author: Kelvin Lawson [email protected]
• Website: http://atomthreads.com
• License: BSD Revised

---

Atomthreads is a free RTOS for embedded systems, released under the flexible, open source BSD license and is free to use for commercial or educational purposes without restriction.

It is targeted at systems that need only a lightweight scheduler and the usual RTOS primitives. No file system, IP stack or device drivers are included, but developers can bolt on their own as required. Atomthreads will always be a small number of C files which are easy to port to any platforms that require threading by adding a simple architecture-specific file.

---

DOCUMENTATION:

All documentation is contained within the source files, commented using Doxygen markup. Pre-generated documentation can be accessed at http://atomthreads.com.

See also the README file contained within each folder of the source tree.

---

GETTING STARTED:

Building of the sources is carried out from the ports tree. For example to make a software build for the AVR architecture see ports/avr/README.

---

SOURCE TREE:

• kernel: Core kernel sources
• tests: Automated test suite
• ports: CPU architecture ports

---

AUTOMATED TESTS STATE:

• Continuous Integration hosted at travis-ci.org:

atomthreads's Issues

Can't register the same timer again at the timeout handle function

static void led_flash_timer_handle(POINTER param)
{
       LED_RED_TOGGLE();    
       led_timer.cb_ticks = 300
        led_timer.cb_func = led_flash_timer_handle;
        led_timer.cb_data = NULL;        
        atomTimerRegister(&lock_led_timer);    
}

void led_flash(uint8_t led, uint32_t interval, uint8_t flash_times)
{
    atomTimerCancel(&lock_led_timer);

     LED_RED_ON();

    lock_led_timer.cb_ticks = 300;
    lock_led_timer.cb_func = led_flash_timer_handle;
    lock_led_timer.cb_data = NULL;

    atomTimerRegister(&lock_led_timer);    
}

The callback list in atomTimerCallbacks() will be changed if the timer register again in led_flash_timer_handle. This limit the application of timers.

8 bit cpu with SDCC compiler

we are curious about SDCC compiler form http://sdcc.sourceforge.net/. it's small, free and could run in linux OS. could you please port STM8 cpu with it? I have tried but failed, because of do not understand compiler and atomthread.

SDCC compiler for STM8

Currently, atomthreads supports the STM8 via non-free compilers only. How about adding support via free SDCC?

Philipp

Update callback_list_tail

The callback_list_tail variable is not updated after adding a callback request in atomTimerCallbacks() in atomtimer.c, line 456.

/Rgrds Erik

atomTimerDelay

In atomTimerDelay pass the address of a local variable( ATOM_TIMER timer_cb ) to another function:

atomTimerRegister (&timer_cb).

This is clearly a mistake and, as a result, in my program it only puts the idle_thread in the readyQueue. I come with a fix in a few days...

Address of local variable timer_cb is assigned to a non-local variable

Storing the address of a local variable in non-local memory can cause a dangling pointer bug if the address is used after the function returns.

atomthreads/kernel/atomtimer.c

Line 372 in 1a2f9ba

curr_tcb_ptr->suspend_timo_cb = &timer_cb;

atomthreads/kernel/atomsem.c

Line 380 in 1a2f9ba

curr_tcb_ptr->suspend_timo_cb = &timer_cb;

atomthreads/kernel/atomqueue.c

Line 399 in 1a2f9ba

curr_tcb_ptr->suspend_timo_cb = &timer_cb;

atomthreads/kernel/atommutex.c

Line 415 in 1a2f9ba

curr_tcb_ptr->suspend_timo_cb = &timer_cb;

atomthreads/kernel/atomqueue.c

Line 607 in 1a2f9ba

curr_tcb_ptr->suspend_timo_cb = &timer_cb;

atomMutexPut() corrupts unclaimed mutex when called from interrupt context

When atomMutexPut() is called from an interrupt context, curr_tcb_ptr is not checked against NULL. It is checked against mutex->owner, and if the mutex is unclaimed it will match and result in mutex->count being decremented - which will underflow to 255 since the original value will be 0. At this stage the mutex can no longer be claimed (due to count==255) but if it happens multiple times it can leave the mutex in a state where it can be claimed (once!) but unable to be released due to a corrupt count value.

64-bit thread entry point would be useful for 64-bit architectures

So that pointers can be passed to thread entry points, possibly create an ENTRY_PARAM type definition that can be set as desired on each architecture port.

Why use TIM1? How about TIM4?

The STM8 port uses TIM1, the "16-bit advanced control timer". Does Atomthreads really need it? Would it make sense to leave this fancy timer to the application, and use the much simpler TIM4 for Atomthreads, as e.g. BuguRTOS does?

Philipp

Allow threads to run to completion

Threads can be made to run to completion using the following in thread_shell():

curr_tcb_ptr = atomCurrentContext();
if (curr_tcb_ptr)
{
curr_tcb_ptr->suspended = TRUE;
}
atomSched (FALSE);

However it has not yet been fully verified on all ports, and ports do not necessarily need a thread_shell() routine so a more generic method might be more appropriate.

atomTimerRegister() from within timer callbacks

Add the ability to register new timers from within timer callback interrupts. Or alternatively support self-reloading timers.

Undefined reference to `_exit'

While trying to compile for dm36x i got this error:

~/atomthreads/ports/arm/platforms/dm36x$ make
mkdir build
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. -I../../../../kernel ../../../../tests/kern1.c -o build/kern1.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. -I../../../../kernel -I../../../../tests atomport-private.c -o build/atomport-private.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. -I../../../../kernel -I../../../../tests uart.c -o build/uart.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -x assembler-with-cpp -I. -I../.. -I../../../../kernel startup.s -o build/startup.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. -I../../../../kernel -I../../../../tests ../../atomport.c -o build/atomport.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. -I../../../../kernel -I../../../../tests ../../tests-main.c -o build/tests-main.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. -I../../../../kernel -I../../../../tests ../../syscalls.c -o build/syscalls.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -x assembler-with-cpp -I. -I../.. -I../../../../kernel ../../atomport-asm.s -o build/atomport-asm.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. ../../../../kernel/atomkernel.c -o build/atomkernel.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. ../../../../kernel/atomsem.c -o build/atomsem.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. ../../../../kernel/atommutex.c -o build/atommutex.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. ../../../../kernel/atomtimer.c -o build/atomtimer.o
arm-none-eabi-gcc -c -g -c -mcpu=arm926ej-s -ffreestanding -Wall -Werror -I. -I../.. ../../../../kernel/atomqueue.c -o build/atomqueue.o
arm-none-eabi-gcc -mcpu=arm926ej-s -Tsystem.ld -Wall build/kern1.o build/atomport-private.o build/uart.o build/startup.o build/atomport.o build/tests-main.o build/syscalls.o build/atomport-asm.o build/atomkernel.o build/atomsem.o build/atommutex.o build/atomtimer.o build/atomqueue.o --output build/kern1.elf -Wl,-Map,build/kern1.map
/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/lib/libc.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x2c): undefined reference to `_exit'
collect2: error: ld returned 1 exit status
make: *** [kern1.elf]

~/atomthreads/ports/arm/platforms/dm36x$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../lib/gcc/arm-none-eabi/4.7.4/lto-wrapper
Target: arm-none-eabi
Configured with: /build/buildd/gcc-arm-none-eabi-4-7-2013q3/src/gcc/configure --target=arm-none-eabi --prefix=/build/buildd/gcc-arm-none-eabi-4-7-2013q3/install-native --libexecdir=/build/buildd/gcc-arm-none-eabi-4-7-2013q3/install-native/lib --infodir=/build/buildd/gcc-arm-none-eabi-4-7-2013q3/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/build/buildd/gcc-arm-none-eabi-4-7-2013q3/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/build/buildd/gcc-arm-none-eabi-4-7-2013q3/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/build/buildd/gcc-arm-none-eabi-4-7-2013q3/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/build/buildd/gcc-arm-none-eabi-4-7-2013q3/install-native/arm-none-eabi --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors' --with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 4.7.4 20130913 (release) [ARM/embedded-4_7-branch revision 202601] (GNU Tools for ARM Embedded Processors)

What am I doing wrong?

-Os switch to gcc causes compilation warning and hence error

Hello!

I turned on the -Os switch to gcc in my Arduino Nano port and that generated a compilation warning and (by the nature of -Werror) an error.
The fix is silly simple, please see my fork at https://github.com/spe-ciellt/atomthreads and particulary the commit spe-ciellt@16cfe63

Thanks and best regards,
/Stefan

MicroBlaze port

I have recently put together a port for the MicroBlaze soft-core micro-controller (32 bit configuration, no virtual memory).
I also have a variant port for the Cortex-M for STM32 MCUs and SmartFusion FPGAs that work with the vendor provided tools and firmware libraries.
In addition, I have created an optional module that provides another synchronization technique.
Is there interest in me submitting these as a pull request, or should I just leave them on my own fork?

New TCB terminated field not initialized

The newly added ATOM_TCB.terminated field is not initialized to FALSE in atomThreadCreate.

I would say it should be, as the new atomSched logic relies on it

Extra semicolon in struct in atom.h

When THREAD_PORT_PRIV is not defined in atom.h, line 63, we get an extra semicolon. This is not allowed by the C standard.
SDCC gives an error message: ../../kernel/atom.h:63: syntax error: token -> ';' ; column 5
GCC gives a warning when using -pedantic.

Philipp

Why uint32_t stack_size

Why is the stack_size parameter to atomThreadCreate() an uint32_t instead of size_t? The uint32_t wastes space on small systems. And size_t seems to be the size meant for such stuff.

Philipp