On 9/30/2013 8:22 PM, Sebastian Biały wrote:
> 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
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.


>> 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
wrapper mozesz sobie napisac w 1 dzien. Ja tam bym wolal aby nie
mialo makr z C i 10 typedefow na inta.


>> 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.


Pozdrawiam

Marek

do góry

On 10/1/2013 11:50 AM, Marcin wrote:
>> 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
alternatywa dla uLinuxa. czyt. systemy z kilkoma MB RAMu.

Pozdrawiam

Marek

do góry

On 2013-10-02 12:30, Marek Borowski wrote:
> 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.

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 ...

> Uparles sie na to API w C++. W przypadku OSa z 50 publicznymi funkcjami
> 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.

> Ja tam bym wolal aby nie
> 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...

do góry