Kodowanie własnego sprzętu do testów sieciowych

Wprowadzenie

Jeśli kiedykolwiek spędziłeś czas na ręcznym testowaniu partii komponentów, wiesz, jak pracochłonne i czasochłonne jest to zadanie. Każdy test wykonuje się według tych samych podstawowych kroków, powtarzanych dla każdego testowanego elementu. Zrozumiesz również moc korzystania ze sprzętu testowego, który możesz zaprogramować do wykonania tych kroków za Ciebie, więc wystarczy wszystko ustawić i połączyć, aby móc nacisnąć przycisk i przeprowadzić test. Możesz zaoszczędzić jeszcze więcej czasu, automatyzując konfigurację całego sprzętu testowego jednym kliknięciem myszki komputerowej.

Co jednak, jeśli chcesz stworzyć własny, dedykowany sprzęt testowy, aby dodać go do swojego zautomatyzowanego zestawu testowego? Ten krok po kroku przewodnik pokaże Ci, jak napisać kod, który pozwoli Ci konfigurować sieciowe sprzęty testowe z komfortu Twojego komputera.

Automatyzacja sieciowa eliminuje potrzebę osobnego konfigurowania każdego elementu sprzętu testowego i oszczędza czas, jeśli musisz powtarzać te same testy w przyszłości. Dodatkowym atutem jest to, że przywracanie ustawień po każdym zaniku zasilania lub przypadkowym wyłączeniu sprzętu jest szybkie i proste.

Wprowadzenie do SCPI

Jeśli nie jesteś zaznajomiony z sieciowym sprzętem testowym, musisz poznać Standard Commands for Programmable Instruments (SCPI). W przeszłości Hewlett-Packard wprowadził koncepcję standardowego interfejsu magistrali, który pozwalałby dowolnemu komputerowi z odpowiednim interfejsem połączyć się z dowolnym sprzętem testowym. Ten standard HPIB stał się znany jako General Purpose Interface Bus (GPIB) z własnym oznaczeniem standardu IEEE 488. Standaryzacja ta pozwoliła każdemu elementowi sieciowego sprzętu testowego reagować na polecenia z komputera do wykonania funkcji takich jak wydanie sygnału czy przeprowadzenie pomiaru.

SCPI rozszerzyło zasadę standaryzacji sieciowego sprzętu testowego, dodając dodatkową warstwę dla standardu IEEE-488, aby regulować polecenia komputerowe, które sprzęt testowy mógł rozumieć. To podejście oznacza teraz, że oscyloskop wyprodukowany przez HP będzie reagował na te same polecenia co oscyloskop wyprodukowany przez Keysight. Przed standaryzacją poleceń często różne modele produkowane przez tego samego producenta reagowały na różne polecenia. Ta standaryzacja oznacza, że program kontrolujący sprzęt testowy na komputerze będzie działał z dowolnymi markami i modelami sprzętu laboratoryjnego, więc zmiana sieciowego zasilacza laboratoryjnego na lepszy model nie będzie wymagała zmian w programie kontrolnym.

Standaryzacja ta oznacza również, że każdy kod napisany według tego przewodnika będzie działał w każdym innym laboratorium, jeśli masz ten sam typ sieciowego sprzętu testowego połączony z odpowiednim komputerem.

Wprowadzenie do SCPI

Komendy SPCI mają formę prostych ciągów znaków ASCII, które są dość intuicyjne do odczytania i zrozumienia. Na przykład, wysłanie komendy „*RST” do urządzenia testowego spowoduje jego zresetowanie; wysłanie komendy „*WAI” zainstruuje je, aby poczekało.

Komendy SPCI mogą instruować urządzenie testowe do wykonania akcji lub żądania informacji w zależności od ich formatu. Na przykład, komenda „TIM:ACQT 20ms” zmieni czas akwizycji oscyloskopu na 20ms, podczas gdy komenda „TIM:ACQT?” spowoduje, że zwróci on swój aktualny czas akwizycji.

