Pokazany na fotografii 1 moduł XMC 2Go został opracowany przez firmę Infineon jako zestaw demonstracyjny mikrokontrolera typu XMC1100 oraz środowiska programistycznego o nazwie DAVE, przeznaczonego dla o mikrokontrolerów tej firmy.
W momencie pojawienia się moduł był reklamowany jako prawdopodobnie najmniejszy na świecie zestaw ewaluacyjny mikrokontrolera. Rzeczywiście, jest mniejszy niż typowy pendrive, ponieważ moduł mierzy 38,5 mm długości i 14 mm szerokości.
Miniaturowe rozmiary zestawu XMC 2Go idą w parze z jego wyposażeniem, które jest bardziej niż skromne. Poza mikrokontrolerem XMC1100, zestaw jest wyposażony tylko w dwie diody LED, które mogą być sterowane przez program użytkownika. Dodatkowo, dla użytkownika jest dostępnych 14 linii I/O mikrokontrolera, które są wyprowadzone na pola lutownicze rozmieszczone wzdłuż krawędzi płytki drukowanej.
Do programowania mikrokontrolera XMC1100 służy znajdujący się na tej samej płytce drukowanej logicznychprogramator/debugger zgodny z J-Link. Pełni on również rolę konwertera UART/USB dla układu transmisji szeregowej mikrokontrolera XMC1100. Schemat blokowy modułu XMC 2Go przedstawia rysunek 2.
Zastosowany w zestawie XMC 2Go układ XMC1100-Q24F0064 jest przedstawicielem najprostszej rodziny mikrokontrolerów z rdzeniem Cortex-M w ofercie firmy Infineon. Jest on wyposażony w rdzeń Cortex-M0, 8 kB pamięci ROM, 64 kB nieulotnej pamięci Flash i 16 kB pamięci SRAM. Maksymalna częstotliwość taktowania rdzenia to 32 MHz. Układy peryferyjne, w które jest wyposażony mikrokontroler XMC1100 to:
- trzy równoległe porty GPIO: P0, P1 i P2,
- 4-kanałowy układ typu Capture-Compare CCU4,
- okienkowy watchdog timer WDT,
- zegar czasu rzeczywistego RTC,
- 2-kanałowy uniwersalny interfejs szeregowy USIC0,
- układ zarządzania zdarzeniami i przerwaniami ERU0,
- 6-kanałowy, 12-bitowy przetwornik analogowo-cyfrowy VADC,
- generator pseudolosowy PRNG,
- czujnik temperatury TSE.
Budowa analizatora
Typowy analizator stanów logicznych składa się z dwóch bloków: modułu próbkującego i zapamiętującego poziomy logiczne sygnałów doprowadzonych do wejść pomiarowych oraz modułu wyświetlającego zarejestrowane przebiegi. Pierwszy moduł zazwyczaj jest wykonany w postaci układu elektronicznego, natomiast prezentację zarejestrowanych przebiegów zwykle realizuje program uruchomiony na komputerze PC. Program ten stanowi też interfejs użytkownika umożliwiający obsługę przyrządu.
Opisywany w artykule analizator stanów logicznych ma identyczną budowę. Rolę modułu próbkującego i gromadzącego w swej pamięci stany logiczne mierzonych sygnałów pełni w nim zestaw ewaluacyjny XMC 2Go, natomiast prezentowanie wyników i programowanie parametrów pracy odbywa się za pomocą komputera PC.
Zrealizowany na bazie modułu XMC 2Go układ analizatora stanów logicznych ma następujące parametry:
- Liczba linii wejściowych: 8.
- Zakres napięcia wejściowego: 0...3,3 V.
- Częstotliwość próbkowania wejść (wybierana za pomocą menu): 10 Hz, 20 Hz, 50 Hz, 100 Hz, 200 Hz, 500 Hz, 1 kHz, 2 kHz, 5 kHz, 10 kHz, 20 kHz, 50 kHz, 100 kHz, 200 kHz i 500 kHz.
- Zegar próbkowania wejść: wewnętrzny.
- Wielkość bufora próbek (wybierana): 64 B, 128 B, 256 B, 512 B, 1024 B, 2048 B, 4096 B, 8192 B.
- Wyzwalanie pomiaru dowolną kombinacją poziomów logicznych wejść.
- Obserwacja sygnału przed momentem wyzwolenia w zakresie od 0 do 100% rozmiaru bufora próbek.
- Komunikacja z komputerem PC przez łącze USB (wirtualny port szeregowy 115200 b/s, 8N1).
Mikrokontroler XMC1100 nie należy do najszybszych obecnie dostępnych na rynku, wyposażonych w rdzeń Cortex-M. Nie on jest też wyposażony w żadne sprzętowe obwody wspomagające przesyłanie danych wewnątrz układu, np. kontroler DMA.
W związku z tym, wszystkie funkcje analizatora związane z próbkowaniem stanów wejść oraz ich zapisem w pamięci muszą być realizowane przez mikrokontroler w sposób programowy. Schemat funkcjonalny układu zbudowanego według tej koncepcji przedstawia rysunek 3.
Mierzone sygnały są doprowadzone do wejść In0...In7 analizatora, których rolę pełni 8 linii portu P0. Są one skonfigurowane jako wejścia cyfrowe z aktywnym układem polaryzacji każdego wejścia do masy, dzięki czemu nieużywane w danym pomiarze linie portu P0 mają zawsze ustalony potencjał (poziom niski). Pomiar wejść jest aktywowany na polecenie z komputera PC.
W momencie rozpoczęciu pomiaru startuje generator zegara próbkowania, który zaczyna generować przerwania z częstotliwością równą wybranej częstotliwości pomiaru wejść In0...In7. W roli generatora pracuje kanał CC40 układu Capture-Compare CCU4.
Kanał ten jest skonfigurowany do pracy jako licznik zliczający w górę, który automatycznie restartuje się po osiągnięciu zaprogramowanej wartości. Licznik ten jest taktowany zegarem PCLK o częstotliwości 32 MHz podzielonym w wewnętrznym preskalerze kanału CC40. Okres zliczania licznika jest więc równy:
T = 1/f_PCLK * CC40_PSC * (CC40_PRS + 1)
gdzie :
f_PCLK – częstotliwość zegara układu CCU4 (f_PCLK = 32 MHz). CC40_PSC – stopień podziału wewnętrznego prescalera kanału CC40. CC40_PRS – górny próg zliczania licznika w kanale CC40.
Stopień podziału prescalera CC40_PSC oraz okres zliczania CC40_PRS są każdorazowo programowane, aby uzyskać wybraną częstotliwość pomiaru wejść In0...In7. Osiągnięcie górnej wartości przez licznik skutkuje wygenerowaniem przez kanał CC40 układu CCU4 przerwania.
Ponieważ w mikrokontrolerze XMC1100 źródła przerwań z układów peryferyjnych w ramach danego peryferium nie są na stałe przypisane do określonego wektora przerwań tylko są programowane, w prezentowanym układzie do sygnalizacji przeładowania licznika użyto pierwszego wolnego przerwania układu CCU4, tj. wektora CCU40_0. Szczegóły konfiguracji układu CCU4 oraz jego przerwań przedstawia listing 1.
Właściwy pomiar sygnałów doprowadzonych do wejść analizatora jest realizowany przez funkcję obsługi przerwania CCU4_0 (listing 2). Odczytuje ona stany logiczne wejść In0...In7, kompletuje pojedynczy bajt i zapisuje w buforze próbek, który jest zorganizowany jako bufor kołowy o pojemności 8 kB. W trakcie pomiaru zawsze wykorzystywana jest cała pojemność tego bufora, niezależnie od ustawionego danym pomiarze rozmiaru N bufora próbek, co upraszcza kod funkcji i przyśpiesza jej wykonywanie.
Dopiero przy transmisji zgromadzonych danych do komputera PC z bufora jest pobierane i wysyłane tylko N ostatnich próbek. Po zapisie danych do bufora kontrolowany jest warunek wyzwolenia pomiaru oraz zliczana jest liczba próbek stanów logicznych wejść In0...In7 zgromadzonych od momentu wyzwolenia pomiaru. Po osiągnięciu zadanej liczby próbek N, ich dalsza akwizycja jest zatrzymywana i następuje wywołanie funkcji transmisji danych do komputera PC.
Szybkość obsługi przerwań z kanału CC40 układu CCU4 przez mikrokontroler decyduje o maksymalnej częstotliwości, z jaką analizator jest w stanie próbkować poziomy na swoich wejściach. Przy częstotliwości próbkowania analizatora równej 500 kHz wywołanie funkcji obsługi przerwania oraz jej wykonanie musi trwać nie dłużej niż 64 takty zegara MCLK (przy częstotliwości MCLK równej 32 MHz).
Jest to niewiele, jeżeli uwzględnimy, że w układzie XMC1100 samo opóźnienie pomiędzy momentem zarejestrowania przez układ zgłoszenia przerwania a pobraniem pierwszej instrukcji funkcji obsługi tego przerwania jest równe 21 taktom zegara MCLK, więc na wykonanie kodu funkcji obsługi przerwania pozostają 43 takty zegara MCLK.
W tej liczbie zawierają się również opóźnienia związane z pobieraniem kodu programu z pamięci Flash. Co prawda, karta katalogowa mikrokontrolera XMC1100 nie podaje dokładnych wartości tych opóźnień, ale na podstawie informacji dostępnych na forum poświęconym mikrokontrolerom XMC wiadomo, że opóźnienie związane z odczytem pamięci Flash w układzie XMC1100 nie jest deterministyczne, ponieważ zależy ono od rodzaju dostępu do pamięci Flash, temperatury, a nawet egzemplarza układu.
Przy sygnale zegarowym MCLK większym lub równym od 16 MHz należy liczyć się z tym, że odczyt pamięci Flash będzie obarczony od 1 do 3 cyklami oczekiwania [2.]. Aby uniknąć powyższych opóźnień, funkcja obsługi przerwania CCU40_0 jest wykonywana z pamięci SRAM, która jest wystarczająco szybka i nie wprowadza żadnych cykli oczekiwania. W tym celu funkcja ta została umieszczona w wydzielonej sekcji programu o nazwie ISRAMCode.
W kompilatorze gcc operacja taka jest wymuszana przez dodanie przy deklaracji funkcji polecenia __attribute__((section(".ISRAMCode"))) (listing 2). Odpowiednio zmodyfikowany skrypt linkera XMC_2Go.ld zapewnia, że sekcja ISRAMCode jest linkowana do pamięci SRAM. Automatyczne kopiowanie zawartości tej sekcji z pamięci Flash do pamięci SRAM wykonuje z kolei odpowiednio zmodyfikowany kod startowy zawarty w pliku startup_XMC1100.S.
Zagadnienia modyfikacji kodu startowego i skryptu linkera są dość złożone i wykraczają poza zakres tego artykułu. Osoby zainteresowane tym problemem powinny zapoznać się z dokumentem firmy Infineon pt. "XMC1000 Microcontroller Series for Industrial Applications. C - Start and Device Initialization. Device Guide" [3.]. Pomocna może też być analiza dołączonych do artykułu kodów źródłowych.
W każdym bądź razie z punktu widzenia programisty piszącego kod funkcji obsługi przerwania CCU40_0, poza wymaganą deklaracją __attribute__(...), nie jest konieczne wgłębianie się w zawiłości umieszczania kodu funkcji w pamięci SRAM. Cały ten proces jest dla niego niewidoczny. Programista musi jednak zadbać, aby kod funkcji obsługi przerwania wykonywał się w ciągu maksymalnie wspomnianych wcześniej 43 taktów zegara MCLK.
W tym celu kod funkcji CCU40_0_IRQHandler został napisany pod kątem maksymalnej szybkości wykonania. Z tego właśnie powodu kompletacja stanów logicznych poszczególnych wejść jest realizowana przy pomocy operacji XOR, zamiast typowo spotykanej kombinacji funkcji AND i OR.
Z tego samego powodu poszczególne zmienne używane przez funkcję CCU40_0_IRQHandler zostały zdefiniowane jako pola jednej globalnej struktury sample_buf, a za znacznik wyzwolenia pomiaru służy nie dedykowana zmienna, lecz wyzerowana maska sample_buf.trig_mask sekwencji wyzwalającej pomiar. Fakty te należy mieć na uwadze przy ewentualnym dokonywaniu modyfikacji kodu, ponieważ nawet prosta zamiana kolejności dwóch kolejnych wierszy kodu funkcji CCU40_0_IRQHandler może spowodować, że wzrośnie całkowity czas jej wykonania i nie uda się osiągnąć zakładanej maksymalnej częstotliwości pracy układu analizatora.
Jak wspomniano, wyświetlanie zarejestrowanych poziomów logicznych wejść In0...In7 oraz sterowanie analizatorem są realizowane z poziomu programu uruchomionego na komputerze PC. Komunikację pomiędzy modułem XMG 2Go a komputerem PC obsługuje układ UART.
W jego roli wykorzystano kanał 0 uniwersalnego interfejsu szeregowego USIC0, który został skonfigurowany do pracy w trybie UART o prędkości transmisji 115200 bit/s i formacie znaku 8N1.
Wbudowany w mikrokontroler XMC1100 interfejs USIC0 jest bardzo elastyczny i może on pracować w trybach UART, SPI, I²C, I²S lub LIN, dlatego jego konfigurowanie nie ogranicza się tylko do zaprogramowania generatora prędkości transmisji i wyboru formatu znaku (jak ma to zazwyczaj miejsce przy programowaniu typowego UARTa), lecz obejmuje także takie parametry jak: protokół transmisji, długość i liczba taktów zegara przypadających na jeden bit transmitowanych danych, czy też moment próbkowania sygnału RxD.
Szczegóły konfiguracji układu USIC0 przedstawia listing 3. Ze względu na szczupłość dostępnego miejsca, komentarze w ramce zostały skrócone w stosunku do kodu źródłowego. Pełną wersję opisu kodu konfiguracji układu USIC0 zawierają pliki dołączone do artykułu.
W zestawie XMC 2Go kanał 0 układu USIC0 jest podłączony do programatora / debuggera J-Link, który realizuje funkcję konwertera interfejsu RS na USB. Dzięki temu analizator stanów logicznych komunikuje się z komputerem PC przez łącze USB.
Po stronie komputera PC odwrotną konwersję zapewniają sterowniki programatora / debuggera J-Link. Podłączony do portu USB moduł XMC 2Go jest widoczny w systemie Windows jako urządzenie kompozytowe USB składające się z dwóch urządzeń: J-Link OB CDC oraz Jlink CDC UART Port (rysunek 4). Analizator stanów logicznych XMC 2Go LA wykorzystuje drugie z nich, tj. Jlink CDC UART Port.
Pomimo przedsięwzięcia przedstawionych przy opisie funkcji CCU40_0_IRQHandler środków zaradczych, przy częstotliwości próbkowania analizatora równej 500kHz mikrokontroler XMC1100 praktycznie cały swój czas spędza w funkcji obsługi przerwania CCU40_0. Mogłoby to powodować niedogodności z obsługą analizatora z poziomu programu sterującego w przypadku, gdy ustawiony warunek wyzwolenia pomiaru nigdy nie występuje.
W takiej sytuacji analizator bez końca gromadziłby dane oczekując na wyzwolenie i nie reagował na komendę przerywania pomiaru wysyłaną przez użytkownika z poziomu komputera PC, ponieważ analiza komend przesyłanych łączem szeregowym jest realizowana w analizatorze w pętli głównej programu.
W celi zapobieżenia tej sytuacji, w programie na czas próbkowania stanów wejść In0... In7 aktywowane jest pomocnicze przerwanie USIC0_0 z interfejsu szeregowego USIC0 (listing 3). Przerwanie to ma zaprogramowany wyższy priorytet niż przerwanie z układu CCU4 i jego jedynym zadaniem jest, po odebraniu znaku przez układ UART, wyłączenie próbkowania wejść In0...In7 i przełączenie analizatora w stan oczekiwania na nowe komendy. Kod funkcji obsługi tego przerwania przedstawia listing 4.
Stan pracy analizatora jest obrazowany przez dwie diody LED, w które jest wyposażony moduł XMC 2Go. Mruganie diody LED1 z częstotliwością 0,5 Hz sygnalizuje, że układ jest wolny i oczekuje na skonfigurowanie oraz komendę rozpoczęcia pomiaru, natomiast sam pomiar jest sygnalizowany przez ciągłe świecenie diody LED2.
Oprogramowanie analizatora stanów logicznych zostało stworzone wyłącznie przy użyciu kompilatora GCC, bez użycia wspomnianego wcześniej środowiska programistycznego DAVE. Strukturę projektu programu przedstawia rysunek 5. Foldery _bin i _obj zawierają pliki wynikowe oraz obiektowe projektu.
Z kolei folder Cmsis zawiera standardowe pliki nagłówkowe rdzeni Cortex-M (katalog Cmsis/Include) i plik nagłówkowy z definicjami rejestrów układów peryferyjnych mikrokontrolera XMC1100 (katalog Cmsis/Xmc1100/Include).
W folderze tym znajduje się również plik źródłowy realizujący inicjalizację systemu (Cmsis/Xmc1100/Source/system_XMC1100.c) oraz plik z kodem startowym (Cmsis/Xmc1100/Source/startup_XMC1100.S). Z kolei foldery Inc oraz Src zawierają odpowiednio pliki nagłówkowe i źródłowe programu głównego analizatora stanów logicznych.
Protokół komunikacyjny
Jako protokół komunikacyjny analizatora został zastosowany protokół SUMP [4., 5.]. Pierwotnie był on używany przez analizator stanów logicznych o nazwie Sump Logic Analyzer, lecz później protokół ten był implementowany w wielu projektach analizatorów stanów logicznych tworzonych na licencji Open Source. Najbardziej znanym z nich jest chyba Openbench Logic Sniffer (w skrócie OLS).
Główną zaletą implementacji protokołu SUMP we własnym projekcie jest możliwość wykorzystania w charakterze programu sterującego analizatorem oprogramowania stworzonego dla analizatora OLS.
Ponieważ prezentowany układ analizatora na bazie zestawu XMC 2Go ma znacznie mniejsze możliwości niż analizator OLS, nie było potrzeby implementacji pełnego protokołu SUMP. Tabela 1 zawiera listę komend protokołu SUMP zaimplementowanych w oprogramowaniu analizatora XMC 2Go LA.
Program dla komputera PC
Jak już wspomniano, do ustawiania parametrów pracy analizatora XMC 2Go LA, oraz do obrazowania zarejestrowanych poziomów logicznych sygnałów doprowadzonych do jego wejść, może zostać użyty dowolny program klienta obsługujący protokół SUMP. W prezentowanym projekcie zastosowano do tego celu program o nazwie OpenBench LogicSniffer (w skrócie OLS), którego autorem jest Jan Willem Janssen [6.].
Jest to chyba najlepszy program klienta SUMP dostępny na licencji Open Source. W chwili pisania artykułu ostatnia opublikowana wersja programu OLS nosiła numer 0.9.7.1, jednak jak wykazały próby, nie zawsze pracuje ona stabilnie. Zaobserwowano, że występują w niej problemy z automatyczną identyfikacją dołączonego modułu analizatora. W związku z tym do pracy z analizatorem XMC 2Go LA polecana jest poprzednia wersja klienta OLS o numerze 0.9.7.
Program OLS został napisany w języku Java. Może więc być uruchamiany w wielu systematach operacyjnych, w tym w systemie MS Windows oraz Linux. Sam program OLS nie wymaga instalacji. Po pobraniu go ze strony autora i zapisaniu na dysku w wybranym katalogu należy jedynie w folderze plugins dodatkowo umieścić plik konfiguracyjny o nazwie ols.profile-xmc2go.cfg (listing 5).
Plik ten jest dołączony do kodu źródłowego opisywanego analizatora i zawiera definicje obsługiwanych przez analizator XMC 2Go LA trybów pracy, dostępnych częstotliwości próbkowania wejść, rozmiarów buforów próbek, kolejności przesyłanych próbek sygnałów, itp.
Najważniejszym parametrem konfiguracyjnym analizatora zdefiniowanym w pliku ols.profile-xmc2go.cfg jest natywna częstotliwość sygnału zegarowego analizatora device.dividerClockspeed. Na jej podstawie program OLS wylicza, w zależności od wybranej częstotliwości próbkowania stanów wejść, wartość podziału dzielnika częstotliwości, która jest programowana w urządzeniu.
W przypadku analizatora XMC 2Go wartość parametru device.dividerClockspeed musi być równa 32000000 (tj. 32 MHz). Inaczej rzeczywista częstotliwość próbkowania stanów wejść analizatora nie będzie odpowiadała wartości wybranej w programie OLS.
Należy to mieć na względzie przy samodzielnej modyfikacji pliku konfiguracyjnego, lub też używaniu konfiguracji innego urządzenia, ponieważ większość plików konfiguracyjnych dla popularnych analizatorów stanów logicznych dostarczana razem w programem OLS zakłada, że natywna częstotliwość sygnału zegarowego analizatora jest równa 100 MHz.
Drugim ważnym parametrem konfiguracyjnym zapisanym w pliku ols.profile-xmc2go.cfg jest definicja klucza tekstowego device.metadata.keys. Program klienta OLS wykorzystuje ją do automatycznego rozpoznawania typu dołączonego analizatora stanów logicznych. W przypadku modułu XMC 2Go LA wartość tego klucza powinna być równa "XMC2GO LA v1.0".
Pozostałe parametry konfiguracyjne zdefiniowane w pliku ols.profile-xmc2go.cfg nie mają już tak newralgicznego znaczenia dla działania analizatora. Informują one program OLS o poszczególnych trybach pracy, które są obsługiwane przez urządzenie. Dzięki temu w programie OLS aktywne są tylko te funkcje analizatora, które są obsługiwane przez podłączony moduł.
Sposób obsługi programu OLS nie różni się znacząco od obsługi innych tego typu aplikacji. Po uruchomieniu programu należy wybrać numer portu szeregowego COM, do którego podłączony jest analizator i przyciskiem Show device metadata dokonać identyfikacji modułu analizatora.
Jest to jednocześnie test poprawności komunikacji programu klienta OLS z analizatorem. Jeżeli operacja przebiegnie pomyślnie, program OLS powinien wyświetlić typ urządzenia i jego podstawowe dane oraz uaktywnić odpowiadającą mu konfigurację pracy (rysunek 6). Rodzaj dołączonego modułu analizatora może też zostać wybrany ręcznie z rozwijanej listy.
W kolejnym OLSkroku należy określić częstotliwość, z jaką analizator będzie próbkował stany swoich wejść oraz rozmiar bufora próbek (rysunek 7). Całkowity czas rejestrowania sygnału będzie w takiej sytuacji oczywiście równy iloczynowi wielkości bufora próbek i okresu próbkowania. W razie potrzeby możliwe jest też określenie momentu wyzwolenia pomiaru poziomów logicznych wejść analizatora oraz sekwencji wyzwalającej pomiar (rysunek 8).
W obecnej wersji oprogramowania analizator XMC 2Go LA obsługuje tylko tryb wyzwalania równoległego pojedynczą kombinacją poziomów logicznych wejść In0...In7. Nie jest natomiast obsługiwane ani wyzwalanie sekwencją kolejnych stanów logicznych wejść In0...In7, ani też sekwencją szeregową stanów logicznych wybranego wejścia.
Po zakończeniu pracy analizatora, program OLS powinien wyświetlić zarejestrowane przez moduł analizatora stany logiczne wejść In0...In7. Przykładowy, uzyskany w trakcie testów układu analizatora sygnał przedstawia rysunek 9.
Możliwości programu OLS nie ograniczają się tylko do prezentacji w postaci graficznej zarejestrowanych przez analizator stanów logicznych wejść. Sygnały te mogą zostać poddane w programie OLS dalszej analizie.
Poza standardowymi pomiarami parametrów sygnału za pomocą kursorów, program OLS oferuje też automatyczną analizę magistral szeregowych. Na liście obsługiwanych magistral znajdują się między innymi takie interfejsy jak: 1-wire, DMX512, i2c, SPI, JTAG oraz UART. Przykład automatycznej analizy przez program OLS sygnału portu szeregowego przedstawia rysunek 10.
Podsumowanie
Przedstawiony analizator stanów logicznych nie bije ani rekordów prędkości rejestracji sygnałów, ani też rekordów w liczbie obsługiwanych wejść. Pod tym względem nie może się on równać z profesjonalnymi przyrządami pomiarowymi. Tym niemniej, jak pokazują przykłady z rys. 9 i 10, do obserwacji i analizy sygnałów o średniej szybkości zmian jest on zupełnie wystarczający.
W tym zakresie analizator XMC 2Go LA może realnie wspomóc konstruktora przy diagnozowaniu błędów w budowanym układzie czy też w pisanym programie. Dysponując zestawem ewaluacyjnym mikrokontrolera o większych możliwościach, w oparciu o powyższy projekt można zbudować analizator stanów logicznych działający szybciej, obsługujący większą liczbę wejść, czy też mający większy bufor danych.
Aleksander Borysiuk
alex_priv@wp.pl
Bibliografia:
- Evaluation Board For XMC1100 Family. XMC 2Go Kit with XMC1100. Kit Version 1.0. Board User's Manual, Revision 1.0, Infineon Technologies AG, 2014
- Infineon Forums. Microcontroller Forum. XMC Forum. XMC1100 NVM wait states documentation, http://goo.gl/Hxxawq
- XMC1000 Microcontroller Series for Industrial Applications. C - Start and Device Initialization. Device Guide, V1.0, Infineon Technologies AG, 2013
- SUMP Communications Protocol, http://goo.gl/7IKs57
- The Logic Sniffer's extended SUMP protocol, http://goo.gl/EIqRE8
- OpenBench LogicSniffer Client, http://goo.gl/pXWD4E