Jaki OS do Cortexa ?

ISIX RTOS ?

Pzdr, K.B.

eCos -

Vendor Lock-in. W takich sytuacjach widoczne staja sie zalety otwartego oprogramowania.

W dniu 30.09.2013 12:47, Marek Borowski pisze:

Z mojej strony polecam RTEMS.

Marcin

Zdefiniuj potrzeby. Preemptive czy cooperative? RT czy nie? Drivery czy nie? POSIX czy nie? Linux like czy nie itd...

Zdecydowanie z wywlaszaniem inne to dla mnie to bardziej rozwojowy libc a nie OS :-). Z RT to jest problem bo wiekszosc OS gdzie task w stanie ready o wyzszym piorytecie wywlaszcza natychmiastowo ten o nizszym przypinaja sobie etykietke Real Time. Przyjmujac takie kryterium to i AmigaOS 1.0 jest RT. Ale tak generalnie tak uzyty OS nie moze wykluczac mozliwosci zbudowania systemu hard rt.

Pytanie bylo dosyc ogolne. Ciekawmi mnie kto uzywa czego i dlaczego. Interesuje mnie glownie spojnosc i przejrzystosc API. Np. niski stopien uzycia makr C jest wskazany. Dobrzeby bylo aby OS byl przetestowany ze stosem TCP/IP. Z moich doswiadzen wynika ze 70-90kB RAM jest potrzebne na uruchomienie webserwera serwujacego cos wiecej niz hello web.

Oczwiscie nie ma problemu jak mi wskazesz linux like system z pelnym posixem ktory na mikrokontrolerze ze 128k RAMu bedzie chodzil dobrze to z checia sie zapoznam :-).

Pozdrawiam

Marek

System realtime mają masę innych klopotów, np. czas allokacji albo zajmowanie timerów na własne potrzeby. Ogólnie RT to raczej cooperative niż preemptive.

Forbid()/Permit() zalatwiało sprawę RT na Amidze :P

Zawsze można wyłączyć przerwania. Tylko wtedy możliwe że OS jest zbedny.

O widzisz. Mnie interesuje aby API było w C++. Obecnie 0% systemow spelnia to kreyterium, aż napisałem własny ( po czym projekt umarł) :/

Linux-like zapewne wyklucza RT.

Prywatnie stosuje inne rozwiązanie: Część RT do osobnego procesora. Sprawdziło się znakomicie.

A QNX?

Mnie osobiście ostatnio zainteresował FreeRTOS, sprawia wrażenie bardzo łatwego w implementacji (szczególnie dla kogoś, kto wcześniej nie bawił się OS na uC).

W dniu 2013-09-30 20:22, Sebastian Bia³y pisze:

Nie do koñca - patrz PREEMPT_RT, Xenomai. Polecam link:

Oczywi¶cie w przypadku rdzeni z rodziny Cortex-M (bo chyba o takie autorowi w±tku chodzi), powy¿sze rozwi±zania kompletnie nie wchodz± w grê.

Juz Ci kolego wskazalem RTEMS. Poczytaj sobie dokumentacje. Jest m.in. posixowe API.

Marcin

Oczywiscie OS bywa zbedny i mozna odpowienie "taski" poprzypinac do obslugi przerwan od timerow. Ale jak chce sie dodac do tego duzo dodatkowej pracy ktora nie jest juz czasowo krytyczna to IMO OS warto miec. Co do wczesniejszych uwag to oczywiscie zgoda ale mozna nie miec dynamicznej obslugi pamieci lub stosowac proste algorytmy alokacji (tylko potem co z ta fragmetacja robic :-) no i uzywac opoznione procedury oblugi przerwan.

Spotkalem sie z teza ze mozna dowolny OS i CPU ktory jest 10x szybszy niz potrzeba, ryzyko opoznienia teoretycznie isntnieje ale w praktyce nie wystepuje.

Uparles sie na to API w C++. W przypadku OSa z 50 publicznymi funkcjami wrapper mozesz sobie napisac w 1 dzien. Ja tam bym wolal aby nie mialo makr z C i 10 typedefow na inta.

No popatrz ja tez.

Pozdrawiam

Marek

No wyglada ciekawie, ale odnioslem wrazenie ze to raczej alternatywa dla uLinuxa. czyt. systemy z kilkoma MB RAMu.

Pozdrawiam

Marek

To zależy. Obecnie proste osy embedded z grubsza składają się z dwoch warstw: multitasking i drivery do urządzeń. Multitasking zazwyczaj nie jest potrzebny w embedded (masz przerwania), natomiast drivery są okay. Zazwyczaj są napisane jednak w na tyle obleśny sposób że są niedrywalne od osa więc wychodzi jak zwykle ...

To tylko teoria. Często API sa kompletnie absurdalne i wymagają masy magicznych sztuczek. Doprowadzenie do dzialania kosztuje wiele energii i bywa nieopłacalne, wolę mieć od razu w C++ bo potem wychodza kwadratowe koła.

To inna sprawa, że każdy OS jako punkt honoru uważa że należy przedefiniować cały świat. Że obcy kod już nie działa? Mamy to w d...