Ważne punkty do rozważenia to, że komendy nie są wrażliwe na wielkość liter i obsługują formy skrócone, więc na przykład „TRIG SOUR CH1” i „Trigger source Channel1” są obiema ważnymi alternatywami tej samej komendy. Możesz również łączyć komendy, więc na przykład „TRIG SOUR CH1”, „TRIG LEVEL1 10” i „TRIG POL INV” można zapisać jako „TRIG:SOUR CH1;LEVEL1 10;POL INV”, ponieważ wszystkie komendy dotyczą tego samego TRIG. Te komendy ustawiają kanał źródłowy, jego poziom w woltach i polarność. Ten przykład ustawia poziom kanału 1 na 10V z odwróconą polarnością. Nie musisz określać jego wyzwalacza 1, ponieważ jest to założone, ale możesz użyć „TRIG1:”, aby uniknąć niejednoznaczności.

Projekt Kodowania

Towarzyszące temu artykułowi wideo pokazuje, jak stworzyć własne sieciowe urządzenie testowe, które używa komend SCPI. To nawiązuje do poprzedniego wideo pokazującego, jak komunikować się z urządzeniem testowym dla automatyzacji.

Celem tego ćwiczenia jest umożliwienie niestandardowemu sprzętowi testowemu bezproblemowego wpasowania się w dowolne istniejące oprogramowanie testowe, które może obsługiwać komendy SCPI, takie jak te używające LAN eXtensions for Instrumentation (LXI) lub Virtual Instrument Software Architecture (VISA). Ostatecznym celem jest opracowanie kompleksowego, zintegrowanego urządzenia testowego poprzez włączenie mikrokontrolera do automatyzowanego sprzętu testowego.

W sercu projektu znajduje się płyta rozwojowa Infineon XMC4700 Relax Kit, przeznaczona do zastosowań przemysłowych. Płyta zawiera mikrokontroler z pamięcią statyczną i dynamiczną, zegarami, zasilaniem, standardowymi interfejsami i podstawowymi kontrolkami. Zawiera również wbudowane połączenie ethernetowe z adresem kontroli dostępu do medium (MAC) dla sieci.

Kluczową zaletą tej konfiguracji jest dostępność zintegrowanego środowiska programistycznego Digital Application Virtual Engineer (DAVE), które dostarcza Infineon. DAVE to narzędzie do rozwoju oprogramowania i generowania kodu oparte na języku C dla aplikacji mikrokontrolerowych. Umożliwia uproszczenie procesu kodowania, wygodnie obsługując większość zadań konfiguracyjnych, dzięki czemu możesz skupić się na implementacji komend SCPI.

Kod testowy, który stworzymy, będzie odczytywał pozycję przycisku i kontrolował stan diody LED. Ten prosty test będzie stanowił łatwy do zrozumienia przykład i zapewni świetny punkt wyjścia do dalszego eksplorowania mocy i korzyści płynących z automatycznego testowania.

Przewodnik krok po kroku do programowania

Przygotowanie projektu:

Podczas korzystania z narzędzia DAVE dla nowego projektu, pierwszym krokiem jest utworzenie nowego pliku projektu za pomocą sekwencji poleceń „Plik -> Nowy -> Projekt DAVE”. Ta akcja otworzy nowe okno, gdzie można wybrać opcję „Projekt DAVE CE” i nadać mu odpowiednią nazwę.

Następnie musisz wybrać docelowy sprzęt; w tym przypadku jest to zestaw XMC4700 Relax Kit.

Chyba że twój projekt będzie ograniczony zasobami, zawsze dobrą praktyką jest używanie pełnowartościowej standardowej biblioteki newlib zamiast opcji nano-size.

Kolejnym krokiem jest skonfigurowanie peryferiów dla projektu za pomocą polecenia „DAVE -> Dodaj nową aplikację”.

Pierwszą konfiguracją, którą należy ustawić, jest połączenie sieciowe, i robisz to za pomocą polecenia „Ethernet -> ETH_LWIP”, które dodaje do projektu lekki stos protokołu internetowego (IP) do obsługi tego interfejsu.

