> Taki producent odpowiednika STM32 ale opartego o rdzeń RISC może ściąć
> cenę swoich cpu o dolara, powiedzmy. A to robi różnicę kiedy ich
> sprzedajesz setki milionów, choćby jako sterowniki dildo i szczoteczek
> do zębów.

Ale przecież do tego już mają rdzenie. Każdy. Np. Texas ma MSP430. Bardzo fajny, też
RISC, swoją drogą. Pobór prądu ma mniejszy, niż naturalny wyciek z typowej
konsumenckiej baterii. Czyli bateryjkę prędzej szlag trafi ze starości, niż z
wyładowania. I każdy poważny producent takie coś ma, w dodatku swoje, więc nie musi
się martwić o czyjeś licencyjne fanaberie. To po co jakiś RISC-V?

> POSIX w embedded nie jest dobry.

Nadal nie napisałeś, dlaczego.

> Osobiscie wolałbym aby mój respirator niekoniecznie pracował na POSIXie.

Na pewno nie chcesz, żeby opracował na FreeRTOSie, bo to ma poziom poniżej
amatorskiego.
Ale ponieważ POSIX to jest tylko API a nie implementacja, to dlaczego nie? Mogę mieć
dobrej jakości implementację z interfejsem POSIX. Nadal nie napisałeś niczego, co by
temu przeczyło.

Przykładowo, dobrej jakości systemem do embedded z interfejsem POSIX jest QNX.
W szczególności, jest używany w systemach medycznych:

https://blackberry.qnx.com/en/software-solutions/emb
edded-software/medical

Więc jednak masz POSIX w urządzeniu medycznym. I dobrze.

> Ale musisz mieć abstrkację. Masz, prawda? Jak byś inaczej mógł
> to testować. Wiec musisz mieć.

Przecież napisałem, że mam. Nazywa się POSIX.

> Zaznajom się np. z Qt.

Już mnie kiedyś chciałeś do tego zachęcić, ale słabo wyszło.

> POSIX nie jest przenośny. Istnieje masa systemów z nim niezgodnych.

Ręce opadają, nic nie rozumiesz.
To nie POSIX ma być przenośny, tylko programy napisane pod to API. I zapewniam, że
takie programy są przenośne pomiędzy systemami, które ten standard implementują.
Np. kod, który napisałem na Linuksie zadziałał od ręki na QNX. Radości było z tego
jak mało kiedy. Właśnie na tym polega ta przenośność.

> Zaś wszystkei zgodne maja mała użytecznośc w embedded. POSIX jest do
> stacji roboczych a nie migania diodami lub kontroli oddechu. Naprwadę,
> nie potrzebujesz parentpid i fopen w respiratorze.

Czyli dalej nie rozumiesz. Kto powiedział, że system ma mieć wszystkie funkcje?
Chodzi o to, że jeśli już ma np. funkcję inicjalizującą mutex, to niech ta funkcja
się nazywa pthread_mutex_init a nie ourMutexCreate. I jeśli system ma tylko 10 takich
funkcji, to niech one się nazywają tak jak 10 funkcji z POSIX. I to wystarczy, żeby
kod napisany na taki system można było bez żadnej modyfikacji przenieść albo zrobić
mu unit-testy na innym systemie, np. na Linuksie, bo akurat taki jest łatwiej
dostępny.

> > Albo korzystam ze standardów. Takim standardem jest POSIX.
> Dalej nie pojmujesz że posix nie jest abstrakcją.

Dalej nie przeczytałeś nawet pierwszego zdania z Wikipedii na ten temat. A dałem
linka.

> Abstrakcją jest
> MyTools::MyMutex a nie pthread_mutex.

To jest abstrakcja na abstrakcję. Też tak robię - ale to jest dodatkowy koszt,
którego nie musiałbym ponosić, gdyby systemy były zgodne ze standardami. A niestety
nie są, bo przecież fajniej jest mieć ourMutexCreate().
I teraz masz milion firm robiących systemy embedded i każda z nich robi wrapper
MyTools::MyMutex. Dlaczego? Ile jest interesujących systemów w użyciu, nawet
wliczając te dziadoskie typu FreeRTOS? No ile? To zobacz teraz, jaki jest stosunek
kosztów: milion firm robi własne abstrakcje do abstrakcji, bo w przybliżeniu 2-3
systemy koniecznie musiały mieć ourMutexCreate. Czyli sumaryczny koszt tych
wszystkich abstrakcji jest większy, niż to pod spodem. To jest choroba naszej branży.

