Jak projektować z myślą o testowaniu w systemach wbudowanych

| Utworzono: październik 17, 2023 | Zaktualizowano: lipiec 1, 2024

Niezależnie od tego, czy projektujesz szybką płytę PCB, czy złożony system wbudowany, będzie on wymagał pewnego poziomu testowania. Dla zaawansowanych systemów wysokiej prędkości i RF oznacza to zazwyczaj symulacje w porównaniu z pomiarami VNA lub oscyloskopem. Dla oprogramowania wbudowanego i firmware kroki testowania mogą być całkiem inne. W rzeczywistości istnieją pewne rzeczy, które możesz zrobić w swoim projekcie prototypu, aby przyspieszyć proces testowania i wyeliminować potrzebę sondowania multimetrem.

W tym artykule pokażę Ci kilka prostych sztuczek, które mogą ułatwić testowanie i debugowanie prototypu. Oznacza to przyjęcie podejścia projektowania pod kątem testowania i zastosowanie go zarówno do oprogramowania, jak i sprzętu. Oto wskazówka: najlepsza ścieżka dla testowania systemów wbudowanych obejmuje więcej niż tylko umieszczanie padów testowych lub punktów testowych.

Projektowanie pod kątem testowania w sprzęcie wbudowanym

W branży PCB mamy wiele słów kluczowych, a „projektowanie pod kątem testowania” jest zazwyczaj grupowane w szerszym pakiecie DfX. Wielu projektantów będzie podchodzić do projektowania pod kątem testowania dla płyty, która uruchamia wbudowany kod, w ten sam sposób, w jaki podchodziliby do testowania każdej innej płyty.

Zazwyczaj oznacza to, że projektanci umieszczają wiele punktów testowych na ważnych sygnałach, ale może nie wiele więcej. Wiele prototypów wbudowanych zacznie wyglądać jak płytka rozwojowa Arduino, gdzie wszystko, co można sobie wyobrazić na głównym procesorze, jest wyprowadzone do złącz pinowych i punktów testowych.

Nie mam nic przeciwko złączom pinowym na płycie systemów wbudowanych, czy na jakiejkolwiek innej płycie. Ale trudno jest monitorować każdy sygnał i pin, próbując jednocześnie testować i debugować oprogramowanie lub firmware działające na płycie. W niektórych przypadkach musisz faktycznie napisać aplikację tylko po to, aby przetestować swoją aplikację. Czasami, jeśli zauważysz błąd w funkcjach swojego projektu, może nie być oczywiste, czy przyczyna leży w twoim kodzie, czy w twoim PCBA.

Od strony sprzętowej, skup się na przyjęciu tego uproszczonego podejścia do projektowania pod kątem testowania:

Nie wszystko wymaga złącza pinowego. Wyprowadź sygnał do złącza, jeśli faktycznie planujesz go do czegoś podłączyć lub jeśli faktycznie zamierzasz go zmierzyć.
Umieść złącza, których faktycznie możesz użyć. W ten sposób możesz podłączyć się do karty akwizycji danych, analyzera logiki, oscyloskopu itp.
Niech oprogramowanie wykonuje testowanie. Nie zapomnij, że twoja aplikacja wbudowana może odczytywać sygnały z peryferiów, co pozwala budować przypadki testowe w twoim kodzie.
Możesz patrzeć na dane na ekranie, potrzebujesz tylko połączenia z komputerem, takiego jak przez port szeregowy, kartę akwizycji danych lub oprogramowanie własne.

Niektóre z tych koncepcji były szeroko dyskutowane przez Ari Mahpoura w jego dyskusjach na temat testowania i ciągłej integracji. Zapoznaj się z tym artykułem, aby dowiedzieć się więcej na temat tego podejścia. Jeśli chcesz wysyłać dane z powrotem do swojego komputera, najprostszą metodą jest dodanie interfejsu USB-do-serial do twojego prototypu. Zapoznaj się z tym projektem autorstwa Zacha Petersona i pobierz pliki projektowe.

Przypadki testowe w oprogramowaniu wbudowanym