Musisz również dodać interfejsy wejścia/wyjścia (IO) dla sprzętu testowego, w tym przypadku przycisk i wskaźnik LED. Oba są komponentami dyskretnymi, więc musisz dodać dwie aplikacje „DIGITAL_IO” pod opcją polecenia System, jedną dla każdego elementu.

Dobrą praktyką jest zmiana nazw aplikacji IO na takie, które identyfikują ich funkcje w nazwach, aby ułatwić życie i zapobiec przypadkowemu dostępowi do niewłaściwej aplikacji. Ten błąd może być trudny do zauważenia podczas próby debugowania programu testowego, który zachowuje się nieoczekiwanie.

Musisz również skonfigurować stos IP dla połączenia Ethernet, klikając prawym przyciskiem myszy na „ETH_LWIP App” i wybierając „Konfiguruj instancję aplikacji”. Odkryjesz, że zestaw XMC4700 Relax jest już wstępnie skonfigurowany, co oszczędza czas. Będziesz musiał zmienić statyczny adres IP na stronie ustawień IP, aby dopasować go do podsieci komputera, którego używasz do automatycznych testów. Ponadto, protokół datagramu użytkownika (UDP) nie jest wymagany w tym przykładzie, więc możesz go dezaktywować w zakładce ustawień protokołu.

W końcu musisz zapewnić mapowanie między ustawieniami pinów aplikacji a sprzętem mikrokontrolera, używając opcji ręcznego przydzielania pinów dla każdego komponentu. Aby skonfigurować przycisk dyskretny, kliknij na niego prawym przyciskiem myszy i wybierz polecenie „Ręczny przydział pinów”.

Następnie możesz wybrać odpowiedni numer pinu dla przycisku na zestawie Relax z rozwijanego menu, które wygodnie dostarcza etykiet, aby to ułatwić. Konfiguracja diody LED i połączenia Ethernetowego obie podążają za tym samym procesem. Odkryjesz, że funkcja przydziału pinów upraszcza ten proces, pozwalając wybierać tylko piny z potrzebną funkcjonalnością. Narzędzie automatycznie dostarcza wszystkie etykiety zestawu XMC4700 Relax, aby to ułatwić.

Te kroki kończą konfigurację twojego projektu testowego, i jesteś teraz gotowy do napisania kodu testowego.

Kodowanie aplikacji projektu

Kod dla aplikacji można wygenerować, po prostu klikając przycisk „Generate Code” na pasku narzędziowym DAVE, a następnie czekać na zakończenie operacji.

Przed rozpoczęciem kodowania na poważnie, zalecanym krokiem jest przekierowanie konsoli z mikrokontrolera na komputer, co umożliwia łatwy dostęp do `printf`. Pozwoli to na formatowanie i drukowanie danych, co ułatwi i przyspieszy pisanie oraz debugowanie kodu. Można to zrobić, włączając „GDB Semi-Hosting” w ustawieniach konfiguracyjnych. Można to zrobić, przechodząc do „Project Properties”, następnie do „C/C++ Build”, i wybierając „Settings”.

W sekcji „ARM-GCC, C Linker, Miscellaneous”, musisz dodać „–specs=rdimon.specs” do flag „Other”. Ten krok włącza konfigurację semi-hostingu dla linkera.

Następnie możesz przejść do sekcji „ARM-GCC C Compiler, Preprocessor” i dodać nowo zdefiniowany symbol „XMC_DEBUG_ENABLE”. To ustawienie zapewnia przekierowanie konsoli w konfiguracji debugowania.

W ustawieniach projektu musisz odznaczyć pole wyboru, które zapewnia „default newlib system calls” w ustawieniach „ARM-GCC C Linker, General”. Jeśli pozostawisz to zaznaczone, zauważysz, że przerywa to inicjalizację uchwytu monitora i powoduje niepowodzenie kompilacji.

Następnie musisz zainicjować monitorowanie, co możesz zrobić, dodając „extern void initialise_monitor_handles(void);” na początku swojego kodu. Ta funkcja musi być wywołana po wywołaniu DAVE_Init();.

