Przykłady
Są dwa powody mogące prowadzić do decyzji o zmianie mikrokontrolera na inny o identycznym układzie wyprowadzeń. Jeden to chęć uproszczenia procesu pisania kodu dzięki wykorzystaniu peryferiów nowego, bardziej zaawansowanego układu. Drugi, dokładnie przeciwny, to oszczędność, którą można osiągnąć wykorzystując prostszy, tańszy mikrokontroler i emulując programowo peryferia.
Do ilustracji pierwszego przypadku wykorzystany zostanie przykład generacji sygnału PWM w oparciu o napięcie analogowe. Operację taką można łatwo wykonać używając najprostszego z opisywanych mikrokontrolera – MC9RS08KA2. Mimo, że układy RS08 nie posiadają timera potrafiącego automatycznie generować PWM, ani przetwornika A/C, obie funkcje można emulować za pomocą 8-bitowego timera modulo oraz komparatora analogowego, w które ta architektura jest wyposażona.
Problem pojawia się jednak, gdy chcemy wygenerować kilka sygnałów PWM o różnych charakterystykach, co jest trudne do zrobienia programowo, jako że trzeba używać timera zarówno do generacji pierwszego sygnału PWM, jak i do emulacji przetwornika A/C. Migracja na następny w opisywanej „ścieżce migracji” mikrokontroler, MC9S08QD4 pozwala szybko rozwiązać ten problem, ponieważ jest on wyposażony w przetwornik A/C, a do generacji sygnałów PWM można wykorzystać dwa lub nawet trzy kanały timera. Przejście jeszcze wyżej, tj. na MC9S08QG8 pozwala z kolei na użycie wbudowanego interfejsu I2C do transferu danych lub na zapisanie ich w pamięci zewnętrznej.
Na drugi przypadek można się z kolei natknąć na samym początku fazy projektowania, gdy złożoność projektu wydaje się większa niż jest w rzeczywistości. W trakcie projektowania części sprzętowej lub w czasie pisania kodu okazuje się, że problem można rozwiązać łatwiej, niż przewidywano i można, w związku z tym, przejść na prostszy, mniejszy mikrokontroler. W opisywanym przypadku możliwa jest jest np. migracja z MC9S08QG8 na MC9S08QD4, albo MC9RS08KA2 bez konieczności wprowadzania dodatkowych zmian w sprzętowej części projektu. Kompatybilność wyprowadzeń układów jest tutaj użyteczna, gdyż testowanie sprzętu można kontynuować. Brakujące peryferia da się emulować programowo na nowym układzie, otrzymana koniec końców funkcjonalność będzie taka, jak zakładano, a koszt produkcji urządzenia się obniży.
Programowe wparcie migracji
Ważne jest posiadanie narzędzi programowych, które poradzą sobie z przeniesieniem projektu z jednego mikrokontrolera na inny. Takie narzędzie, potrafiące pracować ze wszystkimi omawianymi układami jest dostępne i jedyne, co trzeba zrobić, to zaznajomić się z nim i jego funkcjonalnością.
Istnieje oprogramowanie generujące kod inicjalizujący peryferia każdego z opisywanych mikrokontrolerów. Jest to narzędzie Device Initialization Tool z pakietu CodeWarrior, które pomaga programistom skoncentrować się na procedurach decydujących o funkcjonalności projektu, automatycznie inicjalizując peryferia. Wersja środowiska CodeWarrior narzędzia dla opisywanych tu układów nosi nazwę CodeWarrior for HC(R/S)08 V5.1.
Zmiana docelowego mikroprocesora w CoreWarrior wersji 5.0 i wyższych jest prosta. Z menu projektu należy wybrać pozycję Change MCU/Connection (rysunek 6).
Rys. 6. Zmiana docelowego mikrokontrolera w CodeWarrior
Nowy mikrokontroler docelowy można wybrać z obszernej listy obsługiwanych układów. Środowisko CodeWarrior zamieni wcześniejsze pliki związane z konkretnym mikrokontrolerem na nowe, uaktualni mapę pamięci oraz udostępni deklaracje nowych modułów. Przy ponownej kompilacji projektu, wszystkie potencjalne problemy z migracją objawią się jako błędy lub ostrzeżenia kompilatora i można je dokładniej zbadać jeden po drugim. Jeśli oprogramowanie było pisane z użyciem plików nagłówkowych środowiska CodeWarrior, kod łatwo się przekonwertuje, gdyż używane w nich deklaracje są spójne, np. dla wszystkich mikrokontrolerów 8-bitowych PTA5 jest nazywane PTAD_PTAD5.
Rys. 7. Jak dokonywać deasemblacji
Kod dla układów HCS08 można w CodeWarrior pisać w C, ale kompilator tego języka dla rodziny RS08 jest także opracowywany. Póki nie jest on dostępny, programiści mogą używać dostępnej w środowisku funkcji deasemblacji do konwersji kodu w C na assembler (patrz: rysunek 7). W oknie edycji kodu CodeWarrior może zdeasemblować program w C i wyświetlić równoważny kod assemblera. Na rysunku 8 pokazano fragment takiego kodu.
Rys. 8. Przykład zdeasemblowanego kodu
Ostatnim, ważnym aspektem projektowania systemów wbudowanych jest interfejs debuggera. Dla mikrokontrolerów rodzin RS08 i S08 istnieje jednoliniowy interfejs do programowania i debugowania – BDC. Projektanci mogą używać jednego środowiska do programowania i debugowania wszystkich omawianych układów. Cały projekt można więc zmigrować na inny mikrokontroler bez zmian hardware’u czy oprogramowania.
Podsumowanie
Przenośność oprogramowania i kompatybilność sprzętu są kluczowymi czynnikami gdy chodzi o przyspieszanie projektowania i wyciąganie maksimum z mikrokontrolera. Zastosowanie układów, które pozwalają na łatwe przeniesienie projektu na mikrokontroler o innych właściwościach i z innymi peryferiami rozszerza wykorzystanie mikrokontrolera w projekcie i daje projektantom pewność, że zmiany układu da się dokonać, jeśli projekt będzie jej wymagał.
Możliwość używania tych samych narzędzi do pracy z różnymi mikrokontrolerami jest również bardzo ważna. Byłoby bardzo nieefektywne zmieniać software lub programistę, aby dokończyć migrację i dlatego posiadanie narzędzi programistycznych i sprzętowych, które są kompatybilne z szeroką gamą układów bardzo ułatwia szybką zmianę używanego mikrokontrolera. Posiadanie jednego programatora i debuggera do wielu układów także pomaga na efektywne używanie posiadanych narzędzi i ułatwia proces migracji.
Na podstawie AN3325 firmy Freescale (autorstwa Ingi Harris) opracował Dominik Maj.
| Następna część artykułu jest dostępna tu. Poprzednia część artykułu jest dostępna tu. |