Następnie, jeśli uruchamiasz aplikację wbudowaną na swoim systemie, możesz włączyć obsługę błędów lub przypadki testowe w kodzie, aby przyspieszyć testowanie. Dodanie połączeń do interfejsów z złączami, padami testowymi i podstawowym interfejsem szeregowym to wszystko ważne kroki, które pomagają monitorować twoją wbudowaną płytę w czasie rzeczywistym. Celem jest zobaczenie, jak aplikacja oprogramowania zachowuje się wraz z sprzętem. Więc jak możesz monitorować postępy swojej aplikacji i sprzętu jednocześnie? Weź przykład z programistów oprogramowania: dodaj obsługę błędów i komunikaty, aby wyświetlać status każdej funkcji w twojej aplikacji. Może to być tak proste, jak wyświetlanie komunikatów informujących, czy ważne funkcje zakończyły się sukcesem czy niepowodzeniem w aplikacji. Napisanie wszystkich tych kontroli błędów zajmuje trochę czasu, ale posiadanie komunikatu na ekranie wskazującego, co twoj system robi podczas wykonania aplikacji, może wyeliminować mnóstwo debugowania. Oto przykład, który pokazuje, jak można to zaimplementować w C/C++ za pomocą prostej funkcji (nazwanej myFunction()) i hipotetycznej biblioteki GPIO. Załóżmy, że pracujesz na platformie, która zapewnia prostą bibliotekę GPIO z funkcjami takimi jak gpio_init(), gpio_read() itp.:

#include
#include // dla std::runtime_error
// Hipotetyczna biblioteka GPIO

namespace GPIO {
void init(int pin) {
        // Inicjalizacja danego pinu jako wejście
        // Ta funkcja jest specyficzna dla platformy
    }

bool read(int pin) {
// Odczyt wartości danego pinu (HIGH lub LOW)
// Zwraca true jeśli HIGH, false jeśli LOW
        // Ta funkcja jest specyficzna dla platformy
        return false; // Miejsce na kod, zależne od rzeczywistego sprzętu
    }
}

int main() {
    const int GPIO_PIN = 5; // Numer pinu do odczytu GPIO (wybierz zgodnie z twoją konfiguracją)
    GPIO::init(GPIO_PIN);
    double a = 10.0, b = 2.0;

    // Jeśli sygnał GPIO jest HIGH, ustaw b na zero
    if(GPIO::read(GPIO_PIN)) {
        b = 0.0;
    }
    try {
        double result = myFunction(a, b);
        std::cout << "Wynik: " << result << std::endl;
    }
    catch(const std::exception& e) { // Przechwytuje wyjątki typu std::exception
        std::cerr << "Błąd: " << e.what() << std::endl; // Wyświetla komunikat o błędzie
    }
    catch(...) { // Obsługa wszystkich innych wyjątków
        std::cerr << "Wystąpił nieznany błąd!" << std::endl;
    }
    return 0;
}

Jeśli twoja aplikacja monitoruje sygnały bezpośrednio, może wyświetlać te wyniki na każdym etapie swoich głównych funkcji. Wyświetlanie ich na ekranie wraz z kluczowymi sygnałami wskaźnikowymi pokaże dokładnie, co się dzieje, gdy twoja aplikacja się rozwija, i nie będziesz musiał ręcznie mierzyć każdego sygnału na swojej płytce za pomocą zewnętrznej jednostki. Oczywiście, wymaga to poprowadzenia kilku dodatkowych ścieżek do GPIO podczas projektowania płytki, ale możesz odkryć, że pozorny błąd logiczny był naprawdę tylko prostym błędem połączenia na twojej PCB.

Nie zapomnij, że możesz nadal przekazywać jakiekolwiek inne sygnały, które muszą trafić do sondy, na złącze. W ten sposób te sygnały mogą być nadal mierzone za pomocą oscyloskopu lub karty akwizycji danych. Tymczasem port szeregowy wykona dużą część pracy, pomagając ci wchodzić w interakcję z logiką twojej aplikacji.

Niezależnie od tego, co chcesz zaprojektować, możesz wdrażać innowacyjne praktyki projektowania pod kątem testowania, korzystając z kompletnego zestawu funkcji projektowania PCB w Altium Designer®. Aby wdrażać współpracę w dzisiejszym środowisku interdyscyplinarnym, innowacyjne firmy korzystają z platformy Altium 365™, aby łatwo udostępniać dane projektowe i wprowadzać projekty do produkcji.

To tylko wierzchołek góry lodowej możliwości, jakie oferuje Altium Designer na Altium 365. Zacznij swoją darmową próbę Altium Designer + Altium 365 już dziś.

About Author

Alexsander dołączył do Altium jako Technical Marketing Engineer i wniósł do zespołu wieloletnie doświadczenie inżynierskie. Jego pasja dla projektowania układów elektronicznych w połączeniu z praktycznym doświadczeniem biznesowym zapewnia wyjątkową perspektywę zespołowi marketingowemu Altium. Alexsander jest absolwentem UCSD, jednego z 20 najlepszych uniwersytetów na świecie, gdzie uzyskał dyplom inżyniera elektryka.