|
Arabic
Bengali
Chinese
English
French
German
Hebrew
Hindi
Italian
Japanese
Korean
Malay
Polish
Portuguese
Spanish
Turkish
Ukrainian
Vietnamese
ENCYKLOPEDIA RADIOELEKTRONIKI I INŻYNIERII ELEKTRYCZNEJ Mikrokontrolery dla początkujących i nie tylko. Encyklopedia elektroniki radiowej i elektrotechniki
Encyklopedia radioelektroniki i elektrotechniki / Mikrokontrolery PIERWSZE SPOTKANIE Na początek kilka słów dla tych, którym temat cyklu, sądząc po tytule, wydaje się a priori nieciekawy lub „obcy”. Być może nie używałeś jeszcze mikrokontrolerów w swoich projektach (dalej skrótowo MK) i myślisz, że w dającej się przewidzieć przyszłości będziesz mógł się bez nich obejść. Możliwe jest również, że zakładasz, że zbudowanie systemu mikrokontrolera w celu rozwiązania twojego problemu byłoby zbyt uciążliwe i nieopłacalne ekonomicznie. Nie spiesz się: specjalnie dla Ciebie chcemy podać kilka faktów i trochę statystyk. Weźmy na przykład najbliższego krewnego MK - komputer osobisty - i porównajmy intensywność ich użytkowania. Według firmy analitycznej Loewenbaum & Co. Inc. (USA) liczba komputerów osobistych wydanych na świecie w 1997 roku osiągnęła około 20 milionów sztuk. Zgadzam się, to dużo. Teraz wyobraźcie sobie, że ta gigantyczna liczba to tylko 0,2% światowej produkcji MK. Według firmy analitycznej IC Insights Inc. (USA) rynek światowy w 1998 roku wchłonął ich ponad 13,5 miliarda! Wniosek nasuwa się sam. Jeśli nawet dzisiaj trudno jest znaleźć dziedzinę działalności człowieka, w której komputer nie byłby efektywnie wykorzystywany, to co możemy powiedzieć o MK? Dlaczego stały się tak popularne i dosłownie niezastąpione? Odpowiedź leży w samej strukturze mikrokontrolera. Jako pierwsze przybliżenie definicji tego pojęcia możemy przyjąć, że MC to komputer umieszczony w jednym mikroukładzie. Stąd jego główne atrakcyjne cechy: małe wymiary, zużycie, cena; wysoka wydajność, niezawodność oraz możliwość dostosowania do wykonywania szerokiej gamy zadań. MK różni się od mikroprocesora tym, że oprócz jednostki centralnej (CPU) zawiera pamięć i liczne urządzenia wejścia / wyjścia: przetworniki analogowo-cyfrowe, szeregowe i równoległe kanały informacyjne, zegary czasu rzeczywistego, szerokość impulsu modulatory (PWM), programowalne generatory impulsów itp. W swojej strukturze i zasadzie działania MK w zasadzie nie różni się od komputera osobistego. Dlatego słowa mikrokontroler i mikrokomputer są synonimami. Jednak pierwszy termin (od angielskiego słowa control - management) jest bardziej powszechny, ponieważ odzwierciedla jego główny cel - zastosowanie w automatycznych systemach sterowania wbudowanych w różne urządzenia: karty kredytowe, aparaty fotograficzne, telefony komórkowe, stereo, telewizory, magnetowidy i kamery, pralki, samochody, kuchenki mikrofalowe, systemy antywłamaniowe, układy zapłonowe silników benzynowych, napędy elektryczne lokomotyw, reaktory jądrowe i wiele, wiele innych. Wbudowane systemy sterowania stały się zjawiskiem tak masowym, że właściwie powstała nowa gałąź gospodarki, zwana Embedded Systems (ang. Embedded systems - ang.). Obecnie na świecie produkuje się tysiące odmian MK. Dostarczane są w pakietach od 8 do 356 pinów, pracują w temperaturach od -55 do +125oC przy częstotliwościach od 32 kHz do 200 MHz, mogą pracować przy napięciu zasilania 1,2 V, pobierając prąd nie przekraczający kilku mikroamperów . . Ceny produktów również stale spadają. Niektóre ośmiobitowe mikrokontrolery kosztują już dziś nie więcej niż 50 centów, co jest porównywalne z kosztem jednego układu „twardej logiki”. Wszystko to doprowadziło do tego, że dziś coraz trudniej jest znaleźć obszar działalności człowieka, w którym MC nie znalazłoby zastosowania, a proces ich dystrybucji ma charakter lawinowy. Mamy nadzieję, że powyższe fakty skłoniły Cię już do pełnego szacunku stosunku do głównego bohatera naszej opowieści. Rzeczywiście, MC stało się wydarzeniem globalnym, atakującym prawie wszystkie rodzaje działalności człowieka. Co zapewniło tak szybki wzrost popularności tych produktów, który pojawił się nieco ponad 25 lat temu? Czym są te urządzenia i jakie są ich możliwości oraz perspektywy? Jeśli nie korzystałeś jeszcze w swojej działalności z MC lub opartych na nich systemów, to tak. może czas o tym pomyśleć? A jeśli zdecydujesz się zastosować MK, to jaka powinna być kolejność twoich działań? Jakie trudności mogą cię czekać, co może ci pomóc po drodze? Na te pytania postaramy się odpowiedzieć w proponowanym cyklu artykułów. PRAWO MOORE'A I PIERWSZY MK Już w 1965 roku Gordon Moore, jeden z przyszłych założycieli potężnej korporacji Intel, zwrócił uwagę na ciekawy fakt. Po sporządzeniu wykresu wzrostu wydajności układów pamięci odkrył ciekawy wzór: nowe modele układów pojawiały się co 18 do 24 miesięcy, a ich pojemność za każdym razem w przybliżeniu się podwajała. Jeśli ten trend się utrzyma, zasugerował G. Moore, moc urządzeń komputerowych wzrośnie wykładniczo w stosunkowo krótkim czasie. Prognoza G. Moore'a została następnie znakomicie potwierdzona, a odkryta przez niego prawidłowość jest obserwowana do dziś iz zadziwiającą dokładnością, będąc podstawą licznych prognoz wzrostu produktywności. W ciągu 28 lat, które upłynęły od pojawienia się mikroprocesora 4004 (1971), liczba tranzystorów w chipie wzrosła ponad 12 000 razy: z 2 do 300 28 000 w chipie Sorretta. Otóż w 1976 roku wykładniczy rozwój technologii półprzewodnikowej doprowadził do stworzenia przez firmę Intel pierwszego MK - 8048. Oprócz procesora zawierał on pamięć programu, pamięć danych, ośmiobitowy timer oraz 27 linii I/O . Dziś 8048 to już historia, ale kolejny produkt, wydany przez Intela w 1980 roku, wciąż żyje i ma się dobrze. To jest MK8051. ARCHITEKTURA MK 8051 Ten MK można uznać za klasyczny model, na którego obraz i podobieństwo powstało później wiele innych produktów. Jego schemat blokowy pokazano na ryc. 1. CPU - główny węzeł MK. Jest to związane z tak ważną koncepcją, jak system dowodzenia.
Zestaw instrukcji to unikalny zestaw kodów binarnych specyficznych dla danego procesora, który definiuje listę wszystkich jego możliwych operacji. Każdy taki kod definiuje jedną operację i jest nazywany kodem operacji lub komendą. Im więcej kodów użytych w zestawie instrukcji, tym więcej operacji może wykonać procesor. MK 8051 jest ośmiobitowy, więc jego kody operacji mają rozmiar 8 bitów. Teoretycznie może istnieć łącznie 256 ośmiobitowych kodów operacji. 8051 wykorzystuje 255. W zależności od liczby użytych kodów operacji, systemy instrukcji dzielą się na dwie grupy: CISC i RISC. Termin CISC oznacza złożony system poleceń i jest skrótem angielskiej definicji Complex Instruction Set Computer. Podobnie, termin RISC oznacza zredukowany zestaw instrukcji i pochodzi od angielskiego Reduced Instruction Set Computer. System dowodzenia MK 8051 można przypisać typowi C15C. Jednak pomimo powszechnego stosowania tych pojęć, należy uznać, że same nazwy nie odzwierciedlają zasadniczej różnicy między systemami dowodzenia CISC i RISC. Główną ideą architektury RISC jest staranny dobór takich kombinacji kodów operacji, które mogłyby być wykonane w jednym cyklu generatora zegara. Główną korzyścią z takiego podejścia jest znaczne uproszczenie implementacji sprzętowej procesora i możliwość znacznego zwiększenia jego wydajności. Początkowo takie podejście można było wdrożyć jedynie poprzez znaczne zmniejszenie zestawu instrukcji, stąd narodziła się nazwa RISC. Na przykład zestaw instrukcji MK z rodziny Microchir PIC zawiera tylko 35 instrukcji i może być sklasyfikowany jako RISC. Oczywiście w ogólnym przypadku kilka instrukcji architektury RISC musi odpowiadać jednej instrukcji architektury CISC. Jednak wzrost wydajności dzięki architekturze RISC zwykle przewyższa straty wynikające z mniej wydajnego zestawu instrukcji, co skutkuje wyższą wydajnością całego systemu RISC w porównaniu z CISC. Więc. najszybsza komenda MK 8051 jest wykonywana w 12 cyklach. Nawet jeśli dla każdej instrukcji trzeba wykonać trzy instrukcje kontrolera RISC, ostatecznie architektura RISC zapewni czterokrotny wzrost wydajności. Po drodze architektura RISC pozwala rozwiązać szereg zadań. Rzeczywiście, wraz z uproszczeniem procesora liczba tranzystorów niezbędnych do jego realizacji maleje, dlatego zmniejsza się powierzchnia kryształu. Powoduje to zmniejszenie kosztów i zużycia energii. W tym miejscu można by wykrzyknąć: przyszłość należy do architektury RISC! Jednak granica między tymi dwoma pojęciami szybko się zaciera. Na przykład. Mikrokontrolery z rodziny AVR firmy Atmel mają zestaw instrukcji składający się ze 120 instrukcji, co odpowiada typowi CISC. Jednak większość z nich jest wykonywana w jednym cyklu, co jest cechą charakterystyczną architektury RISC. Obecnie powszechnie przyjmuje się, że główną cechą architektury RISC jest wykonywanie instrukcji w jednym cyklu generatora zegara. Sama liczba poleceń nie ma już znaczenia. Generator zegara generuje impulsy w celu synchronizacji pracy wszystkich węzłów urządzenia. Częstotliwość ich powtarzania można ustawić za pomocą rezonatora kwarcowego lub obwodu RC podłączonego do wyjść MK. W niektórych MK tryb pracy generatora zegara jest zapewniony bez użycia elementów zewnętrznych. W tym przypadku częstotliwość impulsów zegarowych zależy od parametrów kryształu, które są określane podczas jego produkcji. ROM to urządzenie pamięci tylko do odczytu przeznaczone do przechowywania programów, dlatego pamięć ta jest często nazywana pamięcią kodu lub pamięcią programu. Do niedawna istniały dwa główne typy pamięci ROM - maskowane i programowalne. Informacje są wprowadzane do pamięci ROM masek podczas procesu produkcyjnego MC przy użyciu szablonów technologicznych - masek. Nie można go zmienić po zakończeniu cyklu produkcyjnego. Takie ROMy są używane tylko w przypadkach, gdy jakość programu nie budzi wątpliwości i istnieje ogromne zapotrzebowanie na MK z tym konkretnym programem. Zaletą maskowych ROM-ów jest najniższy koszt w masowej produkcji (od kilku tysięcy sztuk). Programowalna pamięć ROM jest zapisywana za pomocą urządzenia zwanego programatorem. MK z takimi ROMami są dwojakiego rodzaju: jednorazowo i wielokrotnie programowalne (przeprogramowalne). Te pierwsze, jak sama nazwa wskazuje, pozwalają tylko na jednorazowe zaprogramowanie, po którym nie ma już możliwości wykasowania informacji (MK z pamięcią OTP - z ang. One Time Programmable). Stosowane są w produkcji małoseryjnej (do 1000 sztuk). gdy użycie maski MK nie jest ekonomicznie uzasadnione. Mikroukłady wielokrotnie programowalne dzielą się na MK wyposażone w pamięć ROM z kasowaniem przez promieniowanie ultrafioletowe (dostępne w pakietach z „okienkiem”) oraz MK z pamięcią elektrycznie reprogramowalną. Wadą MC z ROM z wymazywaniem przez promieniowanie ultrafioletowe jest bardzo wysoki koszt i stosunkowo niewielka liczba cykli zapisu/kasowania (zależy od całkowitej dawki napromieniowania kryształu i zwykle nie przekracza 15...20) Obecnie coraz bardziej popularna staje się nowa technologia implementacji pamięci ROM - pamięć Flash. Jego główną zaletą jest że jest zbudowany na zasadzie przeprogramowalności elektrycznej. tj. umożliwia wielokrotne kasowanie i zapisywanie informacji za pomocą programistów. Minimalna gwarantowana liczba cykli zapisu/kasowania zwykle przekracza kilka tysięcy. To znacznie wydłuża cykl życia i zwiększa elastyczność systemów MC. ponieważ pozwala na wprowadzanie zmian w programie MC zarówno na etapie rozwoju systemu, jak i podczas jego pracy w rzeczywistym urządzeniu. RAM to pamięć o dostępie swobodnym używana do przechowywania danych, dlatego ta pamięć jest również nazywana pamięcią danych. Liczba cykli odczytu i zapisu w pamięci RAM nie jest ograniczona, ale wyłączenie zasilania powoduje utratę wszystkich informacji. Architektura MK 8051 polega na oddzielnym wykorzystaniu pamięci programu i pamięci danych i nosi nazwę Harvard. Zazwyczaj ta architektura jest używana do poprawy wydajności systemu poprzez oddzielenie ścieżek dostępu do pamięci programów i danych, ale w 8051 została wykorzystana do uzyskania pamięci programów i danych, które nie wymagały tego samego rozmiaru. Antypoda Harvardu – architektura von Neumanna – polegająca na przechowywaniu programów i danych we współdzielonej pamięci i jest najbardziej typowa dla mikroprocesorów przeznaczonych do użytku w komputerach. Przykładem jest rodzina mikroprocesorów x86. Timery TO, T1 to szesnastobitowe programowalne timery/liczniki, które można zaprogramować do wykonywania różnych funkcji. Można je wykorzystać do dokładnego formowania przedziałów czasowych, zliczania impulsów na wyjściach MK, tworzenia sekwencji impulsów, taktowania transceivera szeregowego kanału komunikacyjnego. Timery/liczniki są w stanie generować żądania przerwań, przełączać CPU w celu ich obsługi w przypadku zdarzeń i uwalniać go od konieczności okresowego sprawdzania stanu timerów. Ponieważ główne zastosowanie MK znajduje się w systemach czasu rzeczywistego, ich nieodzownym elementem są timery/liczniki. W niektórych modyfikacjach liczba timerów sięga 32. Port szeregowy jest kanałem wymiany informacji między MK a światem zewnętrznym. Takie kanały komunikacyjne zajmują minimalną liczbę kryształowych pinów, zapewniając komunikację na znaczne odległości przy minimalnych kosztach sprzętowych. 8051 implementuje uniwersalny asynchroniczny szeregowy transceiver (UART), który obsługuje standardowy protokół RS-232C, co umożliwia zorganizowanie komunikacji między tym MK a komputerem osobistym. Oprócz RS-232C, najpopularniejszymi protokołami w świecie systemów wbudowanych jest RS-485. I2C (dwuprzewodowa magistrala dwukierunkowa). SPI (XNUMX-przewodowy szeregowy interfejs peryferyjny). Bitbus (szeregowa magistrala sterująca), CAN (interfejs sieciowy między kontrolerami), USB (uniwersalna magistrala szeregowa) i kilka innych. Dla prawie każdego rodzaju kanału szeregowego można dziś znaleźć MK, który ma w swoim składzie odpowiedni port szeregowy. Równoległe porty we/wy są również istotną częścią każdego mikrokontrolera. Zwykle służą do komunikacji z najbliższym otoczeniem – czujnikami i elementami wykonawczymi. Ważną cechą portów równoległych MK jest możliwość zaprogramowania ich do wykonywania kilku funkcji. Na przykład w 8051 piny portu P0 i P2 mogą być używane jako normalne statyczne rejestry we/wy lub jako magistrala adresowa i danych do podłączania urządzeń zewnętrznych, takich jak dodatkowa pamięć programu, pamięć danych, urządzenia we/wy. Daje to MK elastyczność architektoniczną. Port RXNUMX może być wykorzystany zarówno jako statyczny rejestr I/O, jak i pełnić specjalne funkcje do obsługi kanału szeregowego, timerów, kontrolera przerwań itp. Przeprogramowalność pozwala na wykorzystanie wszystkich wyjść MC w projektowanym urządzeniu z maksymalną wydajnością. System przerwań jest jedną z najważniejszych części MK. Cechą systemów czasu rzeczywistego jest to, że niezwykle ważnym parametrem jest dla nich czas reakcji na zdarzenia zewnętrzne. Wyjaśnijmy to na prostym przykładzie. Wykonując obliczenia matematyczne na komputerze, zwykle uruchamia się program przeznaczony do wykonywania tych obliczeń, a po załadowaniu go do pamięci komputera wprowadza się sformułowanie problemu i czeka na wynik. Czas oczekiwania w tym przypadku nie ma fundamentalnego znaczenia (oczywiście w granicach rozsądku) - wolne działanie komputera może być irytujące, ale nie wpłynie to na wynik. System czasu rzeczywistego zakłada bardzo określoną, obliczoną na etapie rozwoju, szybkość reakcji systemu sterowania na zdarzenia zewnętrzne. Opóźnienia ponad obliczone są tutaj po prostu niedopuszczalne – mogą doprowadzić do katastrofalnych skutków. Problemy szybkiej reakcji na zdarzenia rozwiązuje się poprzez organizację systemu przerwań. Oznacza to, że dla każdego takiego zdarzenia tworzony jest osobny „kawałek” kodu, który stanowi reakcję MK na to zdarzenie. Ten „kawałek” kodu nazywany jest procedurą żądania przerwania (termin procedura przerwania jest często używana dla zwięzłości) i jest umieszczany w pamięci programu pod znanym adresem. W momencie wystąpienia danego zdarzenia na wejście kontrolera przerwań wysyłany jest sygnał o tym fakcie. To ostatnie jest urządzeniem, które ustanawia korespondencję jeden do jednego między sygnałem wejściowym o zdarzeniu, które wystąpiło, a adresem pamięci programu, pod którym znajduje się punkt wejścia do procedury przetwarzania żądania przerwania z tego zdarzenia. Kontroler przerywa wykonanie przez CPU bieżącego programu i inicjuje jego przejście do wykonania procedury obsługi przerwania. Czas, jaki upłynął od momentu wystąpienia zdarzenia do rozpoczęcia wykonywania pierwszej instrukcji procedury przerwania, nazywany jest czasem odpowiedzi MK na zdarzenie. Po zakończeniu przetwarzania CPU automatycznie powraca do wykonywania przerwanego programu. Inną funkcją kontrolera przerwań jest ustalanie priorytetów zdarzeń. Koncepcja priorytetu oznacza, że działająca procedura przerwania może zostać przerwana przez inne zdarzenie tylko wtedy, gdy ma ono wyższy priorytet niż bieżące. W przeciwnym razie CPU przejdzie do przetwarzania nowego zdarzenia po zakończeniu przetwarzania poprzedniego. Kontroler przerwań, który jest częścią MK 8051, posiada pięć wejść zdarzeń: dwa z urządzeń zewnętrznych, dwa z timerów i jedno z kanału szeregowego. Zwykle, kiedy mówią o jakimkolwiek MK, zawsze wspominają o rodzinie, do której należy. Jedna rodzina obejmuje produkty, które mają ten sam rdzeń, który jest rozumiany jako zestaw takich pojęć jak system instrukcji, schemat sekwencji operacji procesora, organizacja pamięci programu i pamięci danych, system przerwań oraz podstawowy zestaw urządzeń peryferyjnych . W rzeczywistości na rys. 1 przedstawia rdzeń, który stał się podstawą do stworzenia setek innych modyfikacji rodziny 8051. Różnice między poszczególnymi jej przedstawicielami dotyczą głównie składu urządzeń peryferyjnych oraz ilości pamięci na program lub dane. Ponieważ zakres zadań rozwiązanych przez MK. niezwykle szeroki, ich producenci starają się wypuścić jak najwięcej modyfikacji, aby zaspokoić najróżniejsze potrzeby konsumentów. W wielu rodzinach liczba modyfikacji zbliża się do setki lub nawet przekracza tę wartość. Najważniejszą cechą rodziny jest kompatybilność oprogramowania na poziomie kodu binarnego wszystkich zawartych w niej MK. Pozwala to twórcom systemów na zastąpienie jednej rodziny mikrokontrolerów innymi bez utraty ich rozwoju oprogramowania. Oczywiście im większa liczba odmian wchodzących w skład rodziny, tym większe prawdopodobieństwo wyboru najlepszej opcji, tym bardziej atrakcyjna jest ta rodzina dla dewelopera. Kwestia właściwego wyboru rodziny MC dla nowego rozwoju jest kwestią strategiczną, ponieważ problem przenoszenia oprogramowania między produktami różnych rodzin jest niezwykle złożony, a nawet użycie języków wysokiego poziomu nie zawsze pozwala na rozwiązanie to bez wielkich strat. Do kwestii kryteriów selekcji powrócimy w kolejnych artykułach cyklu. Opracowanie programu to jeden z najważniejszych etapów tworzenia urządzenia opartego na MK. Bez tego jest „martwy”, nie reaguje na wpływy zewnętrzne i nie wydaje sygnałów sterujących. Po włączeniu zasilania MCU natychmiast rozpoczyna wykonywanie programu znajdującego się w podłączonej do niego pamięci programu (zwykle ROM). Jego wykonanie rozpoczyna się od jakiegoś ustalonego adresu, najczęściej zerowego. Adres to po prostu numer komórki ROM Proces przebiega następująco: MCU odczytuje liczbę zapisaną w pamięci programu iw zależności od jej wartości, zwanej kodem maszynowym, wykonuje określone działania na zawartości rejestrów ALU. pamięci, portów itp. Na przykład poprzez odczytanie liczby 32H z pamięci programu. MK "rozumie", że trzeba odczytać wartość z portu wejściowego nr 2 i umieścić ją w rejestrze akumulatora. Często jeden bajt nie wystarcza do opisania akcji, a wtedy MK odczytuje dodatkowe bajty z pamięci. Po wykonaniu akcji MK odczytuje wartość z kolejnej komórki pamięci w kolejności itd. Zbiór bajtów opisujących jedną akcję wykonaną przez MK nazywa się rozkazem (instrukcją) maszynową, a zestaw takich rozkazów, które MK „ rozumie”. - jego system poleceń lub zestaw instrukcji (zestaw instrukcji). MK z różnych rodzin mają różne systemy poleceń, tj. ich kody maszynowe mają różne znaczenia, chociaż wykonują podobne czynności. Tak więc program dla MK jest ciągiem liczb, których wartości wskazują mu, jakie działania należy wykonać. Wynikiem opracowania programu jest plik komputerowy zawierający te kody maszynowe. Za pomocą programatora ROM jest on wprowadzany („zaszyty”) do pamięci programu MK. Jak składa się ta sekwencja kodów maszynowych - program dla MK? Czy programista naprawdę musi zapamiętywać wartości kodów maszynowych i ręcznie ustawiać ich kolejność? W ten sposób powstały pierwsze programy dla MK. i nazywało się to programowaniem w kodach maszynowych. Oczywiste jest, że ten sposób tworzenia programów jest bardzo czasochłonny i nieefektywny. Pierwszym krokiem ułatwiającym proces tworzenia programów był program komputerowy – tzw. tłumacz z asemblera. Pomysł polegał na wyrażeniu działań wykonywanych przez MK w języku bardziej czytelnym dla człowieka, a następnie przekształceniu tych wyrażeń w kody maszynowe. W powyższej przykładowej instrukcji maszynowej, która odczytuje wartość portu 2 i umieszcza ją w akumulatorze, podjęta akcja może być z grubsza oznaczona jako MOV A.P2. Tutaj słowo MOV (z angielskiego move), zwane mnemonikiem instrukcji, oznacza przekazanie wartości, a A i P2, zwane operandami, wskazują, skąd wziąć wartość i gdzie ją umieścić. Ta notacja nazywana jest językiem asemblera. program na nim napisany. przetwarzane przez tłumacza, który konwertuje konstrukcje języka asemblerowego na kody maszynowe. Programowanie w asemblerze jest szeroko rozpowszechnione do dziś. Tłumacze języka asemblera dla wszystkich popularnych rodzin mikrokontrolerów są bezpłatne. Pomimo oczywistej przewagi programowania w asemblerze nad programowaniem w kodzie maszynowym, w wielu przypadkach asembler nie jest wystarczająco wydajny, aby zrealizować zadania programisty. Faktem jest, że MK jest w stanie wykonywać tylko najprostsze operacje, takie jak operacje arytmetyczne na liczbach całkowitych, transfery, porównania itp. W przypadku bardziej złożonych zadań, na przykład operacji na liczbach zmiennoprzecinkowych, programiści musieli napisać specjalne procedury, które są niewygodne dla używać i uciążliwe. Kolejnym krokiem w rozwoju programów dla MK było stworzenie specjalnych programów komputerowych – tłumaczy z języków programowania wysokiego poziomu, czyli kompilatorów. Najczęściej używanym językiem programowania jest C. Wraz z pojawieniem się tłumaczy tworzenie programów dla MK zostało radykalnie uproszczone. Jeśli na przykład musisz dodać dwie liczby w programie, teraz wystarczy napisać a = b + c. a tłumacz konwertuje to wyrażenie na niezbędną sekwencję instrukcji maszynowych w zależności od typów zmiennych a, b i c. Użycie języka wysokiego poziomu pozwala programiście oderwać się od systemu poleceń konkretnego mikrokontrolera i operować kategoriami prostszymi i bardziej zrozumiałymi dla człowieka. Od programisty wymagana jest jedynie znajomość ogólnej architektury mikrokontrolera. zasady działania wbudowanych urządzeń peryferyjnych niezbędnych do rozwiązania zadania oraz umiejętność programowania w języku C. Zawartość funkcjonalna programu jest realizowana przy użyciu narzędzi języka C. który zawiera dużą liczbę różnych podprogramów (funkcji): arytmetycznych, do pracy z ciągami znaków i wielu innych. Rozważ proces tworzenia programu dla MK w języku C. Proces rozwoju będzie wymagał komputera osobistego. Po zrozumieniu zadania programista pisze kod źródłowy swojego programu w języku C za pomocą dowolnego edytora tekstu. Następnie uruchamia program tłumacza C. który konwertuje tekst źródłowy na pośredni plik obiektowy. Sterowanie translatorem odbywa się za pomocą zestawu klawiszy (ich opis znajduje się w jego dokumentacji), które są określone w jego wierszu poleceń. Jeśli programista podczas pisania programu popełnił błędy składniowe, tłumacz wyświetla ich listę na ekranie z oznaczeniem każdego numeru linii w źródłowym pliku tekstowym. Deweloper musi naprawić wszystkie błędy. Po udanej translacji pliki obiektowe muszą zostać przetworzone przez linker (linker), który generuje plik programu w kodzie maszynowym. Jest jeden problem podczas używania języka wysokiego poziomu. Kompilator jest odpowiedzialny za konwersję konstrukcji językowych na kody maszynowe, a konwersję tę można przeprowadzić z różnym stopniem wydajności. Kryteria wydajności to rozmiar kodu maszynowego (im mniejszy, oczywiście tym lepszy) oraz szybkość kodu maszynowego. Zadanie wygenerowania zwartego i szybkiego kodu jest bardzo trudne, a ogólna jakość kompilatora zależy od jego rozwiązania. Nowoczesne kompilatory C wykorzystują wielopoziomową optymalizację, cechy architektury konkretnego MK, pozwalają tworzyć mieszane programy, w których część podprogramów jest napisana w asemblerze. Opisany proces wygląda dość uciążliwie: programista musi ręcznie uruchamiać różne programy (edytor tekstu, kompilator C, linker do zapamiętywania klawiszy sterujących, wyszukiwania błędów w programie po numerach linii w pliku. Najnowszy krok ułatwiający pracę programisty programów dla MK było pojawienie się zintegrowanych środowisk programistycznych (Integrated Development Environment. IDE). Zintegrowane środowisko programistyczne to program komputerowy, który łączy ze sobą wszystkie etapy tworzenia programu. Łączy w sobie edytor tekstu do pisania kodu źródłowego, translatory z asemblera i C, linker, debugger, informacje referencyjne o MK i inne narzędzia niezbędne dla programisty. Konfiguracja translatorów, linkera i innych komponentów odbywa się nie poprzez określanie przełączników w wierszu poleceń, ale w formie okien dialogowych, w których wystarczy aby zaznaczyć pola we właściwych miejscach. . Pojawienie się zintegrowanych środowisk programistycznych jeszcze bardziej zwiększyło efektywność tworzenia programów dla MC, pozwoliło deweloperowi skupić się na istocie rozwiązywanego problemu i abstrahować od konkretnych szczegółów jego realizacji. Zintegrowane pakiety programistyczne są produkowane przez kilka firm. Pakiety różnych producentów są podobne pod względem funkcji, ale różnią się możliwościami serwisowymi, łatwością obsługi i jakością generowanego kodu maszynowego. Główne cechy najpopularniejszych zestawów rozwojowych przedstawiono w tabeli.
SYMBOLICZNE DEBUGOWANIE PROGRAMÓW DLA MK Z rzadkimi wyjątkami programy dla MK, ze względu na zawarte w nich błędy, nie zaczynają działać za pierwszym razem i wymagają debugowania. Deweloperzy radzą sobie z problemami z debugowaniem na różne sposoby. Niektórzy uważają, że wystarczy dokładnie przeanalizować tekst źródłowy, zobaczyć oscyloskopem, co dzieje się na wyjściach MK, a wszystkie błędy można poprawić. Ta metoda ma zastosowanie, jeśli programista ma duże doświadczenie, doskonale zna używane MK i ma tłumacza, który zawsze generuje poprawny kod (zwykle asembler) i wystarczającą ilość czasu. Inni używają w swojej praktyce domowych monitorów debugowania - zestawów specjalnych podprogramów, które są ładowane do MK wraz z programem głównym. Ten ostatni wywołuje podprogramy monitorujące w punktach kontrolnych i dostarczają informacji o stanie zasobów MK. Prawie każdy program może być debugowany w ten sposób, ale ma wady, które mogą być znaczące. Po pierwsze, monitor debugowania musi być wyposażony w część zasobów MC do pracy: przynajmniej część przestrzeni adresowej kodu i określoną liczbę komórek stosu, a maksymalnie także część pamięci RAM i peryferiów urządzenia MC. używany przez monitor do wyświetlania informacji. Alokacja zasobów do monitora debugowania może być trudna, jeśli sam program główny aktywnie ładuje MK. Na przykład PIC 16С5х (Microchip) MK ma tylko dwie komórki stosu i trudno jest używać wywołań podprogramu debugowania monitora. Po drugie, wywołania monitora zabierają czas programowi głównemu i dlatego nie mogą być wywoływane z krytycznych czasowo części programu. Po trzecie, tworzenie monitora debugowania samo w sobie wymaga czasu. Najskuteczniejszym sposobem debugowania programów dla MK jest użycie wyspecjalizowanych profesjonalnych narzędzi do debugowania, które obejmują debuggery symulatorów i emulatory w obwodzie. Zanim omówimy możliwości, jakie dają takie debuggery, należy dotknąć wyboru kompilatora, za pomocą którego teksty źródłowe programów są konwertowane na kod maszynowy. W zdecydowanej większości przypadków preferowane jest programowanie w języku wysokiego poziomu. Użycie asemblera jest konieczne, jeśli stawiane są bardzo surowe wymagania co do wielkości i szybkości generowanego kodu. Obecnie takich przypadków jest coraz mniej, ponieważ prawie zawsze można wziąć „szybszego” MK z większą ilością pamięci. Ponadto nowoczesne pakiety cross-tool ułatwiają pisanie programów mieszanych, w których niektóre moduły są napisane w C. a najbardziej krytyczne pod względem wydajności części znajdują się w asemblerze. Kompilatory C umożliwiają również wstawianie instrukcji asemblera do kodu źródłowego. Jakie są zalety programowania w C w porównaniu z programowaniem w asemblerze? W skrócie przedstawiają się one następująco:
Aby skutecznie debugować programy napisane w języku wysokiego poziomu, programista musi mieć do dyspozycji narzędzia do debugowania, które zapewniają odpowiednie możliwości wyświetlania danych użytych w programie, a także śledzenia wykonania programu od jego kodu źródłowego . Aby było to możliwe, konieczne są dwa warunki:
Zastanówmy się teraz, jak debugger powinien interpretować informacje symboliczne i jakie opcje powinien udostępnić użytkownikowi w związku z tym. ŚLEDZENIE REALIZACJI PROGRAMU WEDŁUG TEKSTÓW ŹRÓDŁOWYCH Ogólnie rzecz biorąc, jeden wiersz tekstu źródłowego jest konwertowany przez kompilator na kilka instrukcji maszynowych. Nawet program w asemblerze prawie zawsze zawiera makra, które po przetłumaczeniu rozwijają się do kilku instrukcji procesora. Debugowanie takiego programu za pomocą dezasemblera jego kodu jest niewygodne, więc kompilatory wstawiają tabelę numerów linii do informacji debugowania. Zawiera informacje o zgodności numerów wierszy tekstu źródłowego i nazw plików źródłowych z adresami bezwzględnymi kodu programu. Debuger wyświetla kod źródłowy programu na ekranie. zgodnie z tą tabelą może wykonać program „linia po linii”, wykonując w jednym kroku wszystkie instrukcje maszynowe wygenerowane przez kompilator dla bieżącej linii. Tablica numerów wierszy pozwala również na wykonywanie działań kontekstowych na tekście programu, np. wykonanie go „do kursora”, czyli w określone przez użytkownika miejsce w tekście źródłowym, ustawienie punktów przerwania na określonych wierszach itp. Akcje kontekstowe są wygodne, ponieważ programista nie musi znać adresów odpowiadających wierszom tekstu źródłowego: debugger sam określi je z tabeli. Debuger musi również „znać” adresy podprogramów, funkcji i etykiet kodu oraz być w stanie znaleźć tekst źródłowy funkcji według jej nazwy. WYŚWIETLANIE DANYCH WYKORZYSTYWANYCH W DEBUGOWANYM PROGRAMIE W celu pełnego debugowania programista musi mieć możliwość przeglądania danych przetwarzanych przez program w dowolnym momencie. Debuger musi „być w stanie” wyświetlić wszelkie dane używane przez program w najbardziej odpowiedni sposób. Z reguły programiści używają nazwanych danych w programach, to znaczy każdemu obiektowi używanemu w programie nadawana jest nazwa. Obiekty mogą mieć różną złożoność – od prostych komórek pamięci po złożone struktury języków wysokiego poziomu, takie jak struktury, tablice itp. DANE W PROGRAMACH MONTAŻOWYCH Programy asemblerowe wykorzystują głównie proste dane, czyli komórki pamięci. Stosowane są również tablice. Aby poprawnie wyświetlać proste dane, debugger musi „wiedzieć”:
Mając powyższe informacje, debugger po odebraniu od użytkownika nazwy obiektu powinien wyświetlić jego wartość zgodnie z typem. Najbardziej „zaawansowane” debuggery mogą dodatkowo wyświetlać pozostałe atrybuty obiektu. DANE W PROGRAMACH W JĘZYKACH WYSOKIEGO POZIOMU Wyświetlanie obiektów używanych w językach wysokiego poziomu jest znacznie trudniejsze ze względu na różnorodność struktur obiektowych, sposobów ich przechowywania w pamięci oraz zakresów. Jako przykład użyjemy języka C, jako najpopularniejszego wśród programistów. STRUKTURA OBIEKTÓW Poza prostymi zmiennymi o różnej długości, programy w C wykorzystują również zmienne zmiennoprzecinkowe, struktury (struct), związki lub związki (union), wskaźniki, tablice jednowymiarowe i wielowymiarowe. Te ostatnie mogą składać się zarówno z obiektów prostych, jak i złożonych (struktury, związki, wskaźniki). Używanie złożonych obiektów w programach jest z pewnością wygodne. Jednak ze względu na złożoność ich struktury wysoce pożądana jest możliwość odpowiedniego wyświetlenia ich na etapie debugowania. W debuggerach Fitona złożone obiekty mogą być wyświetlane zarówno w postaci skompresowanej (lista wartości elementów), jak i rozwiniętej, wskazując adres, wartość i typ każdego elementu tablicy i/lub elementu struktury. Implementacja wskaźników w różnych kompilatorach jest różna. Fakt, że MK zwykle ma kilka przestrzeni adresowych, stwarza dodatkowe trudności, ponieważ podczas pracy ze wskaźnikiem oprócz adresu musi być znana przestrzeń adresowa, na którą wskazuje wskaźnik. W niektórych implementacjach identyfikator przestrzeni adresowej jest częścią wartości wskaźnika, w innych kompilator „wie” to z góry i generuje odpowiedni kod. Ponadto komponent adresu we wskaźniku może mieć rozmiar od 8 do 32 bitów. Podczas wyświetlania wartości wskaźników debuger musi „znać” wszystkie szczegóły ich implementacji w każdym kompilatorze. METODY LOKALIZACJI OBIEKTÓW W PAMIĘCI Oprócz obiektów statycznych, których adresy nie zmieniają się podczas wykonywania programu, w programie napisanym w języku wysokiego poziomu mogą występować tzw. obiekty automatyczne, dla których pamięć jest tymczasowo przydzielana w stosie MK . Adresy takich obiektów nie są bezwzględne, lecz ustalane dynamicznie na etapie wykonywania programu. Zazwyczaj są one mierzone na podstawie bieżącej wartości jakiejś zmiennej statycznej zwanej wskaźnikiem ramki stosu (Base Pointer lub BP). Ponieważ wartość BP jest generowana dynamicznie przez program w czasie wykonywania, wartości obiektów automatycznych są dostępne tylko w ich zakresie, czyli z prawidłową wartością BP. Debugger przy wyświetlaniu wartości obiektów automatycznych musi „wiedzieć” sposób wyznaczania adresów, a także monitorować poprawność wartości BP Możliwe jest również tymczasowe umieszczanie zmiennych w rejestrach MK. W takim przypadku debugger musi „wiedzieć”, które zmienne są umieszczane w których rejestrach i na jak długo. I wreszcie, często zdarza się, że ten sam obiekt w ciągu swojego życia zmienia sposób umieszczenia go w pamięci i to nie raz. Może się to zdarzyć na przykład, gdy funkcja otrzymuje jeden lub więcej parametrów w rejestrach, a następnie umieszcza je na stosie. POLE WIDOCZNOŚCI OBIEKTU Podobnie jak w programach asemblerowych, programy C mają obiekty globalne, które są dostępne przez nazwę z dowolnego modułu oraz obiekty zlokalizowane w module (obiekty te są deklarowane jako statyczne). Jednak zmienne automatyczne i rejestrowe utrudniają debugerom wyświetlanie ich wartości. Fakt jest taki. po pierwsze, czas życia obiektu automatycznego jest ograniczony jego zakresem, a po drugie, obejmujące zakresy mogą mieć własne obiekty automatyczne o tych samych nazwach. Zilustrujmy to przykładem funkcji, która ma kilka zagnieżdżonych zakresów:
Zmienna o nazwie „a” istnieje tak długo, jak wykonywana jest funkcja f, ale w zależności od tego, która część funkcji jest wykonywana, nazwa „a” oznacza różne zmienne. Podczas śledzenia funkcji f debugger musi, w zależności od tego, która zmienna jest aktywna, poprawnie pokazywać jej wartość. Podczas tworzenia programu programista nie dba o szczegóły realizacji koncepcji, które zastosował w programie. Jeśli chodzi o kategorie „za pewnik”, często nie podejrzewa, jak trudno było je zaimplementować programistom kompilatorów i debuggerów. Te ostatnie mają rozwiązać problem połączenia w jednej powłoce jednocześnie prostego i intuicyjnego interfejsu, bogactwa funkcjonalności oraz szczegółowego przestudiowania wszystkiego, co wiąże się z implementacją cech architektury i funkcjonowania konkretnego MK. Jeśli debugger nie zapewnia programiście narzędzi do debugowania adekwatnych do złożoności rozwiązywanego problemu, programista nieuchronnie traci produktywność. Kto z nas nie musiał spędzać godzin i dni na szukaniu irytującego błędu lub literówki w tekście źródłowym?! W procesie opracowywania i tworzenia systemu mikroprocesorowego prędzej czy później przychodzi moment, kiedy zostaje on ostatecznie zaimplementowany w sprzęt i zaczyna wykazywać oznaki życia. Jednak w większości przypadków objawy te okazują się nieprzewidywalne, system zaczyna żyć własnym życiem. Wielu programistów zgodziłoby się pewnie, że każdy nowy program zawiera błędy. Po części dlatego nowy MK początkowo zachowuje się jak „czarna” skrzynka. W celu ułatwienia procesu debugowania systemów opracowano całą klasę narzędzi. Ich głównym celem jest uczynienie procesu funkcjonowania debugowanego MK „przejrzystym”, tj. łatwym do kontrolowania, arbitralnie kontrolowanym i modyfikowanym według woli programisty. Dobry profesjonalny zestaw narzędzi może dodatkowo zapewnić programiście wiele usług, tym samym znacznie ułatwiając mu pracę, eliminując rutynowe czynności. Główne narzędzia do debugowania obejmują emulatory w obwodzie, symulatory oprogramowania, płytki rozwojowe (płytki ewaluacyjne), monitory debugowania i emulatory ROM. Istnieją również połączone urządzenia i zestawy. EMULATORY W OBWODZIE Emulator w obwodzie (ICE) to narzędzie sprzętowo-programowe, które może zastąpić emulowany procesor w prawdziwym urządzeniu. VSE to najpotężniejsze i najbardziej wszechstronne narzędzie do debugowania. Funkcjonalnie VE dzielą się na te, które są podłączone do komputera zewnętrznego (zwykle jest to PC kompatybilny z IBM) i działają autonomicznie. Te drugie posiadają własne zasoby obliczeniowe i urządzenia wejścia-wyjścia, dlatego przy równych możliwościach są znacznie droższe od tych pierwszych, a przy tej samej cenie znacznie od nich ustępują pod względem funkcjonalności i możliwości serwisowych. Podczas debugowania systemu VSE jest zwykle podłączany kablem do specjalnej głowicy emulującej. Stosunkowo niedawno pojawiły się modele VSE, w których taka głowica jest konstrukcyjnie połączona z jednostką główną i wkładana do debugowanego systemu zamiast MK. Jeśli tego ostatniego nie można usunąć (piny są przylutowane do płytki), użycie VSE jest dopuszczalne, pod warunkiem, że ten MC ma tryb debugowania, w którym wszystkie jego piny są w trzecim (wysokoimpedancyjnym) stanie. W takim przypadku do podłączenia VSE służy specjalny adapter klipsowy, który jest podłączony bezpośrednio do wyjść emulowanego MK. Najmniej. VSE zawiera debugger, węzeł emulacji MK. podsystem pamięci emulacji i punktu przerwania. Bardziej zaawansowane TSE mogą dodatkowo zawierać tracer, procesor punktu przerwania, profiler (analizator wydajności kodu programu), timer czasu rzeczywistego, narzędzia programowe i sprzętowe, które pozwalają odczytywać i modyfikować zasoby emulowanego procesora „w locie” , oprogramowanie i narzędzia sprzętowe, które zapewniają zarządzanie synchroniczne i niezbędne do emulacji w systemach wieloprocesorowych, zintegrowane środowisko programistyczne. Debuger jest rodzajem pomostu między programistą a narzędziem do debugowania. Dobry debugger zapewnia ładowanie debugowanych programów do pamięci systemu, wyświetlanie na monitorze stanów i zawartości wszystkich rejestrów i pamięci (oraz w razie potrzeby ich modyfikacji) oraz kontrolę procesu emulacji. Bardziej wydajne debuggery (powszechnie nazywane debugerami wysokiego poziomu lub debuggerami wysokiego poziomu) również na to pozwalają.
Taki debugger pozwala użytkownikowi jednocześnie kontrolować postęp programu i widzieć zgodność między tekstem źródłowym, obrazem programu w kodach maszynowych oraz stanem wszystkich zasobów emulowanego mikrokontrolera. Należy zauważyć, że debugger wysokiego poziomu zapewnia wydajność wszystkich swoich funkcji tylko wtedy, gdy używany jest kompilator krzyżowy, który dostarcza kompletnych i poprawnych informacji debugowania (nie wszystkie kompilatory, zwłaszcza ich pirackie wersje, są do tego zdolne), a przy jednocześnie format jego prezentacji „znany” debuggerowi. Pamięć emulacji jest używana w procesie debugowania zamiast pamięci ROM opracowywanego systemu. Ponadto umożliwia debugowanie programu w przypadku braku rzeczywistego systemu lub jego układu. Jeśli potrzebujesz wprowadzić zmiany w debugowanym programie, wystarczy załadować nowy lub zmodyfikowany program do pamięci emulatora, zamiast przeprogramowywać ROM. Istnieją VSE. które pozwalają użytkownikowi „zastąpić” pamięć emulacji zamiast ROM nie tylko w całości, ale także blok po bloku (w niektórych modelach minimalny rozmiar bloku to 1 bajt). w kolejności określonej przez użytkownika. Aby to zrobić, wystarczy mu ustawić rozkład pamięci danych i pamięci programu, zgodnie z którym procesor będzie miał dostęp zarówno do zawartości ROM w debugowanym systemie, jak i do zawartości pamięci emulacji TSE. Taka pamięć jest zwykle nazywana pamięcią z możliwością mapowania. Tracer to analizator stanów logicznych, który pracuje synchronicznie z procesorem i rejestruje przebieg wykonywanych instrukcji oraz stan wybranych sygnałów zewnętrznych. Istnieją VSE, które pozwalają śledzić nie tylko sygnały zewnętrzne, ale także stany zasobów wewnętrznych MC. np. rejestry. W takich urządzeniach stosuje się specjalne wersje MK (kryształy emulacyjne). Procesor punktu przerwania umożliwia zatrzymanie wykonywania programu lub wykonanie innych czynności (na przykład uruchomienie lub zatrzymanie śledzenia) po spełnieniu określonych przez użytkownika warunków, w przeciwieństwie do zwykłego mechanizmu punktu przerwania, procesor umożliwia tworzenie i śledzenie warunków niemal dowolnego złożoność na poziomie sprzętowym, podczas emulacji proces nie jest dedukowany ze skali czasu rzeczywistego. W niektórych modelach VSE procesor punktu przerwania może być opcjonalnie używany do dynamicznego sterowania znacznikiem. Profiler (analizator wydajności kodu programu) pozwala na podstawie wyników działania debugowanego programu uzyskać informacje o liczbie wywołań poszczególnych sekcji programu oraz czasie poświęconym na ich wykonanie. Analiza informacji statystycznych dostarczanych przez profiler umożliwia identyfikację „martwych” lub przeciążonych fragmentów programów iw rezultacie optymalizację struktury debugowanego programu. Zintegrowane środowisko programistyczne to zestaw narzędzi programistycznych, który obsługuje wszystkie etapy tworzenia oprogramowania od napisania kodu źródłowego programu do jego kompilacji i debugowania oraz zapewnia prostą i szybką interakcję z programowym debuggerem-symulatorem i programistą. Obecność wbudowanego edytora, kierownika projektu i systemu kontroli w powłoce oprogramowania VSE znacznie ułatwia pracę programisty, oszczędzając mu wielu rutynowych działań. Dla niego granica między napisaniem programu, jego edycją i debugowaniem jest zatarta. Przejście od edycji tekstu źródłowego do debugowania i odwrotnie odbywa się „transparentnie” i synchronicznie z aktywacją odpowiednich okien. Menedżer projektu automatycznie rozpoczyna kompilację w razie potrzeby i aktywuje odpowiednie okno interfejsu programu. Równie łatwo możesz przystąpić do debugowania projektu za pomocą istniejącego debuggera symulatora lub rozpocząć flashowanie pamięci ROM za pomocą debugowanego programu. Niektóre ITU zapewniają użytkownikom inne dodatkowe funkcje. Wśród nich na szczególną uwagę zasługuje jedna, choć dość specyficzna, ale w niektórych przypadkach o fundamentalnym znaczeniu, umiejętność budowania kompleksów multiemulatorowych niezbędnych do debugowania systemów wieloprocesorowych.Cechą charakterystyczną takiego kompleksu jest sterowanie synchroniczne (z jednego komputera) kilku emulatorów. W ogólnym przypadku zdolność TSE do kontrolowania i zarządzania funkcjonowaniem debugowanych urządzeń może być ograniczona (np. nieprawidłowa obsługa przerwań w trybie krokowym, zakaz używania portu szeregowego itp.). Należy również pamiętać, że każdy model VSE posiada własną listę obsługiwanych mikrokontrolerów i kompilatorów. Jednak dla większości popularnych mikrokontrolerów opracowano VSE, które nie mają ograniczeń w wykorzystaniu zasobów debugowanych kryształów. Możliwości takiego ESS zilustrujemy na przykładzie modelu PICE-51 firmy Fiton. PICE-51 to urządzenie stworzone przy użyciu programowalnego układu logicznego (FPGA). Umożliwiło to drastyczne zmniejszenie rozmiaru VSE, zminimalizowanie odchyleń jego charakterystyki elektrycznej i częstotliwościowej od charakterystyki emulowanego MC, a tym samym osiągnięcie maksymalnej dokładności emulacji przy częstotliwościach do 33 MHz przy napięciach zasilania od 3,3 do 5 V emulacja prawie wszystkich MK z rodziny MCS-51. Wsparcie oprogramowania działa w środowisku Windows. PICE-51 składa się z płyty głównej, wymiennego adaptera pod konkretną grupę MK oraz wymiennej głowicy emulacyjnej również pod konkretny typ obudowy. Tracer i procesor punktu przerwania są montowane na płycie głównej, a procesor emulujący dla określonego typu MK jest zainstalowany na wymiennej płycie adaptera. Głowice emulacyjne umożliwiają instalację urządzenia w gniazdach DIP i PLCC na płytce użytkownika. Zasilanie jest dostarczane z bloku o napięciu wyjściowym +5 V (0,5 A) lub z debugowanego urządzenia. Komunikacja z komputerem odbywa się galwanicznie izolowanym kanałem RS-232C o szybkości 115 kbodów. Inne cechy i możliwości PICE-51 są następujące:
Tak szeroki zakres funkcjonalności sprawia, że VSE jest najpotężniejszym i najbardziej wszechstronnym narzędziem do debugowania. SYMULATORY Symulator - narzędzie programowe, które może symulować działanie MK i jego pamięci. Zwykle składa się z debuggera, modelu procesora i pamięci. Bardziej zaawansowane urządzenia zawierają modele wbudowanych urządzeń peryferyjnych (timery, porty, przetworniki ADC i systemy przerwań). Symulator powinien „umieć” wczytywać pliki programów we wszystkich popularnych formatach, jak najpełniej wyświetlać informacje o stanie zasobów symulowanego mikrokontrolera. a także zapewniają możliwości symulacji wykonania załadowanego programu w różnych trybach. Podczas debugowania model uruchamia program, a aktualny stan modelu jest wyświetlany na ekranie monitora komputera. Ładując program do symulatora. użytkownik może uruchamiać go w trybie krokowym lub ciągłym, ustawiać warunkowe lub bezwarunkowe punkty przerwania, kontrolować i dowolnie modyfikować zawartość komórek pamięci i rejestrów symulowanego mikrokontrolera. Symulator pozwala szybko sprawdzić logikę wykonywania programu, poprawność działań arytmetycznych. W zależności od klasy używanego debuggera, niektóre modele symulatorów obsługują symboliczne debugowanie programów na wysokim poziomie. Symulator może również zawierać szereg dodatkowych narzędzi programowych, takich jak interfejs środowiska zewnętrznego. Obecność takiego interfejsu pozwala tworzyć i elastycznie wykorzystywać model środowiska zewnętrznego MC. działanie i oddziaływanie na debugowany program zgodnie z zadanym algorytmem. W rzeczywistym systemie MC zwykle „zaangażowany” jest w odczytywanie informacji z podłączonych do niego zewnętrznych urządzeń (czujników), przetwarzanie ich i wydawanie sygnałów sterujących do elementów wykonawczych. Aby zasymulować działanie czujnika w prostym symulatorze, należy ręcznie zmienić aktualny stan modelu urządzenia peryferyjnego, do którego podłączony jest czujnik w rzeczywistym systemie. Jeśli np. podczas odbierania bajtu przez port szeregowy zostanie ustawiona pewna flaga, a sam bajt wpadnie do określonego rejestru, to obie te czynności należy wykonać ręcznie w symulatorze. W niektórych modelach problem ten został rozwiązany: symulatory mają wbudowane narzędzia do tworzenia modeli zewnętrznych urządzeń podłączonych do MK, w tym narzędzia do graficznego wyświetlania informacji. Oczywistą cechą symulatorów programowych jest to że ładowane do nich programy są wykonywane w skali czasowej innej niż czas rzeczywisty. Jednak niska cena, możliwość debugowania nawet w przypadku braku makiety debugowanego urządzenia sprawiają, że symulatory programowe są bardzo atrakcyjnym narzędziem do debugowania. Należy również zauważyć, że istnieje cała klasa błędów, które można wykryć tylko za pomocą symulatora. MONITORY DEBUGOWANIA Monitor debugowania to specjalny program ładowany do pamięci debugowanego systemu. Zmusza MK do wykonywania, oprócz zastosowanego zadania, również funkcji debugowania:
Program monitorujący działa „w połączeniu” z komputerem lub terminalem pasywnym, na którym odbywa się wizualizacja i kontrola procesu debugowania. Zaletą tego podejścia
PŁYTY ROZWOJOWE Deweloperzy lub, jak się je zwykle nazywa w literaturze zagranicznej, komisje ewaluacyjne (Evaluation Boards). - oryginalnych konstruktorów do prototypowania stosowanych systemów. Ostatnio wiele firm produkcyjnych wypuszcza nowe modele MK. ofertę i odpowiednie płytki rozwojowe. Zwykle jest to płytka drukowana z zainstalowanym MK i wszystkimi elementami niezbędnymi do jej normalnej pracy, a także układy komunikacji z komputerem. Z reguły płytka zapewnia wolne miejsce na montaż opracowywanego urządzenia użytkownika. Czasami jest też gotowe „okablowanie” do instalacji dodatkowych urządzeń zalecanych przez firmę (ROM, RAM, wyświetlacz LCD, klawiatura, ADC itp.). Płytki zmodyfikowane przez użytkownika mogą być z powodzeniem stosowane jako kontrolery jednopłytkowe wbudowane w produkty o małej skali (5...20 szt.). Dla wygody użytkownika płytki rozwojowe wyposażone są również w proste narzędzie do debugowania oparte na monitorze debugowania. Pojawiły się tutaj dwa różne podejścia: jedno jest stosowane w przypadku MK. posiadanie zewnętrznej magistrali, a drugie – dla MK, które jej nie mają. W pierwszym przypadku monitor debugowania jest dostarczany jako układ ROM. który jest instalowany w specjalnym gnieździe na płytce rozwojowej. Płytka posiada również pamięć RAM dla programów użytkownika oraz kanał komunikacji z komputerem lub terminalem. Przykładem jest płytka rozwojowa opracowana przez firmę Intel dla rodziny MK MCS-51. W drugim przypadku płyta rozwojowa zawiera wbudowane systemy programowania wewnętrznej pamięci ROM MK. którymi steruje komputer. Program monitorujący jest wprowadzany do pamięci ROM MK wraz z odpowiednio przygotowaną aplikacją (wywołania procedur debugowania monitora są wstawiane w odpowiednie miejsca). Następnie przeprowadzana jest jazda próbna. Aby wprowadzić poprawki do debugowanego programu, jest on usuwany z pamięci ROM i zapisywany do niego poprawiony. Gotowy program użytkowy uzyskuje się z programu debugowanego przez usunięcie monitora i wszystkich wywołań jego funkcji. Płytki rozwojowe dla MK z rodzin PIC-micro (Microchip), 80C750 (Philips), 89C2051 (Atmel) są przeznaczone do takiego algorytmu debugowania. Płytki rozwojowe są czasami wyposażone w programy do debugowania, które działają na komputerze zewnętrznym „w połączeniu” z monitorem. Programy te stały się ostatnio zauważalnie bardziej złożone i często mają wysoce profesjonalny zestaw funkcji debugowania (na przykład debugger symulatora) lub różne elementy, które są nieodłączne tylko w zintegrowanych środowiskach programistycznych w czystej postaci. Zestawy mogą również zawierać najczęściej spotykane w praktyce programy użytkowe. Możliwości debugowania zestawu „płyta rozwojowa plus monitor” nie są tak uniwersalne, jak w przypadku ESS. dodatkowo niektóre zasoby MC w trakcie debugowania są wybierane do pracy monitora. Niemniej jednak w wielu przypadkach decydującym czynnikiem jest dostępność kompletnego zestawu gotowych narzędzi programowych i sprzętowych, które pozwalają na rozpoczęcie instalacji i debugowania zastosowanego systemu bez straty czasu. Zwłaszcza jeśli weźmie się pod uwagę, że taki zestaw kosztuje kilka razy mniej niż bardziej wszechstronny emulator. EMULATORY ROM-u Emulator pamięci ROM to narzędzie programowe i sprzętowe, które umożliwia zastąpienie pamięci ROM debugowanego urządzenia pamięcią RAM. do którego możesz pobrać program ze swojego komputera za pośrednictwem jednego ze standardowych kanałów komunikacji. Pozwala użytkownikowi uniknąć wielu cykli flashowania pamięci ROM. Emulator ROM jest używany tylko do debugowania programów MK, które mają dostęp do zewnętrznej pamięci programu. Pod względem złożoności i kosztów urządzenie to jest porównywalne z płytkami rozwojowymi. Ma jedną wielką zaletę - wszechstronność. Emulator ROM może współpracować z dowolnym MK. Pierwsze emulatory ROM pozwalały na ładowanie, uruchamianie i zatrzymywanie programu tylko przy użyciu resetu głównego. Potem były skomplikowane modele ze sprzętowym generowaniem sygnałów śladowych do oscyloskopu po osiągnięciu określonego adresu. Emulowana pamięć w takich produktach była dostępna do przeglądania i modyfikacji, ale kontrola nad wewnętrznymi rejestrami kontrolnymi MK była do niedawna niemożliwa. Ostatnio pojawiły się tak zwane inteligentne emulatory ROM. Pozwalają „zajrzeć" do wnętrza MC na płycie użytkownika i są podobne w kontroli debugowania do VSE. Cactus prezentuje nawet swój rzeczywiście inteligentny emulator ROM jako VSE z serii MK, więc nie można odróżnić pracy z jednym i drugi.W rzeczywistości procesor w tym przypadku nie jest wymieniany, a używany jest ten na opłatę użytkownika. Inteligentny emulator ROM jest hybrydą zwykłego emulatora ROM. monitor debugowania i system szybkiego przełączania magistrali z jednej na drugą. Stwarza to efekt, jakby monitor debugowania był zainstalowany na płycie użytkownika, a jednocześnie praktycznie nie zabiera zasobów sprzętowych z MK, z wyjątkiem niewielkiej (około 4 KB) strefy kroków programowych. Taki emulator opracowała np. firma Fiton dla wszystkich istniejących i przyszłych MK, które mają rdzeń 8051, ale są dodatkowo nasycone różnymi urządzeniami wejścia/wyjścia. Produkt obsługuje wiele różnych MC firmy Philips, Siemens. OK. ZINTEGROWANE ŚRODOWISKA ROZWOJOWE Ściśle mówiąc, zintegrowane środowiska programistyczne nie należą do narzędzi do debugowania, jednak błędem byłoby ignorowanie tej klasy narzędzi programistycznych, które znacznie ułatwiają i przyspieszają proces tworzenia i debugowania systemów mikroprocesorowych. Przy tradycyjnym podejściu początkowy etap pisania programu jest skonstruowany w następujący sposób. Tekst źródłowy jest wpisany za pomocą edytora tekstu. Po zakończeniu pisania praca z edytorem tekstu zatrzymuje się i uruchamia się kompilator krzyżowy. Z reguły nowy program zawiera błędy składniowe, a kompilator zgłasza je do konsoli operatora. Następnie ponownie uruchamiany jest edytor tekstu, a operator wyszukuje i eliminuje zidentyfikowane błędy. Jednocześnie komunikaty o ich charakterze, wyświetlane przez kompilator, przestają być widoczne, ponieważ ekran zajmuje edytor tekstu. Ten cykl może powtarzać się więcej niż jeden raz. A jeśli program jest stosunkowo złożony, złożony z różnych części, podlega edycji lub modernizacji, to już ten początkowy etap może wymagać od programisty dużego nakładu pracy i czasu. Aby uniknąć dużej ilości rutynowej pracy, a tym samym znacznie zwiększyć produktywność programisty, pozwalają tak zwane zintegrowane środowiska programistyczne (powłoki) programistyczne (Integrated Development Environment IDE), które pojawiły się i szybko zyskują na popularności. Z reguły dobre zintegrowane środowisko łączy dostępne narzędzia do debugowania (emulator w obwodzie, symulator oprogramowania, programator) i dostarcza programiście teksty programów w stylu „Turbo”. Zintegrowane środowisko umożliwia:
Ostatnio funkcje zintegrowanych środowisk programistycznych stały się częścią interfejsów programistycznych najbardziej „zaawansowanych” emulatorów i debuggerów-symulatorów. Taka funkcjonalność w połączeniu z przyjaznym interfejsem znacznie przyspiesza pracę programisty. Dlatego przy wyborze narzędzi do debugowania warto wziąć pod uwagę następujący zestaw wskaźników: listę obsługiwanych mikrokontrolerów, ograniczenia zasobów emulowanych / symulowanych mikrokontrolerów, możliwość debugowania symbolicznego, listę obsługiwanych kompilatorów oraz, wreszcie możliwości serwisowe. Autorzy: Yu.Zobnin, Sh.Kobakhidze, Moskwa
Hałas drogowy opóźnia rozwój piskląt
06.05.2024 Bezprzewodowy głośnik Samsung Music Frame HW-LS60D
06.05.2024 Nowy sposób kontrolowania i manipulowania sygnałami optycznymi
05.05.2024
▪ Bragi Słuchawki Bezprzewodowe Słuchawki ▪ Badanie podstawowe, projekt Google Genetics
▪ sekcja serwisu Urządzenia pomiarowe. Wybór artykułu ▪ Artykuł Złote runo. Popularne wyrażenie ▪ artykuł Który producent elektroniki nosi imię skrzydlatego konia? Szczegółowa odpowiedź ▪ Artykuł Obowiązki pracownika w zakresie stosunków pracy i ochrony pracy
Strona główna | biblioteka | Artykuły | Mapa stony | Recenzje witryn
www.diagram.com.ua |
Zobacz inne artykuły Sekcja 
Najnowsze wiadomości o nauce i technologii, nowa elektronika:
Wszystkie języki tej strony