> Abstrakcją może byc też Qt

Ale czemu sobie żałować? Zróbmy abstrakcję na to też. Przecież nie wszystkie
frameworki są zgodne, prawda? A co jak management zdecyduje, że zmieniamy Qt na coś
innego? I teraz, jeśli programiści nie są idiotami, to pójdzie sprawnie, bo mają
abstrakcje, tak?
Wszystkie Twoje argumenty można tu zastosować.

[POSIX]
> Przeczytałeś cos nie na temat. To jest abstrkacja do konkretnej rodziny
> systemów.

Konkretnej? Nie, żadnej rodziny tam nie było. Niektórych systemów w ogóle jeszcze nie
było, jak ten standard powstał.

> W tej rodzinie nie ma FreeRTOSa ani Widnowsa CE, a są one w
> embedded używane.

No są. Niestety. Bo po co być zgodnym ze standardami, skoro można mieć - *beż żadnej
wartości dodanej* - ourMutexCreate?
Ale o to można obwiniać tylko autorów tych systemów.
POSIX jest standardem. QNX spełnia ten standard. FreeRTOS nie spełnia tego standardu.
Co zrobić.

> Posix to NIE jest abstrakcja na systemy operacyjne.

Właśnie dokładnie tym jest.

> Co najwyżej na wąską
> grupę bardzo podobnych systemów, o nikłej uzytecznosci w embedded.

Nadal czekam na wyjaśnienie, dlaczego nie do embedded.
Dlaczego ourMutexCreate jest do embedded a pthread_mutex_init nie jest. To ciekawe
bardzo. Funkcja się inaczej nazywa i już nie nadaje się do embedded. Kurdę, muszę
uważać, jak funkcje nazywam.

> Abstrakcja na systemy operacyje jest wysokopoziomowa. Tam gdzie nie
> wiadomo czy mutex to int, handle, pointer czy foo.

Właśnie tak jest w POSIX. pthread_mutex_t nie jest określony w standardzie i w
różnych implementacjach może być różnie zdefiniowany.

> Januszowe RTOSiki są popularniejsze od grażynowych posixów.

A x86 i DOS były popularniejsze swego czasu. Tylko że samodzielnie wylałeś na nie
tyle żółci, że powinieneś sam rozumieć, jaki jest związek popularności z wartością
merytoryczną.

> Pewnego dnia januszowy RTOSik zostanie zamieniony na mirkowy CE bo taki
> się zwidziało właścicielowi biznesu. Jesli Janusz nie był iditiotą to
> zmiana na to CE może być mało bolesna.

Niestety nie jest to zgodne z moimi obserwacjami. Zmiana jednego systemu POSIX na
drugi system POSIX może być mało bolesna, ale zmiana OurRTOS na TheirRTOS to większy
problem, bo jak już ktoś miał gdzieś standardy, to zwykle w różnych, niezależnych
kierunkach. Wtedy to nie jest kwestia taniego wrappera. Zwłaszcza, jak to tego
dołożymy stos TCP. Np. popularnym partnerem dla dziadoskiego FreeRTOSa jest dziadoski
LwIP. To jest dopiero duet, wszystko wtedy opada.

> Pamiętaj o czym rozmawiamy: stwierdziłeś że zmiana procesora to nie
> tylko zmiana makefile, tylko bardzo ciezka rzecz.
>
> No więc to cieżka rzecz, jak się ma dziadowski kod.

Jeszcze cięższa, jak się nie ma kodu. O tej możliwości też cały czas mówimy, bo to
jest realna możliwość.

Ale trochę rozwlekła nam się ta dyskusja zrobiła, więc może skupmy się: dlaczego
POSIX nie jest dobry do embedded? Dlaczego funkcja, która się nazywa na literkę "p"
nie nadaje się do embedded a funkcja robiąca dokładnie to samo, ale na inną literkę
się nadaje?
"U mnie działa."

--
Maciej Sobczak * http://www.inspirel.com