STM32F4-Discovery – test ChibiOS, CMSIS RTOS, TNKernel: dwa procesy, makefile, armcc/gcc

Krótki test RTOS-ów na STM32F4-Discovery.

Zawodnicy:
ChibiOS
CMSIS RTOS (by Keil)
CoOS
FreeRTOS
ISIX
RTX (by Keil)
TNKernel

Kompilatory (kompilacja przez makefile):
armcc 5.0.2 (CMSIS, CoOS, FreeRTOS, RTX, TNKernel)
gcc 4.7.2 (ChibiOS, CMSIS, CoOS, FreeRTOS, ISIX, TNKernel)

Zadanie:
Utworzyć dwa procesy.
Proces nr 1 wykonuje polecenie i kończy działanie. Proces powinien być zabity przez RTOS.

TASK_1 ()
{
zapal_diody();
}

Proces nr 2 wykonuje polecenia bez końca.

TASK_2 ()
{
for (;
{
czekaj_ms (1000);
mrugaj_diodami();
}
}

Z tym zadaniem poradziło sobie trzech zawodników (w nawiasach wrażenia bardzo subiektywne):
ChibiOS (dopracowany, mały kod wynikowy, robi dobre wrażenie)
CMSIS RTOS (elegancki, duży potencjał rozwojowy)
TNKernel (prosty, chyba już nie rozwijany)

PS. 1. Ten test nie miał na celu określenia najlepszego systemu.

PS. 2. FreeRTOS jest wg. mnie jednym z najlepszych RTOS-ów, więc nieco zdziwił mnie ten wynik. Chyba, że popełniłem jakiś błąd.

Moderowany przez zumek:

Zanim kolega założy kolejny chaotyczny temat, to proszę przed tym zapoznać się z poniższymi linkami. Aby zobaczyć materiał na tym forum musisz być zalogowany Aby zobaczyć materiał na tym forum musisz być zalogowany

Trochę mało szczegółów. Jaki był spodziewany rezultat i jakie były wyniki? Co to ma testować, zapalił i pomrugał diodami? Coś nie wyczuwam obciążenia dla systemów.
FreeRTOS jak ma delay (vTaskDelay) to wątki o niższym priorytecie się nie wykonają, w zasadzie to o tym samy również nie, jakie miałeś priorytety ustawione?

Cytat:

PS. 2. FreeRTOS jest wg. mnie jednym z najlepszych RTOS-ów, więc nieco zdziwił mnie ten wynik. Chyba, że popełniłem jakiś błąd.

To nie pracowałeś widocznie z takimi RTOS-ami jak np Integrity.

FreeRTOS:


Zmiana priorytetów nic nie zmienia; task_1 zapala diody i system się wiesza.

CMSIS RTOS:


CMSIS zabija task_1 i system działa dalej.

A co robi FreeRTOS z taskiem który się skończył? Nigdy nie miałem takiego kończącego się tasku, ale jedno wiem, takie zadanie dla FreeRTOS to raczej nie jest wyzwanie. Napisałem kilka dużych projektów na tym systemie, łącznie z siecią, USB, webserverem itd. Ten system pewnie nie jest the-best-of-the-best ale na Boga potrafi mieć wątki i je wykonywać. I jest stabilny.

Ze strony FreeRTOS

Cytat:

Task functions should never return so are typically implemented as a continuous loop. Again, see the RTOS demo application for numerous examples.

Raczej należy task zawiesić na końcu: "vTaskSuspend" jeśli chce się go zniszczyć to tylko vTaskDelete

Jeśli chodzi o FreeRTOS-a dla procesorów ARM CM3 i CM4F, to rozwiązanie wydaje się stosunkowo proste.
W pliku 'port.c' dodałem funkcję:

i zmieniłem jedną linijkę w funkcji 'pxPortInitialiseStack':

I teraz wyjście z funkcji powoduje, że RTOS zabija proces.
Tego właśnie oczekiwałem.

Pozdrawiam wszystkich!

rajszym napisał:

Krótki test RTOS-ów na STM32F4-Discovery.

Gdzie? Ja widzę tylko dwa bezsensowne przykłady i ani pół słowa o wynikach.

michcior napisał:

FreeRTOS jak ma delay (vTaskDelay) to wątki o niższym priorytecie się nie wykonają, w zasadzie to o tym samy również nie

Czy Ty choć wiesz o czym piszesz, czy może tak sobie fantazjujesz?

rajszym napisał:

I teraz wyjście z funkcji powoduje, że RTOS zabija proces.
Tego właśnie oczekiwałem.

Szkoda że zanim zacząłeś czegoś oczekiwać, nie przeczytałeś dokumentacji, gdzie na pierwszym miejscu o taskach pisze tak:

Cytat:

pvTaskCode Pointer to the task entry function. Tasks must be implemented to never return (i.e. continuous loop).

Proponuję moderatorom zmianę nazwy tego tematu, bo nie ma ona nic wspólnego z zawartością. Raczej coś na styl "FreeRTOS - nie przeczytałem manuala i coś mi nie działa" byłaby bardziej adekwatna.

4\/3!!