Aplikacja BELIeVE firmy Bermondsey Electronics
HISTORIA
| Pełne imię i nazwisko | Data | Opisać | Wersja |
| Piotr Wrigley | 19/10/2022 | Pierwsze wydanie | 0.1 |
| Piotr Wrigley | 25/10/2022 | Dodaj słownik | 0.2 |
| Piotr Wrigley | 09/02/2023 | Poprawny link, literówki | 0.3 |
| Piotr Wrigley | 23/02/2023 | Dodaj wskazówkę TCP | 0.4 |
WSTĘP
Celem tego dokumentu jest opisanie wewnętrznych mechanizmów aplikacji BELIeVE. Przedstawia użytkownikowi szczegółowy opis konfiguracji projektu i procesu testowania. Ten dokument opisuje wewnętrzne operacje tego procesu, dzięki czemu użytkownicy mogą uzyskać lepszą wartość z produktu.
WAŻNA UWAGA DOTYCZĄCA JINT
Pod maską aplikacja wykorzystuje silnik Jint o otwartym kodzie źródłowym do wykonywania ECMAScript na platformie .NET. Ma to zaletę współdziałania z platformą .NET. Sama witryna Jint dokumentuje niektóre z jej funkcji, takie jak typy .NET używane dla obiektów JavaScript. W chwili pisania tego tekstu używamy wersji 2.11.58, która implementuje ECMAScript v5.1. Podręcznik opisujący język jest dostępny bezpłatnie i zaleca się jego przeczytanie. Od lutego 2023 r. podręcznik znajduje się pod adresem:
https://www.ecma-international.org/wp-content/uploads/ECMA-262_5.1_edition_june_2011.pdf.
USTAWIENIE PROJEKTU
Projekty BELIeVE to zbiór skryptów testowych zorganizowanych w grupy testowe. Skrypty mogą być uruchamiane indywidualnie lub jako grupy. Podczas przebiegów testowych dane są rejestrowane na dysku i w konsoli debugowania.
STWÓRZ PROJEKT
O stworzeniu, projekcie file jest plikiem XML file na dysku. Jego zawartość można edytować ręcznie, jeśli wolisz, ponieważ nie ma specjalnej sumy kontrolnej ani szyfrowania. Domyślnie, obok tworzone są również dwa foldery.
STRUKTURA FOLDERA PROJEKTU
Pomysł na foldery projektu polega na przechowywaniu danych projektu (w formacie szesnastkowym) files, biblioteki DLL itd.) w jednym miejscu, tak aby wszystko, co jest związane z danym projektem, mogło być kontrolowane wersjonowaniem przy użyciu jednego folderu/repozytorium. Folder „Log” jest tworzony wewnątrz folderu „Workspace” podczas pierwszego uruchomienia testu. Jest to tekst file zawiera cały tekst zapisany w oknach „Log” i „Debug” na ekranie głównym i jest najszybszyamped. Dzieje się to automatycznie w czasie wykonywania bez ingerencji użytkownika. File Zapis odbywa się w oddzielnym wątku od głównego środowiska wykonawczego Jint, więc obciążenie środowiska wykonawczego jest minimalne.
GRUPY I TESTY
Testy są podzielone na „Grupy” o wspólnych cechach. Grupy współdzielą „Zmienne grupy testowej”. Są one poprzedzone prefiksem TGVAR i są wyświetlane w autouzupełnianiu. Wspólne zmienne używane w grupie mogą być funkcją produktu, która ma zostać aktywowana, np.ample.
SKRYPTY KONFIGURACYJNE
Każda grupa może mieć skrypt SetUp z nią powiązany. Gdy jest włączony, skrypt SetUp jest wykonywany przed każdym skryptem testowym w grupie.
SKRYPTY DEMONTAŻU
Podobnie każdy test może uruchomić skrypt TearDown po wykonaniu, jeśli jest aktywowany. Kombinacja skryptów SetUp i TearDown może być używana do resetowania celu między skryptami, np.ample. Skrypt TearDown nie jest wykonywany raz na końcu grupy, jest wykonywany po każdym skrypcie w grupie.
SKRYPTY FAILSAFE
Jeśli skrypt pójdzie źle, możesz chcieć podjąć jakieś działania ochronne. Na przykładample, możesz zdecydować się na odłączenie zasilania od DUT. W konfiguracji testu view, jest pole wyboru „Włącz skrypt FailSafe”. Gdy jest zaznaczone, każdy błąd skryptu uruchomi skrypt FailSafe (w tym SetUp i TearDown). Nieobsłużone wyjątki w skrypcie FailSafe powodują przerwanie samego skryptu FailSafe, potencjalnie wcześniej. Należy zauważyć, że jest to powiązane, ale niezależne od pola wyboru „przerwij przy awarii”. Przerwij przy awarii spowoduje wykonanie skryptu FailSafe, jeśli opcja jest włączona, ale oczekuje się, że zostanie użyta do pominięcia uruchamiania dalszych testów po wystąpieniu awarii.
PRZERWIJ W PRZYPADKU NIEPOWODZENIA
Czasami możesz zdecydować się na porzucenie wykonywania grupy testowej, jeśli którykolwiek test się nie powiedzie. Możesz to zrobić, wybierając odpowiednią opcję w interfejsie użytkownika. Skrypt FailSafe zostanie wykonany, jeśli jest włączony, a wykonywanie projektu zakończy się, gdy jakikolwiek ASSERT się nie powiedzie. Ma to na celu przyspieszenie wykonywania, jeśli interesuje Cię tylko zobaczenie, że wszystkie testy zakończą się powodzeniem, a nie kontynuowanie, jeśli którykolwiek test się nie powiedzie. Możesz to uruchomić przed wydaniem DUT, na przykładample.
SZCZEGÓŁOWE WYKONANIE SKRYPTÓW
Przed uruchomieniem skryptu, skojarzone biblioteki DLL są skanowane w poszukiwaniu metody Init() (szablon zawiera pustą metodę). Jest ona uruchamiana przed wszystkim innym, dla wszystkich bibliotek DLL używanych przez projekt, niezależnie od tego, czy te biblioteki DLL mają metody wywoływane w uruchamianym skrypcie. Innymi słowy, dodanie biblioteki DLL do projektu spowoduje uruchomienie jej metody Init() przed każdym skryptem w projekcie. Po zakończeniu tego, generowany jest pewien JavaScript, aby utworzyć zmienne opisane w interfejsie użytkownika (zmienne Group, Test i Machine). Tworzona jest instancja Jint i uruchamia ten automatycznie wygenerowany kod. Skrypt SetUp, gdy jest używany, jest uruchamiany jako następny. Następnie wykonywany jest skrypt testowy. Na koniec skrypt TearDown jest wykonywany, gdy jest używany, w tej samej instancji Jint, co inne skrypty (więc zmienne i instancje są nadal dostępne). W razie potrzeby, skrypt FailSafe może być uruchomiony w dowolnym momencie (ponownie, w tej samej instancji Jint). Po zakończeniu wszystkich tych czynności instancja Jint jest usuwana, a następnie wywoływane są metody DLL Exit() dla każdej biblioteki DLL wymaganej przez projekt. Po zakończeniu tego procesu licznik czasu wykonania w interfejsie użytkownika jest zatrzymywany. Nie ma gwarancji określonej kolejności wykonywania funkcji DLL. Muszą być one zaprojektowane tak, aby działały niezależnie od czynników zewnętrznych. Oznacza to, że każdy skrypt jest uruchamiany w swojej własnej, autonomicznej instancji, bez trwałości. Należy zauważyć, że środowisko, w którym znajduje się DUT, może się zmienić lub nie w tym czasie — będzie to zależeć od tego, jak często urządzenie jest resetowane lub wyłączane. Podczas wykonywania grupy testów skrypty są zazwyczaj uruchamiane w kolejności interfejsu użytkownika z lewego górnego panelu („Project”). Testy można zmieniać kolejność, przeciągając i upuszczając. Na karcie „Test Setup” w polu „Test Group” znajduje się pole wyboru „Randomise test order”, które losowo przetasuje testy. Gdy ta opcja jest włączona, kolejność SetUp->Test->TearDown nie ulega zmianie. Każdy skrypt zostanie uruchomiony raz. Kolejność wykonywania testów jest rejestrowana w dzienniku testów.
USTAL PROGI
DUT są produkowane z tolerancją, tak jak każdy element sprzętu testowego i pomiarowego. ASSERT-y w kodzie muszą radzić sobie z tą tolerancją. Upewnij się, że ASSERT-y ustawiają odpowiednią tolerancję dla testu, który uruchamiasz. Jeśli mierzysz czas na pulpicie, pamiętaj, że dostarczone metody StopWatch są powiązane z zegarem systemowym OS i jego harmonogramem, i odpowiednio zaplanuj.
ZMIENNE
- TSTVAR
Poszczególne zmienne testowe (TSTVAR) są definiowane w interfejsie użytkownika/projekcie filePodobne skrypty testowe można kopiować, wklejać i dostosowywać, np.ample, inny firmware files lub progi. Podświetlanie składni wychwyci te zmienne w edytorze. - TGVAR
Zmienne grupy testowej (TGVAR) mają zastosowanie do wszystkich testów w ramach grupy, ale poza tym zachowują się identycznie jak zmienne TSTVAR. - Zmienna MS
Zmienne specyficzne dla maszyny (MSVAR) są dostosowane do każdego programu testowego. Mogą one definiować takie rzeczy, jak to, którego portu COM należy użyć do komunikacji z urządzeniem szeregowym lub gdzie w filesystem do znalezienia konkretnego fileNowe maszyny można dodawać za pomocą interfejsu użytkownika lub ręcznie w projekcie file. Wewnętrznie aplikacja generuje odcisk palca (który można odczytać programowo za pomocą metody DLL_TOOL.GetMachineFingerprint()). Każdej maszynie można również nadać przyjazną nazwę. Następnie należy dostosować MSVAR-y dla każdego programu uruchamiającego test. W czasie wykonywania testu odcisk palca maszyny jest porównywany z dowolnymi zdefiniowanymi MSVAR-ami w celu zdefiniowania tych zmiennych dla danego programu uruchamiającego.
DLL
- (INNA) WAŻNA UWAGA DOTYCZĄCA JINT
Interoperacyjność Jint udostępnia klasy środowisku wykonawczemu. Oznacza to, że klasy mogą być definiowane w zewnętrznej bibliotece DLL i dostępne w skrypcie za pomocą notacji kropkowej. Te interfejsy nie są koniecznie znane podświetlaczowi składni w czasie pisania testu, więc autouzupełnianie nie jest dostępne. Jint chętnie użyje metod lub elementów klasy zdefiniowanych w bibliotece DLL, nawet jeśli nie są wyróżnione przez interfejs użytkownika. Umożliwia to przekazywanie obiektów podobnych do struktur C między metodami biblioteki DLL a skryptem testowym – przydatne do udostępniania elementów BLE Device Information Service, na przykładample. - METODA GETINFOS()
Aby udostępnić elementy DLL edytorowi testów, można wypełnić metodę GetInfos().ample jest zainstalowany w folderze Dokumenty użytkownika. Metoda GetInfos() zwraca JSON opisujący metody w bibliotece DLL. Zdecydowanie zaleca się postępowanie zgodnie z dostarczonym ogólnym zarysem. Edytor testów wywołuje metodę GetInfos() biblioteki DLL, aby wypełnić opcje autouzupełniania i wyświetlić okno podręczne. Możesz na przykładample, użyj tego do opisania metod pod względem parametrów i typów zwracanych. - ECMASCRIPT JEST JEDNOWĄTKOWĄ, BIBLIOTKI DLL NIE MUSZĄ BYĆ
Co bardzo ważne, ECMAScript ściśle przestrzega jednowątkowego modelu wykonywania. Oznacza to, że skrypty mogą uwzględniać tylko jednowątkowe środowisko. Przerwania i wywołania zwrotne nie są dostępne w skrypcie. Dezorientują środowisko, a wielowątkowy dostęp do skryptów spowoduje awarię środowiska, często z niezrozumiałym kodem błędu i/lub komunikatem. Biblioteki DLL działają w środowisku .NET i nie są przez to ograniczone. Jeśli użytkownik chce uruchomić nowe wątki z metody DLL, nie ma na to żadnych ograniczeń. Użytkownicy muszą uważać, aby skrypty miały dostęp tylko do bezpiecznych wątkowo metod DLL. Na przykład biblioteka DLL może utworzyć wątek, aby rozpocząć komunikację z DUT. Używając metod wielowątkowych, wartości zwracane z DUT mogą wypełnić metodę „GetComms”, którą można bezpiecznie pobrać z wątku Jint. Skrypty i silnik Jint są wykonywane jako pojedyncze wątki, tworzone przez środowisko wykonawcze na żądanie. Każdy wykonywany skrypt testowy jest tworzony w nowej instancji Jint i przekazywane są różne skrypty, jak opisano we wcześniejszych sekcjach. Pomaga to zapobiegać wzajemnemu zanieczyszczaniu się skryptów i zapewnia czyste środowisko wykonawcze za każdym razem, gdy skrypt jest uruchamiany. Narzut Jint nie jest znaczący. Narzuty OS prawdopodobnie będą znacznie wyższe niż przełączanie kontekstu lub czas interpretacji. - METODY INIT/EXIT
Metody DLL Init/Exit powinny być zaprojektowane tak, aby były uruchamiane niezależnie od jakiegokolwiek testu. Biblioteki DLL powinny być przenośne, aby umożliwić ponowne wykorzystanie kodu. Są uruchamiane przed uruchomieniem skryptu i po zakończeniu każdego skryptu FailSafe lub TearDown oraz poza środowiskiem Jint. Nie ma określonej kolejności wykonywania ani obietnic współbieżności dla metod Init i Exit bibliotek DLL.
WSKAZÓWKI JS (Z PERSPEKTYWY AC DEVELOPER)
- DYNAMICZNE PISANIE NIE JEST TYM SAMYM, CO BEZ PISANIA
ECMAScript jest dynamicznie typizowany. Oznacza to, że często konwersję typu można zignorować. Wyjątki stają się wtedy problemem i są zazwyczaj widoczne tylko w czasie wykonywania. ECMAScript udostępnia szereg jawnych metod konwersji typu, które są bardzo wygodne. ParseFloat przyjmie ciąg znaków i zamieni go na double. ParseInt, ParseString itd. są użytecznymi jawnymi metodami konwersji typu, których liberalne stosowanie jest zalecane. Należy zauważyć, że podstawowym typem Number jest double. - WSZYSTKIE TE TWIERDZENIA SĄ TAM Z JAKIEGOŚ POWODU
Środowisko wykonawcze może dynamicznie typować Twoje wartości, więc dostarczone ASSERT-y wymuszają różne typy (w terminologii .NET Common Language Runtime) w używanych porównaniach. Podstawowym typem Jint dla Number jest double, co zmusza nas do podążania pewnymi ciekawymi ścieżkami, więc ASSERT-y są dostarczane w celu ujednoznacznienia procesu. Rozważ każde typizowane ASSERT (np. ASSERT.IS_EQUAL_STRING), aby przeprowadzić jawną konwersję typu przed przetestowaniem warunku ASSERT. Nie jest to nieomylne, więc użytkownik nadal może powodować błędy, na przykładample, przekazując wartość ciągu instrumentu do float ASSERT. Nietypowane ASSERTy będą traktować Numbers jako double, ale wyrzucą błędy czasu wykonania, jeśli zostanie przekazany typ Object. - IVI/VISA/SCIPI ZWYKLE OFERUJĄ STRINGI
Na przykład ciągi znaków takie jak „5.1452E-06A”ample. Jest to wartość rzeczywista zwrócona przez DMM. Aby przekształcić ją w wartość matematyczną, możesz użyć w ASSERT, np.ampnajpierw musisz usunąć „A” na końcu (dla amps). Możesz użyć do tego metody ECMAScript substring. Zauważ również, że ciąg ma właściwość .length, której możesz użyć. Po usunięciu pola jednostek możesz użyć metody parseFloat, aby zwrócić liczbę. Jeśli zdecydujesz się zaimplementować bibliotekę DLL, to autor musi wybrać, jak zaimplementować metody, aby uzyskać liczby. Konwersja typu może nastąpić zarówno w bibliotece DLL, jak i w Jint, ale niezależnie od tego, pamiętaj, że wiele instrumentów obsługuje ciągi, a nie liczby. - GWINTOWANIE
Model wątkowy w ECMAScript jest ściśle jednowątkowy. Nie próbuj tego obejść; kończy się to źle. Testy muszą być zaprojektowane dla operacji jednowątkowych. Użyj bibliotek DLL, aby osiągnąć operację wielowątkową.
WSKAZÓWKI DOTYCZĄCE INSTRUMENTÓW
- NIE WSZYSTKIE INSTRUMENTY SĄ RÓWNE
W zależności od TME może być używane różne formatowanie ciągu.
W zależności od wewnętrznej konstrukcji TME, metoda pobierania jej najnowszej wartości może lub nie może zostać zaktualizowana, jeśli zostanie odczytana zbyt szybko po ostatnim odczycie. Często nie jest to dobrze oznaczone w dokumentacji. Można to wywnioskować z czasu, ale harmonogram systemu operacyjnego może kolidować z precyzyjnym czasem np. metody DLL_TOOL.WaitMs. - NIE WSZYSTKIE INSTRUMENTY Z TEJ SAMEJ SERII SĄ RÓWNE
Byliśmy świadkami problemów z łącznością między urządzeniami, które na pierwszy rzut oka wyglądają identycznie. - DOSTAWCY LUBIĄ WDRAŻAĆ RZECZY SPECYFICZNE DLA DOSTAWCY
W porządku i nie obwiniamy ich. Przeczytaj drobny druk. Podstawowe protokoły mogły nie zostać zaprojektowane dla file transfer, więc podczas transferu fileJeśli korzystasz z obejścia specyficznego dla dostawcy, zachowaj ostrożność i przestrzegaj definicji protokołu. - WYPRÓBUJ INNE INTERFEJSY KOMUNIKACYJNE W SWOIM ZESTAWIE TESTOWYM I POMIAROWYM
Zależy od konkretnego urządzenia, ale TCP/IP może mieć niższe opóźnienie i/lub większą przepustowość niż USB, szczególnie USB przez hub. Warto zbadać możliwości VPN. Używaliśmy aplikacji przez VPN i chociaż występuje wzrost opóźnienia (w przybliżeniu czas pingowania), są chwile, kiedy jest to mniej ważne niż możliwość zdalnego uruchomienia testu. - NAWET SPRZĘT TESTOWY NISKIEJ KLASY MOŻE BYĆ UŻYTECZNY
Jeśli dziś ręcznie wprowadzasz wartości do PSU, to wiesz, ile to zajmuje czasu. Niedrogi nowoczesny multimetr stołowy może zwracać powiedzmy 4-10 odczytów na sekundę. Nadal jest to znacznie szybsze niż ręczne odczytywanie. Oznacza to, że potencjalnie przestarzały starszy TME może nadal służyć użytecznemu celowi. Jeśli potrzebujesz wysokiej dokładności lub wysokiej przepustowości, być może będziesz musiał nabyć TME, aby odzwierciedlić wymagania (nie oferujemy skrótu do wysokiej dokładności i wysokiej sample rates). Dzięki testowaniu automatycznemu, a nie ręcznemu, przebieg testu może być w toku, podczas gdy inne zadania są wykonywane. Zwiększa to wydajność rozwoju – programista nie musi już robić godzinnych przerw, aby uruchomić test wydania i może w międzyczasie pracować nad innymi zadaniami. - PAMIĘTAJ O ZAMKNIĘCIU POŁĄCZEŃ TCP
Jeśli używasz protokołu TCP/IP do połączenia z TME, na TME działa osobna maszyna stanowa. To, że test został ukończony, nie oznacza, że ta maszyna stanowa została zakończona. Jeśli połączenie nie zostanie zamknięte prawidłowo, może ono skończyć się przekroczeniem limitu czasu na celu. Ograniczona pamięć w TME często oznacza, że obsługują one dokładnie jedno połączenie na raz, więc jeśli Twój skrypt nie zamknie prawidłowo połączenia, możesz musieć poczekać, aż wewnętrzna maszyna stanowa na TME przekroczy limit czasu, zanim będziesz mógł się ponownie połączyć. Upewnij się, że Twoje sesje TCP/IP kończą się prawidłowo.
WSKAZÓWKI OGÓLNE
ZAPOMNIJ O PRECYZYJNYM CZASIE NA KOMPUTERZE
Harmonogram systemu operacyjnego można uśpić w jednostkach milisekund. W rzeczywistości, jeśli inny proces blokuje procesor, może wystąpić drgania dwucyfrowe milisekund. Załóżmy, że środowisko wykonawcze pulpitu jest dobre dla dokładności około 30 ms i będzie niewiele problemów. Aby uzyskać lepszą dokładność pomiaru czasu, będziesz potrzebować odciążonego TME. Często używamy zestawów deweloperskich uruchamiających prosty protokół szeregowy do pomiaru czasu PWM, na przykładample. Nasza pierwsza dedykowana stacja testowa była/jest używana NUC8i3 z 8 GB pamięci RAM i dyskiem SSD SATA. Zwykle wynosi ona 10 ms jittera lub do 100 ms, jeśli zapisuje file i musi usunąć blok.
TWÓJ ULUBIONY ZESTAW DEWELOPERSKI JEST NAPRAWDĘ UŻYTECZNY
Czy musisz nacisnąć kilka przycisków? Podłącz zestaw deweloperski do kilku optoizolatorów i napisz trywialny protokół szeregowy. Teraz możesz zamknąć obwód z dowolną dokładnością czasową (i synchronizacją z sygnałami zewnętrznymi), jaką uznasz za stosowną. Dodaj funkcję listy, aby przechodzić przez różne przyciski z różnym czasem. Zaszalej. To najlepszy sposób na osiągnięcie dokładności czasowej poniżej 10 ms bez kupowania dedykowanego sprzętu warsztatowego. Arduino zapewnia kontrolowaną platformę sprzętową i wyprowadzenia obsługujące szereg różnych urządzeń peryferyjnych. Wielu dostawców używa tego wyprowadzenia – wybierz więc swój ulubiony i używaj go.
CZASAMI POTRZEBUJESZ KANAŁU TYLNEGO DO SWOJEGO ZADANIA
Bardzo przydatna jest możliwość symulowania wartości zwracanych przez funkcje lub wywoływania określonych zachowań w DUT. Często najlepiej jest to zrobić poza pasmem za pośrednictwem kanału komunikacyjnego, którego produkt końcowy nie będzie używał, aby oddzielić go od innych działań. Kanał musi zostać usunięty przed produkcją. Typowe polecenia kanału zwrotnego obejmują zmianę czasu systemowego, wywoływanie funkcji, uruchamianie dedykowanego skryptu debugowania na celu itp. Warstwa shim działająca na celu może przechwytywać symulowane wywołania funkcji i podłączać żądane symulowane wartości. Segger RTT jest przydatny na celach Cortex-M.
PRZETESTUJ SWOJE OBSŁUGIWANIE BŁĘDÓW
Nieprzetestowane programy obsługi błędów mogą powodować poważne wady produkcyjne. Użyj systemu, aby je przetestować. Utwórz stany błędów w swoim DUT i upewnij się, że biblioteka dostawcy odpowiednio reaguje. Użyj raportów o błędach w terenie, aby rozszerzyć swój zestaw testów.
MOŻESZ TESTOWAĆ PRZEZ NOC
Stając w obliczu krótkiegotagW przypadku płytek drukowanych TME lub DUT można uruchamiać testy automatyczne w terminach dostosowanych do dostępności sprzętu.
NIECH LUDZIE ZNAJDĄ RZECZY
Można mieć ochotę zresetować DUT między każdym testem lub między grupami testowymi, ale rzadko jest to najlepszy wynik. Randomizer powoduje, że stan DUT jest zachowywany między testami. O ile test nie zawiera wyraźnego wymogu testowania cyklu zasilania, zaleca się, aby nie wyłączać DUT między testami. Pomaga to wyeliminować „jednorazowość” w DUT.
DUŻY LOG FILES MOŻE BYĆ NIEPOKOJĄCE
Dziennik wielogigabajtowy file brzmi kusząco, ale nie jest łatwo otwierać ani przetwarzać. Edytory tekstu i CSV viewers będą mieli kłopoty (nawet te zaprojektowane dla dużych zestawów danych będą w najlepszym razie powolne). Generalnie lepiej jest logować tak mało, jak to konieczne do logowania fileNowoczesne dyski SSD oznaczają przepisywanie dużych plików dziennika files nie jest już źródłem błędów, jakim było w czasach dysków twardych, ale nie czyni to go pożądanym ani koniecznym. Okno konsoli może być alternatywą, ale nie zawsze jest praktyczne. Gdziekolwiek to możliwe, łatwiej jest rozbić duży dziennik na mniejsze files (np. czas, rozmiar).
SŁOWNICZEK
| DUT | Badane urządzenie |
| BLE | Bluetooth o niskim zużyciu energii |
| Dysk SSD | Dysk SSD |
| Dysk twardy | Dysk twardy |
| TME | Sprzęt testowy i pomiarowy |
| Biblioteka DLL | Biblioteka dynamicznie połączona |
| PWM | Modulacja szerokości impulsów |
| Płytka drukowana | Płytka drukowana |
Copyright © 2016-22 Bermondsey Electronics Ltd – Unit B.505, The Biscuit Factory UK Wszelkie prawa zastrzeżone. Niniejsza książka ani żadna jej część nie mogą być powielane ani wykorzystywane w żaden sposób bez wyraźnej pisemnej zgody Bermondsey Electronics Ltd.
Dokumenty / Zasoby
 |
Aplikacja BELIeVE firmy Bermondsey Electronics [plik PDF] Instrukcja obsługi BELIEVE Zastosowanie, Zastosowanie |