Page 9 of 23

Wzorce projektowe przydatne w systemach embedded

Wzorce projektowe są bardzo popularnym tematem wśród programistów. Zwykle rozmawia się o nich w kontekście języków obiektowych i dużych systemów. Jednak podobnie jak z innymi zagadnieniami dotyczącymi architektury – część wzorców da się z powodzeniem przenieść na grunt systemów embedded. W dzisiejszym wpisie opowiem o trzech wzorcach z najpopularniejszego katalogu wzorców – książki „Gang of four” – które mogą zrobić najwięcej dobrego w architekturze systemów embedded.

Continue reading

Ewolucja architektury

Dobra architektura nie powstaje od razu. Jest ona raczej wypracowana na bazie różnych doświadczeń. Jednak w większości systemów jest ona określana na sztywno na samym początku, kiedy jeszcze nie mamy wystarczającej wiedzy, aby zrobić ją dobrze. Jest to źródłem wielu problemów z utrzymaniem. Zamiast tego powinniśmy pogodzić się z faktem, że dobre rozwiązania wymagają czasu i umożliwić architekturze ewolucję.

Continue reading

Podstawy architektury embedded – warstwy i moduły

Z czego składa się architektura? Z modułów i warstw. To jest intuicyjny podział wynikający z potrzeby dzielenia złożonych problemów na mniejsze i grupowania podobnych zadań. Jednak o ile co do samego istnienia warstw i modułów nikt nie ma zastrzeżeń, to strategie ich wydzielania zależą często tylko od naszej fantazji. Dzisiaj zdefiniujemy sobie czym są owe moduły i warstwy oraz w jaki sposób powinny być wydzielane. Od razu uprzedzam, że będę tutaj mówił o architekturze dużego systemu realizującego wiele zadań jednocześnie. Duża część projektów embedded jest na tyle prostych, że tak skomplikowana architektura byłaby w nich jedynie obciążeniem.

Continue reading

Problemy z architekturą w systemach embedded

W systemach embedded zwykle skupiamy się na niskopoziomowych interakcjach ze sprzętem. Poznajemy nowe interfejsy, wykorzystujemy kolejne zewnętrzne układy i wykorzystujemy nowe rodziny procesorów. Jednak to z czym sobie naprawdę nie radzimy to poskromienie rosnącej złożoności tworzonych przez nas systemów. W większości systemów prawdziwym problemem jest architektura, czyli systematyczne podejście do radzenia sobie z tą złożonością. Jako branża embedded nie potrafiliśmy do tej pory stworzyć jasnych zasad tworzenia architektury i utrzymywania jej w projekcie. Zwykle dominują dwa podejścia – albo architektury nie ma wcale, albo tworzona jest na początku przed rozpoczęciem kodowania i okazuje się niepraktyczna. W tym wpisie dzielę się swoimi spostrzeżeniami na temat problemów z architekturą w embedded.

Continue reading

Distortos – pierwsze kroki

Distortos to system operacyjny czasu rzeczywistego (RTOS) napisany w C++ z myślą o procesorach ARM Cortex-M, a szczególnie STM32. Pisałem już o nim przy okazji ciekawych projektów C++ Embedded i łazika na NASA Space Apps. Aplikacja na STM w łaziku chyba jednak będzie za prosta, żeby dawać do niej RTOSa, ale ostatnio zacząłem przepisywać Micromouse do C++ i tam już się nada. Źródła distortosa możecie znaleźć na GitHubie, a dokumentację na stronie projektu. Jest on jeszcze w dosyć wczesnej fazie rozwoju, dlatego nie posiada aż tak rozbudowanej dokumentacji i przykładów. Może to być pewną barierą na początku, jednak z czasem na pewno to się zmieni.

Continue reading

Catch2 – framework testowy C++ wspomagający BDD

Ostatnio trochę eksperymentowałem z nowym frameworkiem do unit testów – Catch2. Główną różnicą od innych frameworków takich jak CppUTest czy GoogleTest jest rezygnacja z grup testowych na rzecz struktury Given-When-Then wspierającej Behavior Driven Design (BDD). Inną ważną zaletą jest fakt, że cały framework mieści się w jednym headerze, dlatego nie ma problemów z jego integracją.

Continue reading

Ile kosztuje system safety-critical?

Zwykle przyjmujemy, że koszt wytworzenia systemu safety-critical spełniającego wymagane normy jest dziesięciokrotnie wyższy, niż zwykły projekt posiadający te same wymagania funkcjonalne. Po przeczytaniu poprzednich części serii powinniście mieć całkiem dobre wyobrażenie skąd biorą się dodatkowe koszty. W tym artykule omówię koszty developmentu, zewnętrznego kodu i narzędzi.

Continue reading

SOUP – Wykorzystanie zewnętrznego softu w safety-critical

W większości projektów, gdy mamy możliwość wykorzystania jakiegoś istniejącego rozwiązania, w ogóle się nie zastanawiamy. Dużo publicznego kodu znajdziemy na GitHubie, a w JavaScripcie wychodzi tyle nowych bibliotek, że są one nawet częścią pijackiej gry. Jak już pewnie się domyślacie – w systemach safety-critical sytuacja jest zgoła odmienna. Użycie zewnętrznego kodu podlega specjalnym procedurom i w normach nazywane jest właśnie tytułowym akronimem SOUP, czyli Software of Unknown Provenance, lub Software of Uncertain Pedigree. Nazwy te od razu zwracają uwagę na podstawowy problem tego softu – jego nieznane pochodzenie, historię i proces wytwarzania.

Continue reading