Modele licencjonowania, ograniczenia modyfikacji kodu źródłowego oraz certyfikacja branżowa to najważniejsze kwestie biznesowe, które należy uwzględnić przy stawianiu na System Czasu Rzeczywistego (RTOS). W poniższym artykule przyjrzymy się tym czynnikom i temu, w jaki sposób powinny się one przełożyć na wybór samego RTOS-a.
Systemy operacyjne czasu rzeczywistego, popularne w latach 90., przynoszą obecnie wiele korzyści technicznych dla obszernej gamy produktów embedded czasu rzeczywistego. Niektóre z najważniejszych to szybki i niewielki kod programu, wyznaczalna funkcja, szerokie wsparcie w sektorze półprzewodników, strukturalne podejście do projektowania oraz ponowne wykorzystanie oprogramowania poprzez enkapsulację.
RTOS-y zazwyczaj posiadają mikrojądro jako projekt, w którym tzw. scheduler odgrywa kluczową rolę. Budowanie na prostym, a zarazem skutecznym harmonogramie czasu rzeczywistego umożliwia precyzyjne projektowanie systemu. Acz czynniki decydujące o wykorzystaniu konkretnych wykraczają poza podstawy techniczne. Zespoły produkcyjne muszą uwzględnić kwestie biznesowe, inżynierię oprogramowania i długoterminową żywotność przy decydowaniu się na RTOS.
Kwestie biznesowe przy wyborze RTOS-ów
Modele licencjonowania, ograniczenia wobec przebudowywania kodu źródłowego oraz certyfikacja branżowa stanowią najważniejsze zagadnienia biznesowe przy wyborze RTOS. Wszystkie wymienione oddziałują wzajemnie na siebie. Gdy wymagania produktu dotyczą potrzeby możliwości modyfikowania kodu, to może to mieć również wpływ na wybór licencji czy sposobu certyfikacji systemu.
Modele licencjonowania obejmują otwarty kod źródłowy (open-source), komercyjny oraz wersje mieszane. Niektóre z powszechnie stosowanych licencji open-source to MIT-0, Apache 2.0 i Eclipse Public License.
Według badania Embedded Market Survey z 2023 roku, 41% respondentów korzysta z systemu operacyjnego open-source, 20% z open-source z licencjonowaniem komercyjnym, a 21% z licencji komercyjnej. Te ostatnie, tworzone przez podmioty komercyjne, są zazwyczaj własnościowe, a kod źródłowy RTOS nie może być zmieniany ani ponownie dystrybuowany. W wielu przypadkach model licencjonowania mieszanego (kombinacji open-source i opcji komercyjnej) pojawia się, gdy RTOS obejmuje ujęcie open-source i komercyjne, w tym biblioteki firm trzecich. Model licencjonowania bezpośrednio wpływa na możliwość dalszego dystrybuowania kodu i jego modyfikowalność. Ogólnie rzecz biorąc, najbardziej restrykcyjna licencja jest użyta jako punkt odniesienia do omawianych ograniczeń.
Otwarty kod źródłowy czy komercyjny system operacyjny?
Badanie Embedded Market Survey 2023 pokazuje mieszane tendencje.
(Źródło: embedded.com / AspenCore Media)
Ograniczenia modyfikacji wynikające z modeli licencjonowania oraz dostępności kodu źródłowego mogą wpłynąć na proces innowacji. Na przykład mogą one być ograniczone, gdy nowe funkcje sprzętowe lub udoskonalenia oprogramowania wymagają zmian na poziomie jądra.
Licencjonowanie open-source pozwala z kolei na modyfikację jądra, a projekty open-source zdecydowanie zachęcają do ich wnoszenia, aby społeczność techniczna mogła skorzystać z postępów. Modele licencjonowania komercyjnego często ograniczają możliwości zmian. Na przykład, jeśli konieczne jest dostosowanie kodu źródłowego jądra, firma komercyjna może przyjąć i ustalić priorytety, a nawet odrzucić prośbę o wsparcie. Zmiany mogą okazać się niemożliwe, jeśli podmiot komercyjny oferujący RTOS zbankrutuje, zakończy swoją działalność, a kod źródłowy nie zostanie umieszczony w otwartym depozycie.
W badaniu Embedded Market Survey 2023, 34% respondentów uznało certyfikację bezpieczeństwa, a 37% widziało je jako kluczową cechę uzupełniającą opcje komercyjne. W wielu branżach, od urządzeń medycznych po systemy radiokomunikacyjne, wymagane są odpowiednie certyfikaty bezpieczeństwa i ochrony. Proces ten może być kosztowny zarówno czasowo, jak i finansowo. Inżynierowie systemów i kierownicy projektów często poszukują oprogramowania wstępnie certyfikowanego, aby skrócić czas dostarczenia, obniżyć wydatki i zmniejszyć ryzyko. Współpraca przy wkładach w oprogramowanie open-source oraz cykle wydawnicze nierzadko są sprzeczne z certyfikacją, która wymaga rygorystycznego procesu (choć projekt ELISA stara się przezwyciężyć tę niedogodność).
W badaniu Embedded Market Survey 2023, 34% respondentów przekonało się do certyfikacji
bezpieczeństwa, a 37% uznało to za istotną funkcję uzupełniającą opcje komercyjne.
(Źródło: embedded.com / AspenCore Media)
Jednakże, jeśli nie przewiduje się modyfikacji jądra, opcje takie jak SAFERTOS firmy High Integrity Systems mogą być wykorzystane w projektach. Z drugiej strony, niektóre otwarte systemy operacyjne czasu rzeczywistego oferują teraz wsparcie długoterminowe (LTS), posiadając zablokowane konfiguracje wersji, zobowiązanie do utrzymania i precertyfikację za pomocą programów takich jak Global Platform SESIP.
Rozważania związane z inżynierią oprogramowania przy wyborze RTOS
Produktywność programistów to główny wskaźnik kluczowy dla szacowania efektywności dla wielu zespołów inżynierii oprogramowania, a ta odnosząca się do systemów osadzonych nie stanowi tutaj wyjątku. Dostarczanie wyników, optymalizacja wydajności oprogramowania i szybkie rozwiązywanie problemów to niektóre z najważniejszych wskaźników. Praca z RTOS może pomóc w budowaniu dobrych praktyk enkapsulacji, ponownego wykorzystania i konserwacji. Szerokie wsparcie ekosystemu opiera się na tych podstawach. Dostępność otwartych źródeł lub komercyjnych bibliotek, narzędzi optymalizacji kompilatora i kodu, a także instrumentów do debugowania i rozwiązywania problemów może istotnie poprawić wydajność zespołu inżynierów oprogramowania, zaangażowanych w tworzenie produktu.
Projekty RTOS i dostawcy często są powiązani z podmiotami open-source i komercyjnymi, którzy dostarczają biblioteki oprogramowania. Duży katalog tychże gwarantuje szybszy dostęp do technologii. Dostępność bibliotek oraz zapewnienie, że dobrze one współpracują z jądrem, ogranicza ryzyko w inżynierii oprogramowania.
Jądro i biblioteki często są dostarczane jako dystrybucja RTOS LTS. Podobnie producenci półprzewodników, tacy jak Espressif, Renesas, STMicroelectronics i Xilinx (obecnie część AMD) serwują RTOS-y poprzez swoje odpowiednie zestawy narzędzi rozwojowych. Dystrybucja oprogramowania nie wyklucza korzystania z bibliotek spoza niej. Wręcz przeciwnie, taka opcja zapewnia zweryfikowaną kombinację poprzez formalne testy integracyjne.
Wsparcie dla optymalizacji kompilatora i kodu źródłowego może być kluczowym czynnikiem dla wydajności systemu wbudowanego i optymalizacji zarządzania pamięcią. Dobrze znane architektury systemów osadzonych, takie jak ARM Cortex-M, cieszą się wsparciem równie powszechnych ekosystemów kompilatorów i optymalizacji kodu źródłowego z wyborem narzędzi open-source i komercyjnych. Otwarty zestaw instrumentów GNU Compiler Collection (GCC) przetrwał próbę czasu. I często jest uważany za standard w wielu zestawach narzędzi programistycznych. Niemniej, dostawcy instrumentów komercyjnych, tacy jak IAR, zapewniają dodatkowe gwarancje i nierzadko są certyfikowane pod kątem bezpieczeństwa. Co zmniejsza ryzyko certyfikacji bezpieczeństwa oprogramowania docelowego urządzenia. Ogólnie rzecz biorąc, ograniczenie wyboru RTOS-ów do tych, które obsługują najbardziej powszechnie stosowane i sprawdzone kompilatory oraz powiązane narzędzia, jest kluczowym czynnikiem decyzyjnym.
Siła ekosystemu leżąca w instrumentach do debugowania i rozwiązywania problemów stanowi główny wskaźnik, że RTOS posiada wsparcie na poziomie produkcji. Często producenci półprzewodników dostarczają systemy debuggerów jako komponenty do zestawów do tworzenia sprzętu. Niemniej w większości przypadków debuggery te na poziomie oprogramowania wykazują możliwość badania prędkości aplikacji, a także śledzenia nakładów przetwarzania, które mogą prowadzić do fałszywie: pozytywnych i negatywnych rezultatów.
Komercyjne opcje, takie jak te od IAR i SEGGER, zapewniają doskonałe wsparcie dla debuggerów z powiązanymi narzędziami oprogramowania środowiskowego RTOS, które przyspieszają rozwiązywanie problemów z RTOS. Szeroko znane oprogramowanie środowiskowe, takie jak Percepio Tracealyzer, które współpracuje z komercyjnymi debuggerami, może dostarczyć dodatkowej, głębszej wiedzy na temat najtrudniejszych wyzwań w dziedzinie rozwoju.
Rozważania dotyczące długoterminowej żywotności aplikacji przy wyborze RTOS
Ostatnim, ale równie ważnym aspektem jest długoterminowa żywotność oprogramowania, zapewniana przez struktury wsparcia, powszechność użycia i trwałość. Te trzy właściwości dają twórcom IoT pewność, że wybrany przez nich RTOS będzie dostępny w przyszłości, co jest kluczowe przy tworzeniu produktów o umiarkowanym lub długim okresie życia. Produkty takie będą nieuchronnie wymagać konserwacji, która obejmuje rozbudowę funkcji i zmienną dynamikę wyzwań związanych z bezpieczeństwem. Wiedza, że RTOS ma udokumentowaną historię, redukuje ryzyko przy dostarczeniu produktu i konserwacji.
Wsparcie społeczności RTOS i komercyjne zapewniają ścieżki rozpracowywania niedogodności, gdy rozwiązywanie problemów inżynieryjnych okazuje się trudne. Jedno i drugie (w tym dostępność wsparcia długoterminowego) uzupełniają się nawzajem. Pomoc społeczności działa dobrze zarówno z perspektywy ogólnego zastosowania, jak i niszowej.
Ponieważ nie ma umowy o poziomie usług (SLA) związanej ze wsparciem społecznościowym, która gwarantuje ostateczne rozwiązanie problemu, czas reakcji może być bardzo zróżnicowany. Jednak często prowadzi do znaczącej informacyjnej opinii zwrotnej. Wsparcie komercyjne przeważnie wiąże się z przypisaną umową SLA, ale zakres wiedzy może być wydatnie bardziej ograniczony. Rozwiązywanie problemów zwykle najlepiej działa, gdy wsparcie społecznościowe jest połączone z tym komercyjnym.
Powszechne użycie RTOS jest silnym wskaźnikiem utrzymania bazy użytkowników, co sygnalizuje dobrą kondycję i solidne projektowanie RTOS. Odpowiednie tworzenie systemów umożliwia rozwój technologiczny pozwalający przetrwać nieuniknioną próbę czasu. Chociaż projekty RTOS mogą podawać liczby użytkowników, to wykazanie powszechności wykorzystania w systemach produkcyjnych często jest trudne, ale udowodnione poprzez opublikowane i zweryfikowane zastosowania. Dokładna analiza szybkości przypadków użycia w całej historii RTOS pokazuje, jak dobrze został on zaakceptowany komercyjnie.
Suma wszystkich czynników
Modele licencjonowania i ograniczenia modyfikacji kodu źródłowego mogą wpływać na to, w jakim stopniu produkt może się dostosować do zmiennych trendów i technologii. Wsparcie ekosystemu narzędzi deweloperskich ma bezpośrednie przełożenie na optymalizację kodu, debugowanie i łatwość użytkowania, co przyczynia się do kosztów rozwoju produktu. Długość życia i udowodnione zastosowania często podkreślają wsparcie społecznościowe i komercyjne, prawdopodobieństwo istnienia zgromadzonej wiedzy inżynierskiej oraz to, jak dobrze RTOS dopasował się do zmiennego krajobrazu technicznego.
Kiedy następnym razem na biurku zespołu produktowego pojawi się decyzja o postawieniu na RTOS, warto rozważyć te kluczowe kwestie, aby zwiększyć zaufanie do dokonanego wyboru.
Źródło: https://www.embedded.com/three-key-factors-in-choosing-a-real-time-operating-system-rtos/
Systemy operacyjne czasu rzeczywistego, popularne w latach 90., przynoszą obecnie wiele korzyści technicznych dla obszernej gamy produktów embedded czasu rzeczywistego. Niektóre z najważniejszych to szybki i niewielki kod programu, wyznaczalna funkcja, szerokie wsparcie w sektorze półprzewodników, strukturalne podejście do projektowania oraz ponowne wykorzystanie oprogramowania poprzez enkapsulację.
RTOS-y zazwyczaj posiadają mikrojądro jako projekt, w którym tzw. scheduler odgrywa kluczową rolę. Budowanie na prostym, a zarazem skutecznym harmonogramie czasu rzeczywistego umożliwia precyzyjne projektowanie systemu. Acz czynniki decydujące o wykorzystaniu konkretnych wykraczają poza podstawy techniczne. Zespoły produkcyjne muszą uwzględnić kwestie biznesowe, inżynierię oprogramowania i długoterminową żywotność przy decydowaniu się na RTOS.
Modele licencjonowania, ograniczenia wobec przebudowywania kodu źródłowego oraz certyfikacja branżowa stanowią najważniejsze zagadnienia biznesowe przy wyborze RTOS. Wszystkie wymienione oddziałują wzajemnie na siebie. Gdy wymagania produktu dotyczą potrzeby możliwości modyfikowania kodu, to może to mieć również wpływ na wybór licencji czy sposobu certyfikacji systemu.
Modele licencjonowania obejmują otwarty kod źródłowy (open-source), komercyjny oraz wersje mieszane. Niektóre z powszechnie stosowanych licencji open-source to MIT-0, Apache 2.0 i Eclipse Public License.
Według badania Embedded Market Survey z 2023 roku, 41% respondentów korzysta z systemu operacyjnego open-source, 20% z open-source z licencjonowaniem komercyjnym, a 21% z licencji komercyjnej. Te ostatnie, tworzone przez podmioty komercyjne, są zazwyczaj własnościowe, a kod źródłowy RTOS nie może być zmieniany ani ponownie dystrybuowany. W wielu przypadkach model licencjonowania mieszanego (kombinacji open-source i opcji komercyjnej) pojawia się, gdy RTOS obejmuje ujęcie open-source i komercyjne, w tym biblioteki firm trzecich. Model licencjonowania bezpośrednio wpływa na możliwość dalszego dystrybuowania kodu i jego modyfikowalność. Ogólnie rzecz biorąc, najbardziej restrykcyjna licencja jest użyta jako punkt odniesienia do omawianych ograniczeń.
Otwarty kod źródłowy czy komercyjny system operacyjny?
Badanie Embedded Market Survey 2023 pokazuje mieszane tendencje.
(Źródło: embedded.com / AspenCore Media)
Ograniczenia modyfikacji wynikające z modeli licencjonowania oraz dostępności kodu źródłowego mogą wpłynąć na proces innowacji. Na przykład mogą one być ograniczone, gdy nowe funkcje sprzętowe lub udoskonalenia oprogramowania wymagają zmian na poziomie jądra.
Licencjonowanie open-source pozwala z kolei na modyfikację jądra, a projekty open-source zdecydowanie zachęcają do ich wnoszenia, aby społeczność techniczna mogła skorzystać z postępów. Modele licencjonowania komercyjnego często ograniczają możliwości zmian. Na przykład, jeśli konieczne jest dostosowanie kodu źródłowego jądra, firma komercyjna może przyjąć i ustalić priorytety, a nawet odrzucić prośbę o wsparcie. Zmiany mogą okazać się niemożliwe, jeśli podmiot komercyjny oferujący RTOS zbankrutuje, zakończy swoją działalność, a kod źródłowy nie zostanie umieszczony w otwartym depozycie.
W badaniu Embedded Market Survey 2023, 34% respondentów uznało certyfikację bezpieczeństwa, a 37% widziało je jako kluczową cechę uzupełniającą opcje komercyjne. W wielu branżach, od urządzeń medycznych po systemy radiokomunikacyjne, wymagane są odpowiednie certyfikaty bezpieczeństwa i ochrony. Proces ten może być kosztowny zarówno czasowo, jak i finansowo. Inżynierowie systemów i kierownicy projektów często poszukują oprogramowania wstępnie certyfikowanego, aby skrócić czas dostarczenia, obniżyć wydatki i zmniejszyć ryzyko. Współpraca przy wkładach w oprogramowanie open-source oraz cykle wydawnicze nierzadko są sprzeczne z certyfikacją, która wymaga rygorystycznego procesu (choć projekt ELISA stara się przezwyciężyć tę niedogodność).
W badaniu Embedded Market Survey 2023, 34% respondentów przekonało się do certyfikacji
bezpieczeństwa, a 37% uznało to za istotną funkcję uzupełniającą opcje komercyjne.
(Źródło: embedded.com / AspenCore Media)
Jednakże, jeśli nie przewiduje się modyfikacji jądra, opcje takie jak SAFERTOS firmy High Integrity Systems mogą być wykorzystane w projektach. Z drugiej strony, niektóre otwarte systemy operacyjne czasu rzeczywistego oferują teraz wsparcie długoterminowe (LTS), posiadając zablokowane konfiguracje wersji, zobowiązanie do utrzymania i precertyfikację za pomocą programów takich jak Global Platform SESIP.
Produktywność programistów to główny wskaźnik kluczowy dla szacowania efektywności dla wielu zespołów inżynierii oprogramowania, a ta odnosząca się do systemów osadzonych nie stanowi tutaj wyjątku. Dostarczanie wyników, optymalizacja wydajności oprogramowania i szybkie rozwiązywanie problemów to niektóre z najważniejszych wskaźników. Praca z RTOS może pomóc w budowaniu dobrych praktyk enkapsulacji, ponownego wykorzystania i konserwacji. Szerokie wsparcie ekosystemu opiera się na tych podstawach. Dostępność otwartych źródeł lub komercyjnych bibliotek, narzędzi optymalizacji kompilatora i kodu, a także instrumentów do debugowania i rozwiązywania problemów może istotnie poprawić wydajność zespołu inżynierów oprogramowania, zaangażowanych w tworzenie produktu.
Projekty RTOS i dostawcy często są powiązani z podmiotami open-source i komercyjnymi, którzy dostarczają biblioteki oprogramowania. Duży katalog tychże gwarantuje szybszy dostęp do technologii. Dostępność bibliotek oraz zapewnienie, że dobrze one współpracują z jądrem, ogranicza ryzyko w inżynierii oprogramowania.
Jądro i biblioteki często są dostarczane jako dystrybucja RTOS LTS. Podobnie producenci półprzewodników, tacy jak Espressif, Renesas, STMicroelectronics i Xilinx (obecnie część AMD) serwują RTOS-y poprzez swoje odpowiednie zestawy narzędzi rozwojowych. Dystrybucja oprogramowania nie wyklucza korzystania z bibliotek spoza niej. Wręcz przeciwnie, taka opcja zapewnia zweryfikowaną kombinację poprzez formalne testy integracyjne.
Wsparcie dla optymalizacji kompilatora i kodu źródłowego może być kluczowym czynnikiem dla wydajności systemu wbudowanego i optymalizacji zarządzania pamięcią. Dobrze znane architektury systemów osadzonych, takie jak ARM Cortex-M, cieszą się wsparciem równie powszechnych ekosystemów kompilatorów i optymalizacji kodu źródłowego z wyborem narzędzi open-source i komercyjnych. Otwarty zestaw instrumentów GNU Compiler Collection (GCC) przetrwał próbę czasu. I często jest uważany za standard w wielu zestawach narzędzi programistycznych. Niemniej, dostawcy instrumentów komercyjnych, tacy jak IAR, zapewniają dodatkowe gwarancje i nierzadko są certyfikowane pod kątem bezpieczeństwa. Co zmniejsza ryzyko certyfikacji bezpieczeństwa oprogramowania docelowego urządzenia. Ogólnie rzecz biorąc, ograniczenie wyboru RTOS-ów do tych, które obsługują najbardziej powszechnie stosowane i sprawdzone kompilatory oraz powiązane narzędzia, jest kluczowym czynnikiem decyzyjnym.
Siła ekosystemu leżąca w instrumentach do debugowania i rozwiązywania problemów stanowi główny wskaźnik, że RTOS posiada wsparcie na poziomie produkcji. Często producenci półprzewodników dostarczają systemy debuggerów jako komponenty do zestawów do tworzenia sprzętu. Niemniej w większości przypadków debuggery te na poziomie oprogramowania wykazują możliwość badania prędkości aplikacji, a także śledzenia nakładów przetwarzania, które mogą prowadzić do fałszywie: pozytywnych i negatywnych rezultatów.
Komercyjne opcje, takie jak te od IAR i SEGGER, zapewniają doskonałe wsparcie dla debuggerów z powiązanymi narzędziami oprogramowania środowiskowego RTOS, które przyspieszają rozwiązywanie problemów z RTOS. Szeroko znane oprogramowanie środowiskowe, takie jak Percepio Tracealyzer, które współpracuje z komercyjnymi debuggerami, może dostarczyć dodatkowej, głębszej wiedzy na temat najtrudniejszych wyzwań w dziedzinie rozwoju.
Ostatnim, ale równie ważnym aspektem jest długoterminowa żywotność oprogramowania, zapewniana przez struktury wsparcia, powszechność użycia i trwałość. Te trzy właściwości dają twórcom IoT pewność, że wybrany przez nich RTOS będzie dostępny w przyszłości, co jest kluczowe przy tworzeniu produktów o umiarkowanym lub długim okresie życia. Produkty takie będą nieuchronnie wymagać konserwacji, która obejmuje rozbudowę funkcji i zmienną dynamikę wyzwań związanych z bezpieczeństwem. Wiedza, że RTOS ma udokumentowaną historię, redukuje ryzyko przy dostarczeniu produktu i konserwacji.
Wsparcie społeczności RTOS i komercyjne zapewniają ścieżki rozpracowywania niedogodności, gdy rozwiązywanie problemów inżynieryjnych okazuje się trudne. Jedno i drugie (w tym dostępność wsparcia długoterminowego) uzupełniają się nawzajem. Pomoc społeczności działa dobrze zarówno z perspektywy ogólnego zastosowania, jak i niszowej.
Ponieważ nie ma umowy o poziomie usług (SLA) związanej ze wsparciem społecznościowym, która gwarantuje ostateczne rozwiązanie problemu, czas reakcji może być bardzo zróżnicowany. Jednak często prowadzi do znaczącej informacyjnej opinii zwrotnej. Wsparcie komercyjne przeważnie wiąże się z przypisaną umową SLA, ale zakres wiedzy może być wydatnie bardziej ograniczony. Rozwiązywanie problemów zwykle najlepiej działa, gdy wsparcie społecznościowe jest połączone z tym komercyjnym.
Powszechne użycie RTOS jest silnym wskaźnikiem utrzymania bazy użytkowników, co sygnalizuje dobrą kondycję i solidne projektowanie RTOS. Odpowiednie tworzenie systemów umożliwia rozwój technologiczny pozwalający przetrwać nieuniknioną próbę czasu. Chociaż projekty RTOS mogą podawać liczby użytkowników, to wykazanie powszechności wykorzystania w systemach produkcyjnych często jest trudne, ale udowodnione poprzez opublikowane i zweryfikowane zastosowania. Dokładna analiza szybkości przypadków użycia w całej historii RTOS pokazuje, jak dobrze został on zaakceptowany komercyjnie.
Suma wszystkich czynników
Modele licencjonowania i ograniczenia modyfikacji kodu źródłowego mogą wpływać na to, w jakim stopniu produkt może się dostosować do zmiennych trendów i technologii. Wsparcie ekosystemu narzędzi deweloperskich ma bezpośrednie przełożenie na optymalizację kodu, debugowanie i łatwość użytkowania, co przyczynia się do kosztów rozwoju produktu. Długość życia i udowodnione zastosowania często podkreślają wsparcie społecznościowe i komercyjne, prawdopodobieństwo istnienia zgromadzonej wiedzy inżynierskiej oraz to, jak dobrze RTOS dopasował się do zmiennego krajobrazu technicznego.
Kiedy następnym razem na biurku zespołu produktowego pojawi się decyzja o postawieniu na RTOS, warto rozważyć te kluczowe kwestie, aby zwiększyć zaufanie do dokonanego wyboru.
Źródło: https://www.embedded.com/three-key-factors-in-choosing-a-real-time-operating-system-rtos/
Cool? Ranking DIY
