Konfigurowanie projektu sprzętu w pętli

Ari Mahpour
|  Utworzono: maj 9, 2021  |  Zaktualizowano: lipiec 1, 2024
Konfigurowanie projektu sprzętu w pętli

W artykule Hardware in the Loop Testing: An Introduction omówiliśmy, czym jest testowanie sprzętu w pętli (HIL), jak wygląda konfiguracja oraz dlaczego warto włączyć to do projektu. Ten artykuł przedstawia przykładowy projekt płytki zaprojektowanej w Altium Designer oraz proces DevOps z wykorzystaniem testowania sprzętu w pętli w stosunku do oprogramowania układowego.

Projekt

Przed przystąpieniem do konfiguracji sprzętu w pętli potrzebujemy płytki do pracy. Dobrym sposobem na rozpoczęcie projektu przed przystąpieniem do schematu i układu jest prototypowanie z wykorzystaniem płytek ewaluacyjnych. Płytką ewaluacyjną, której użyjemy w tym artykule, jest SAM4E XPlained Pro od Microchip (dawniej Atmel). Aby rozpocząć, potrzebujesz tej płytki ewaluacyjnej oraz zainstalowanego Atmel Studio. Gdy sprzęt i oprogramowanie będą działać, możesz sklonować przykładowy projekt z Gitlaba. Ten projekt zawiera minimalną ilość kodu – wystarczającą do demonstracji możliwości sprzętu w testach sprzętu w pętli. Projekt ten wykorzystuje także niektóre biblioteki z Atmel Software Framework (obecnie przemianowanego na „Advanced Software Framework”). ASF zapewnia sterowniki umożliwiające komunikację przez USB, procedury opóźnień i inne biblioteki, które abstrahują wiele niskopoziomowych implementacji sprzętowych, które zazwyczaj są pisane dla innych mikrokontrolerów. Gdy pobierzesz repozytorium, skompilujesz i załadujesz oprogramowanie układowe, będziesz gotowy do konfiguracji i uruchomienia testów sprzętu w pętli.

Konfiguracja

Do kontroli wersji i ciągłej integracji/ciągłego wdrażania (CI/CD) wybrano Gitlab jako hosta. Jak pokazano w How to Create a CI/CD Pipeline for Your PCB Design, kontrola wersji i CI/CD są zintegrowane jako jedno narzędzie w Gitlabie. Projekt ten składa się z wielu etapów CI/CD (znanych również jako „Pipelines” w Gitlabie):

Figura 1: Pipeline Projektu
Figura 1: Pipeline Projektu

Pierwszy etap tworzy pliki binarne potrzebne do załadowania plików programowania na mikrokontroler. Gdy to zostanie zrobione, urządzenie downstream (czyli płytka ewaluacyjna) zostaje włączone. Następnie urządzenie jest programowane i gotowe do testów.

Test

Testowanie sprzętu w pętli może być tak proste lub skomplikowane, jak to zaprojektujesz. Chociaż wiele złożonych systemów HIL wymaga zewnętrznych urządzeń do symulacji środowisk rzeczywistych, ten przykład wykorzystuje podstawowy mechanizm do symulacji bodźca zewnętrznego: komunikację szeregową. Interfejs USB Device CDC firmy Atmel tworzy wirtualny port COM, umożliwiający komunikację przez USB, podobnie jak przez UART za pomocą RS-232. W tej serii testów:

  1. Ustaw rejestr, wysyłając polecenie
  2. Odczytaj rejestr (aby zweryfikować nasze polecenie)
  3. Wyczyść rejestr
  4. Odczytaj rejestr jeszcze raz

Chociaż oprogramowanie układowe dla mikrokontrolera jest napisane w języku C, oprogramowanie testowe (które obsługuje polecenia i odczytuje telemetrię) jest napisane w Pythonie przy użyciu frameworka Pytest. Pisanie oprogramowania w Pythonie pozwala nam korzystać z wysokopoziomowego skryptowania i bibliotek, które normalnie wymagałyby znacznie więcej czasu i wysiłku w języku kompilowanym, takim jak C++. Dodatkowo, możemy uruchamiać te testy na dowolnym typie maszyny, niezależnie od systemu operacyjnego czy architektury układu. Te same testy, które działają na komputerze z systemem Windows (Windows, x86), mogą również działać na Raspberry Pi (Linux, ARM). Abstrakcyjne tworzenie, kompilowanie i testowanie z twojej maszyny jest kluczową zasadą w przepływie pracy DevOps. Chcemy móc odtworzyć nowe środowisko w mgnieniu oka. Co więcej, chcemy uniknąć żmudnych godzin spędzonych na uruchamianiu środowiska deweloperskiego, czytając strony przewodników „Jak zacząć”. Zautomatyzowanie tego procesu (w tym testowania), jak to zostało zrobione w pliku definicji potoku, zapewnia odtwarzalne środowisko bez zbędnych problemów. Aby uruchomić te same testy ręcznie z wiersza poleceń, zobacz plik potoku.

Po zakończeniu testu wyniki są zapisywane do pliku XML JUnit, który następnie jest parsowany przez Gitlab i wyświetlany w interfejsie internetowym.

Rysunek 2: Wynik Testu Jednostkowego
Rysunek 2: Wynik Testu Jednostkowego

Teraz zaprezentowaliśmy pełne rozwiązanie typu end-to-end konfiguracji sprzętu w pętli z Gitlabem. Zapraszamy do zapoznania się z projektem, aby lepiej poznać konfigurację i format.

Podsumowanie

W tym artykule omówiliśmy, jak skonfigurować swój projekt do testowania sprzętu w pętli. Zawierał on przykładowy projekt hostowany na Gitlabie, który użytkownicy mogą sklonować i skonfigurować przy użyciu pliku konfiguracji potoku (tj. pliku .gitlab-ci.yml). Omówiliśmy również uruchamianie testów w Pythonie przy użyciu frameworka Pytest i sposób, w jaki są one wyświetlane w interfejsie internetowym. Użytkownik ma teraz możliwość stworzenia własnej konfiguracji sprzętu w pętli, korzystając z tego przewodnika oraz przykładowego projektu hostowanego na Gitlabie.

Chcesz dowiedzieć się więcej, jak Altium może pomóc Ci w Twoim następnym projekcie PCB? Skontaktuj się z ekspertem w Altium i dowiedz się więcej o podejmowaniu decyzji projektowych z łatwością i pewnością.

About Author

About Author

Ari jest inżynierem z rozległym doświadczeniem w projektowaniu, produkcji, testowaniu i integracji systemów elektrycznych, mechanicznych i oprogramowania. Jego pasją jest łączenie inżynierów zajmujących się projektowaniem, weryfikacją i testowaniem, aby pracowali jako jeden zespół.

Powiązane zasoby

Powiązana dokumentacja techniczna

Powrót do strony głównej
Thank you, you are now subscribed to updates.