NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Wybór systemu operacyjnego dla Cortex-M: FreeRTOS, ChibiOS, uC/OS-III czy inne?
Marek Borowski
Guest
Guest
Mon Sep 30, 2013 10:47 am
No wlasnie ktorego warto uzywac, FreeRTOSa, CoOS, ChibiOS Nut/OS czy
moze uC/OS-III, ThreadX albo embOS ? A moze jeszcze cos innego ?
Rozwiazania komercyjne wygladaja fajnie ale 70k za licencje to lekka
przesada.
Ciekawa tez opcja jest zwiazanie sie z konkretnym producentem
i uzywanie jego produktu, ale raz juz musialem praktycznie
od nowa pisac projekt bo producent sie wycofal z produkcji
potrzebnej lini procesorow - jest to troche ryzykowne.
Z checia zobacze opinie innych.
Pozdrawiam
Marek
Marcin
Guest
Guest
Mon Sep 30, 2013 1:20 pm
W dniu 30.09.2013 12:47, Marek Borowski pisze:
Quote:
No wlasnie ktorego warto uzywac, FreeRTOSa, CoOS, ChibiOS Nut/OS czy
moze uC/OS-III, ThreadX albo embOS ? A moze jeszcze cos innego ?
Rozwiazania komercyjne wygladaja fajnie ale 70k za licencje to lekka
przesada.
Ciekawa tez opcja jest zwiazanie sie z konkretnym producentem
i uzywanie jego produktu, ale raz juz musialem praktycznie
od nowa pisac projekt bo producent sie wycofal z produkcji
potrzebnej lini procesorow - jest to troche ryzykowne.
Z checia zobacze opinie innych.
Pozdrawiam
Marek
moze uC/OS-III, ThreadX albo embOS ? A moze jeszcze cos innego ?
Rozwiazania komercyjne wygladaja fajnie ale 70k za licencje to lekka
przesada.
Ciekawa tez opcja jest zwiazanie sie z konkretnym producentem
i uzywanie jego produktu, ale raz juz musialem praktycznie
od nowa pisac projekt bo producent sie wycofal z produkcji
potrzebnej lini procesorow - jest to troche ryzykowne.
Z checia zobacze opinie innych.
Pozdrawiam
Marek
Z mojej strony polecam RTEMS.
Marcin
Guest
Mon Sep 30, 2013 2:49 pm
Quote:
No wlasnie ktorego warto uzywac, FreeRTOSa, CoOS, ChibiOS Nut/OS czy
moze uC/OS-III, ThreadX albo embOS ? A moze jeszcze cos innego ?
Rozwiazania komercyjne wygladaja fajnie ale 70k za licencje to lekka
przesada.
moze uC/OS-III, ThreadX albo embOS ? A moze jeszcze cos innego ?
Rozwiazania komercyjne wygladaja fajnie ale 70k za licencje to lekka
przesada.
ISIX RTOS ?
Pzdr,
K.B.
Guest
Mon Sep 30, 2013 3:10 pm
On Monday, September 30, 2013 12:47:13 PM UTC+2, Marek Borowski wrote:
Quote:
No wlasnie ktorego warto uzywac, FreeRTOSa, CoOS, ChibiOS Nut/OS czy
moze uC/OS-III, ThreadX albo embOS ? A moze jeszcze cos innego ?
eCos - http://ecos.sourceware.org/
moze uC/OS-III, ThreadX albo embOS ? A moze jeszcze cos innego ?
eCos - http://ecos.sourceware.org/
NuttX - http://nuttx.org/
Quote:
Ciekawa tez opcja jest zwiazanie sie z konkretnym producentem
i uzywanie jego produktu, ale raz juz musialem praktycznie
od nowa pisac projekt bo producent sie wycofal z produkcji
potrzebnej lini procesorow - jest to troche ryzykowne.
Vendor Lock-in. W takich sytuacjach widoczne staja sie zalety
i uzywanie jego produktu, ale raz juz musialem praktycznie
od nowa pisac projekt bo producent sie wycofal z produkcji
potrzebnej lini procesorow - jest to troche ryzykowne.
Vendor Lock-in. W takich sytuacjach widoczne staja sie zalety
otwartego oprogramowania.
Sebastian BiaĹy
Guest
Guest
Mon Sep 30, 2013 4:10 pm
On 2013-09-30 12:47, Marek Borowski wrote:
Quote:
No wlasnie ktorego warto uzywac
Zdefiniuj potrzeby. Preemptive czy cooperative? RT czy nie? Drivery czy
nie? POSIX czy nie? Linux like czy nie itd...
Marek Borowski
Guest
Guest
Mon Sep 30, 2013 6:09 pm
On 9/30/2013 6:10 PM, Sebastian Biały wrote:
Quote:
On 2013-09-30 12:47, Marek Borowski wrote:
No wlasnie ktorego warto uzywac
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
No wlasnie ktorego warto uzywac
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
Sebastian BiaĹy
Guest
Guest
Mon Sep 30, 2013 6:22 pm
On 2013-09-30 20:09, Marek Borowski wrote:
Quote:
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.
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.
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.
Quote:
Przyjmujac takie kryterium to i
AmigaOS 1.0 jest RT.
AmigaOS 1.0 jest RT.
Forbid()/Permit() zalatwiało sprawę RT na Amidze :P
Quote:
Ale tak generalnie tak uzyty OS nie moze
wykluczac mozliwosci zbudowania systemu hard rt.
wykluczac mozliwosci zbudowania systemu hard rt.
Zawsze można wyłączyć przerwania. Tylko wtedy możliwe że OS jest zbedny.
Quote:
Pytanie bylo dosyc ogolne. Ciekawmi mnie kto uzywa czego i dlaczego.
Interesuje mnie glownie spojnosc i przejrzystosc API.
Interesuje mnie glownie spojnosc i przejrzystosc API.
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ł) :/
Quote:
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.
z pelnym posixem ktory na mikrokontrolerze ze 128k RAMu
bedzie chodzil dobrze to z checia sie zapoznam
.
Linux-like zapewne wyklucza RT.
Prywatnie stosuje inne rozwiązanie: Część RT do osobnego procesora.
Sprawdziło się znakomicie.
Jakub Rakus
Guest
Guest
Mon Sep 30, 2013 7:08 pm
On 30.09.2013 20:22, Sebastian Biały wrote:
Quote:
Linux-like zapewne wyklucza RT.
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).
--
Pozdrawiam
Jakub Rakus
Krzysztof Kajstura
Guest
Guest
Tue Oct 01, 2013 7:11 am
W dniu 2013-09-30 20:22, Sebastian Biały pisze:
Quote:
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.
Linux-like zapewne wyklucza RT.
z pelnym posixem ktory na mikrokontrolerze ze 128k RAMu
bedzie chodzil dobrze to z checia sie zapoznam
.
Linux-like zapewne wyklucza RT.
Nie do końca - patrz PREEMPT_RT, Xenomai. Polecam link:
http://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime
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ę.
Marcin
Guest
Guest
Tue Oct 01, 2013 9:50 am
W dniu 30.09.2013 20:09, Marek Borowski pisze:
Quote:
On 9/30/2013 6:10 PM, Sebastian Biały wrote:
On 2013-09-30 12:47, Marek Borowski wrote:
No wlasnie ktorego warto uzywac
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
On 2013-09-30 12:47, Marek Borowski wrote:
No wlasnie ktorego warto uzywac
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
Juz Ci kolego wskazalem RTEMS.
Poczytaj sobie dokumentacje. Jest m.in. posixowe API.
Marcin
Marek Borowski
Guest
Guest
Wed Oct 02, 2013 10:30 am
On 9/30/2013 8:22 PM, Sebastian Biały wrote:
Quote:
On 2013-09-30 20:09, Marek Borowski wrote:
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.
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.
Przyjmujac takie kryterium to i
AmigaOS 1.0 jest RT.
Forbid()/Permit() zalatwiało sprawę RT na Amidze :P
Ale tak generalnie tak uzyty OS nie moze
wykluczac mozliwosci zbudowania systemu hard rt.
Zawsze można wyłączyć przerwania. Tylko wtedy możliwe że OS jest zbedny.
Oczywiscie OS bywa zbedny i mozna odpowienie "taski" poprzypinac do
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.
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.
Przyjmujac takie kryterium to i
AmigaOS 1.0 jest RT.
Forbid()/Permit() zalatwiało sprawę RT na Amidze :P
Ale tak generalnie tak uzyty OS nie moze
wykluczac mozliwosci zbudowania systemu hard rt.
Zawsze można wyłączyć przerwania. Tylko wtedy możliwe że OS jest zbedny.
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.
Quote:
Pytanie bylo dosyc ogolne. Ciekawmi mnie kto uzywa czego i dlaczego.
Interesuje mnie glownie spojnosc i przejrzystosc API.
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ł) :/
Uparles sie na to API w C++. W przypadku OSa z 50 publicznymi funkcjami
Interesuje mnie glownie spojnosc i przejrzystosc API.
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ł) :/
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.
Quote:
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.
Linux-like zapewne wyklucza RT.
Prywatnie stosuje inne rozwiązanie: Część RT do osobnego procesora.
Sprawdziło się znakomicie.
No popatrz ja tez.
z pelnym posixem ktory na mikrokontrolerze ze 128k RAMu
bedzie chodzil dobrze to z checia sie zapoznam
.
Linux-like zapewne wyklucza RT.
Prywatnie stosuje inne rozwiązanie: Część RT do osobnego procesora.
Sprawdziło się znakomicie.
No popatrz ja tez.
Pozdrawiam
Marek
Marek Borowski
Guest
Guest
Wed Oct 02, 2013 10:31 am
On 10/1/2013 11:50 AM, Marcin wrote:
Quote:
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.
Juz Ci kolego wskazalem RTEMS.
Poczytaj sobie dokumentacje. Jest m.in. posixowe API.
No wyglada ciekawie, ale odnioslem wrazenie ze to raczej
z pelnym posixem ktory na mikrokontrolerze ze 128k RAMu
bedzie chodzil dobrze to z checia sie zapoznam
.
Juz Ci kolego wskazalem RTEMS.
Poczytaj sobie dokumentacje. Jest m.in. posixowe API.
No wyglada ciekawie, ale odnioslem wrazenie ze to raczej
alternatywa dla uLinuxa. czyt. systemy z kilkoma MB RAMu.
Pozdrawiam
Marek
Sebastian BiaĹy
Guest
Guest
Wed Oct 02, 2013 3:31 pm
On 2013-10-02 12:30, Marek Borowski wrote:
Quote:
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.
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.
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 ...
Quote:
Uparles sie na to API w C++. W przypadku OSa z 50 publicznymi funkcjami
wrapper mozesz sobie napisac w 1 dzien.
wrapper mozesz sobie napisac w 1 dzien.
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.
Quote:
Ja tam bym wolal aby nie
mialo makr z C i 10 typedefow na inta.
mialo makr z C i 10 typedefow na inta.
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...
elektroda NewsGroups Forum Index - Elektronika Polska - Wybór systemu operacyjnego dla Cortex-M: FreeRTOS, ChibiOS, uC/OS-III czy inne?