Zauważ, że pisownia „initialise” jest brytyjską wersją języka angielskiego, ponieważ baza ARM znajduje się w Cambridge, Anglia. Użycie amerykańskiej pisowni spowoduje błąd, który może być trudny do rozwiązania, jeśli nie zauważysz subtelnej różnicy w pisowni.

Kodowanie Sieci Projektu

Pierwszym krokiem w uruchomieniu sieci Ethernet jest włączenie stosu Lightweight IP, aby regularnie sprawdzać nowe wiadomości. Możesz to zrobić, dodając wywołanie funkcji „sys_check_timeouts();” w swojej nieskończonej pętli while, która działa po zakończeniu inicjalizacji.

Ta funkcja będzie wymagała debugowania, aby mogła działać na mikrokontrolerze. Możesz to zrobić, tworząc nową konfigurację debugowania. Zaleca się wyłączenie opcji „Ustaw punkt przerwania przy: main”, aby kod mógł działać od razu po uruchomieniu mikrokontrolera. Wybranie opcji debugowania spowoduje załadowanie nowego kodu do mikrokontrolera.

Możesz potwierdzić, że kod działa, uruchamiając konsolę Windows na swoim komputerze i pingując adres IP płytki rozwojowej, która w tym przykładzie jest XMC4700 Relax Kit. Płyta rozwojowa powinna odpowiedzieć na każde pingowanie, potwierdzając, że działa i połączenie sieciowe jest aktywne.

Kod stosu Lightweight IP automatycznie obsłuży funkcje protokołu Internet Control Message Protocol (ICMP). Jednak musisz stworzyć kod do obsługi przychodzących połączeń i danych protokołu Transmission Control Protocol (TCP). Możesz to zrobić, używając standardowych instrukcji kodu stosu Lightweight IP, które nie są specyficzne dla mikrokontrolera.

Teraz, gdy skonfigurowałeś połączenie sieciowe, możesz ustawić blok kontrolny protokołu, aby nasłuchiwał na porcie 5025, którego używa kod SCPI do komunikacji. Powinieneś skonfigurować stos Lightweight IP, aby delegował wszystkie nowe połączenia do funkcji o nazwie client_accept, którą będziesz musiał rozszerzyć, aby obsługiwać nowych klientów. Wszystkie otrzymane dane będą musiały być przekierowane do oddzielnej funkcji przetwarzającej, która również wyświetli komunikat debugowania, wskazujący na otrzymanie nowego połączenia.

Implementacja metody client_recv skopiuje otrzymane dane do bufora w celu przetworzenia. Ta funkcja powinna również sprawdzać połączenia bez danych, co wskazuje, że zdalny host zamknął połączenie. W takiej sytuacji kod może wykonać czynności porządkowe, aby usunąć niechciane artefakty pozostawione przez zamknięte połączenie.

Kompilacja kodu wygeneruje funkcjonalną kompilację, jeśli nie ma błędów kodowania do debugowania.

Kodowanie projektu IO

Kolejnym krokiem jest konfiguracja „Aplikacji Digital IO” do wykonania wymaganych operacji.

Kliknij prawym przyciskiem myszy na każdą aplikację i wybierz opcję „Konfiguruj instancję aplikacji”. Domyślnym ustawieniem dla komponentów IO jest trójstanowe wejście, idealne dla przycisku. Jednak dla diody LED konieczne będzie zmienienie ustawień na „Wejście/Wyjście” z silnym napędem i miękką krawędzią. Ta konfiguracja silnego napędu zapewnia, że płyta wyprodukuje wystarczający prąd napędowy do oświetlenia diody LED. Konfiguracja miękkiej krawędzi odnosi się do prędkości przejścia krawędzi pinu. Miękka krawędź łagodzi wszelkie przejściowe efekty w sieci dystrybucji mocy i zmniejsza ryzyko negatywnego wpływu na zgodność elektromagnetyczną. Użycie tej opcji dla dyskretnego wyjścia jest dobrą praktyką, chyba że potrzebujesz sygnału z szybkością krawędzi w nanosekundach.

Wygenerowanie zaktualizowanego kodu doda te nowe zmiany do funkcjonalnej kompilacji. Ważne jest, aby zawsze generować kod ponownie po dokonaniu jakichkolwiek zmian w aplikacji DAVE.

Kodowanie projektu SCPI

Po zakończeniu konfiguracji i funkcji inicjalizacji, kodowanie projektu może wreszcie przejść do implementacji poleceń SCPI do testowania. Nie ma potrzeby implementowania poleceń SCPI od zera; wyjątkowa biblioteka SCPI-Parser autorstwa Jana Breuera jest dostępna na GitHubie jako punkt wyjścia.

Możesz skorzystać z tego zasobu, wyodrębniając folder libscpi do folderu Biblioteki twojego projektu. Następnie wyodrębnij foldery scpi-def z „przykłady -> wspólne” do folderu twojego projektu. Ten krok importuje bibliotekę SCPI-Parser i zapewnia dobry punkt wyjścia do implementacji twojego projektu.

Będziesz musiał usunąć folder testowy i makefile w bibliotece libscpi w zintegrowanym środowisku programistycznym DAVE, ponieważ będą one niekompatybilne z używaną biblioteką ARM-GCC.

Następnie wróć do okna właściwości projektu w sekcji „Build, Settings, Compiler, Directories” i dodaj odniesienie do folderu includes libscpi.

Będziesz także musiał otworzyć plik scpi-def.c i dodać instrukcję include dla „dave.h”, aby połączyć twoje funkcje IO z plikiem scpi-def.

Jako uwaga na marginesie, ten plik zawiera fantastyczną demonstracyjną implementację multimetru cyfrowego i funkcje do automatycznego testowania. Niestety, te funkcje są niekompatybilne z kompilatorem ARM używanym w tym przykładzie, więc muszą zostać usunięte. Jednakże, jeśli w przyszłości będziesz musiał zaimplementować własne funkcje, możesz odnieść się do oryginalnych plików w celu uzyskania odniesienia.

Podczas edycji pliku usuń wszystkie funkcje DMM i testowe w bloku konfiguracji poleceń, ale zachowaj kod dla polecenia TST i wszystkie następujące po nim instrukcje, wraz ze standardowymi poleceniami SCPI, które biblioteka będzie obsługiwać.

Możesz zdefiniować informacje identyfikacyjne dla konfiguracji testowej w pliku “scpi-def.h”, więc używanie komendy SCPI *IDN zwróci przydatne informacje w odpowiedzi na każde żądanie identyfikacji.

Możesz ustawić komendy SCPI w pliku projektu “main.c”. Będziesz musiał dodać kontekst SCPI do głównej funkcji, używając właściwości user_context, aby przekazać odniesienie do bloku sterowania protokołem Lightweight IP, co pozwoli na inicjalizację biblioteki SCPI. Następnie musisz dodać swoje funkcje, aby umożliwić libscpi komunikację przez połączenie sieciowe. W tym przykładzie należy zdefiniować następujące funkcje:

• Funkcja “SCPI_Write” pozwala libscpi wysyłać dane przez połączenie sieciowe.

• Funkcja “SCPI_Flush” informuje stos Lightweight IP o natychmiastowym wysłaniu wszelkich danych w buforze.

• Funkcja “SCPI_Error” zapewnia sposób na obsługę błędów SCPI. Dla tego podstawowego przykładu możesz to obejść, wykonując prostą funkcję printf.

• Funkcja “SCPI_Control” to opcjonalna funkcja, która pozwala na pisanie do kanału kontrolnego na porcie TCP 5026, którego nie będziesz potrzebować dla tego przykładu.

• Funkcja “SCPI_Reset” jest wywoływana w odpowiedzi na otrzymanie komendy resetowania, przywracając wszystkie przyrządy testowe do ich domyślnych ustawień. Dla tego podstawowego przykładu nie ma podłączonego sprzętu testowego, więc możesz to obejść, wykonując prostą funkcję printf.

W końcu, user_context musi być ustawiony dla nowego połączenia klienta podczas łączenia się ze stosiem Lightweight IP. Pozwoli to na przekazywanie danych do biblioteki SCPI z bufora za pośrednictwem funkcji client_recv do “SCPI_Input” w celu przetworzenia. Należy zauważyć, że ta implementacja nie obsługuje wielu połączeń jednocześnie, ale reprezentuje dobrą praktykę konfiguracji sieciowej.

Kompilacja zaktualizowanego kodu i przesłanie go do mikrokontrolera powinno skutkować systemem testowym, który nie tylko nadal odpowiada na pingi z konsoli Windows, ale także reaguje na komendy SCPI.

Testowanie kodu SCPI projektu

Ten przykładowy projekt używał aplikacji Rohde & Schwarz VISA Tester do testowania komend SCPI.

Po połączeniu aplikacji z urządzeniem testowym, pierwszym testem jest wydanie żądania tożsamości (IDN?). Jest to zalecany pierwszy krok, a polecenie jest w całości obsługiwane przez bibliotekę SCPI, zapewniając, że komunikacja działa i biblioteka została prawidłowo skonfigurowana. Oznacza to, że rozwiązanie wszelkich problemów związanych z testami wymagającymi odpowiedzi z urządzenia peryferyjnego lub sprzętu testowego może zakładać, że komunikacja i biblioteka nie są podejrzane w procesie debugowania.

Testowanie peryferiów wymaga dodania nowych wzorców do tablicy `scpi_commands` w celu zaimplementowania wymaganych funkcji. Do debugowania funkcjonalności można dołączyć wywołania funkcji „printf”, co stanowi prostą metodę weryfikacji wykonania kodu.

W przykładzie, kod odczytuje stan przycisku za pomocą funkcji „scpi_result_t IO_Btn“ w aplikacji DAVE, która została wcześniej skonfigurowana dla obsługi przycisku, a stan jest wysyłany za pomocą odpowiedzi „SCPI_ResultBool“. Zwracana wartość jest odwracana, ponieważ ten przycisk jest komponentem aktywnym przy niskim stanie.

Funkcja obsługi LED analizuje otrzymany stan przycisku i ustawia odpowiedni stan LED. Jeśli nie istnieją żadne parametry, wtedy w tym przykładzie nie podejmuje się żadnych działań. Ten krok wykorzystuje funkcję „scpi_result_t IO_Led” do wykonania swojej funkcji.

Po zaprogramowaniu mikrokontrolera, możesz przetestować kod za pomocą zakładki Konsola w narzędziu DAVE. To zademonstruje odbiór połączenia i działanie polecenia żądania tożsamości.

Stan przycisku możesz sprawdzić, wysyłając zapytanie SCPI i testując funkcjonalność, obserwując, że zwracany stan zmienia się, gdy naciśniesz przycisk.

Funkcjonalność LED możesz przetestować po prostu wysyłając polecenia włącz i wyłącz, obserwując stan światła i monitorując status konsoli.

Z poprawnie działającymi przyciskiem i LED, masz podstawę do pełni funkcjonalnego instrumentu połączonego z siecią. Połączenie z platformą automatyzacji testów lub napisanie własnego kodu testowego umożliwi zdalne sprawdzanie stanu przycisku i kontrolę LED.

Podsumowanie

Artykuł pokazuje, jak korzystanie ze zintegrowanego środowiska testowego DAVE w połączeniu z płytą rozwojową pozwoli Ci stworzyć i połączyć własne sieciowe urządzenia testowe, aby zintegrować je z wyposażeniem laboratoryjnym i zautomatyzować testy laboratoryjne.

Ten krok po kroku przewodnik jest przeznaczony dla podstawowej demonstracji koncepcji, ale wykonanie kroków i uzyskanie działającego systemu testowego wyposaży Cię we wszystko, co jest potrzebne do stworzenia własnych przyrządów testowych.

Wykorzystamy zasady, które zbadaliśmy w tym projekcie, aby w niedalekiej przyszłości stworzyć praktyczne urządzenie testowe, więc bądź na bieżąco z dalszymi rozwojami.