Google+ Start   |   E-mail   |   Newsletter:

MkBootloader

 

Program MkBootloader przeznaczony jest do pracy w systemach operacyjnych MS Windows począwszy od wersji Windows XP a skończywszy na obecnie najnowszych wersjach tego systemu. Pozwala on na komfortowe dokonywanie zmian firmware (wsadów) w mikrokontrolerach AVR, zaopatrzonych uprzednio w BLS (Boot Loader Section), czyli niewielki program do mikrokontrolera napisany w języku C i także dostarczany przez naszą firmę wraz z programem na PC. Komunikacja pomiędzy programem na PC i mikrokontrolerem możliwa jest za pomocą standardowej komunikacji RS232, przy czym można wykorzystywać do tego celu zarówno połączenia kablowe jak i bezprzewodowe. W ramach łączy kablowych można skorzystać ze standardowych portów COM (pracujących w zakresach napięć -12v / +12V), które w nowszych komputerach są już coraz rzadziej spotykane, nie mniej jednak jeśli zastosujemy przejściówki oparte na układach typu MAX232 (TTL) lub też MAX3232 (standard +3,3V), to bez kłopotu można połączyć własne urządzenie do komputera i dokonać podmiany wsadu w procesorze. W przypadku braku standardowych portów COM, można skorzystać z kolei ze złączy USB stosując dowolne przejściówki USB/RS232. Jedne z najlepszych przejściówek tego rodzaju, oparte są na układach firmy FTDICHIP, np.: FT232R, które przy okazji gorąco polecamy. Trzeci rodzaj łączy czyli bezprzewodowych możliwy jest dzięki modułowi Bluetooth, typu ATB-BTM-222, które także dostępne są w ofercie naszej firmy. W tym celu istnieje nawet specjalna opcja pozwalająca na ich stosowanie, a wiąże się ona z faktem, iż nawiązanie komunikacji pomiędzy modułami Bluetooth, wymaga czasu ok 1-2 s, i nasze oprogramowanie potrafi poradzić sobie w takich przypadkach. Nie trzeba dodawać, że możliwość radiowej podmiany firmware należy do najwygodniejszych opcji tego rozwiązania. Przygotowany przez nas kod BLS (wsadu bootloadera do procesorów AVR), pozwala wykorzystywać zdecydowaną większość popularnych i najczęściej stosowanych mikrokontrolerów, takich jak: ATmega8, ATmega88/168/328 również ATmega16/32 ale także ATmega644/644P(A) czy też ATmega162 i wiele innych. Na dzień dzisiejszy program sekcji BLS pozwala na poprawną pracę w mikrokontrolerach posiadających do 256 kB pamięci FLASH. (zapraszam serdecznie do obejrzenia poradnika video z bloga: LINK.  Należy nadmienić jednak, że w pełni udostępniamy kod źródłowy sekcji BLS i każdy może dokonywać jego modyfikacji we własnym zakresie. Jest ona nieraz nawet konieczna, jeśli chcemy korzystać z mikrokontrolerów posiadających więcej niż jeden sprzętowy moduł UART/USART. Poza tym można również we własnym zakresie dostosować ją do większych mikrokontrolerów i nie będzie się to wiązało z koniecznością dokonywania zmian w oprogramowaniu MkBootloader, które w tym zakresie nie posiada żadnych ograniczeń.

 

 

Film instruktażowy - współpraca z częstotliwościami F_CPU


Bardzo istotnym zagadnieniem jest to, że zarówno BLS jak i program na PC, pozwalają użytkownikowi konfigurować praktycznie w dowolnym zakresie kilka bardzo istotnych parametrów pracy tego mechanizmu, takich jak:

Parametry BLS
MCU nazwa mikrokontrolera dla którego kompilujemy BLS, np: atmega32, atmega168 itp
F_CPU częstotliwość taktowania mikrokontrolera (za pomocą dowolnego źródła taktowania, czy to wewn. oscylator RC, czy np zewnętrzny rezonator kwarcowy)
BLS_START adres początku sekcji BLS w pamięci FLASH mikrokontrolera. Zwykle umieszczamy go na końcu pamięci w obszarach wyznaczonych za pomocą Fusebitów
BOOT_WAIT czas wyrażony w sekundach, w jakim BLS będzie czekał po resecie na inicjalizację czyli np rozpoczęcie wgrywania nowego wsadu
BAUD_RATE prędkość transmisji RS232 wyrażona w bodach np.: 115200, 9600 itp

Pozostałe parametry transmisji RS232 ustawione są na sztywno w ten sposób: 8, N, 1 (czyli: 8 bitów danych, brak parzystości, 1 bit stopu) oraz brak kontroli przepływu. Z tego względu w programie na PC, interesuje nas tylko i wyłącznie wybranie odpowiedniego numeru portu COM poprzez który chcemy wysłać wsad do procesora. Program potrafi naturalnie korzystać zarówno z fizycznych portów a także z wirtualnych. Jednocześnie sam wykrywa wszystkie dostępne porty COM zainstalowane w komputerze a dodatkowo posiada opcję (klawisz), za pomocą której możemy automatycznie wykryć i ustawić numer portu COM, dla podłączonej przejściówki na układach firmy Ftdichip, takich jak FT232R.

Jak wygenerować plik BLS dla ATmega - obejrzyj ten poradnik koniecznie!



Sposoby kompilacji z poziomu konsoli oraz wiele różnych przykładów związanych ze zmianą parametrów kompilacji BLS zostały przedstawione na filmie instruktażowym powyżej. Istotne są jednak jeszcze inne elementy tej całej układanki, zanim w pełni będziemy w stanie uruchomić przykłady jak na filmie. Myślę, że specjalnego wyjaśnienia wymaga parametr BLS_START. Wiąże się on jak mówiłem bezpośrednio z możliwościami jakie oferują Fusebity (Boot Flash Section Size) wybranego przez nas mikrokontrolera. A fakt, że przygotowany przez nas BLS zajmuje zaledwie 256 słów (w pamięci FLASH) wcale nie oznacza, że każdy mikrokontroler posiada taki minimalny rozmiar na BLS. Na szczęście nic nie stoi na przeszkodzie aby skorzystać z większego. Przykładem może być ATmega644P, w której minimalny dostępny obszar dla BLS to 512. Natomiast wystarczy spojrzeć na opcje w mikrokontrolerze ATmega8 aby się przekonać, że tam najmniejszy obszar to 128. Pomimo to z uwagi na to że wiemy iż nasz BLS zajmuje 256 jesteśmy zmuszeni wybrać właśnie tę drugą opcję. Poniżej przykładowe zrzuty ekranów ilustrujące to o czym mowa wyżej:
 

Fusebity i rozmiary BLS dla m8 oraz m644P



Przy tej okazji wyjaśnię jak można obliczać adres startu bootloadera, który musimy ustawić jako wartość parametru BLS_START w pliku makefile. Otóż po prawej stronie wybranego rozmiaru BLS'a, widzimy pewną liczbę w postaci HEX. Na dwóch rysunkach powyżej, dla ATmega8 jej wartość wynosi (jak widać) 0x0F00. Wystarczy teraz uruchomić sobie nawet kalkulator w systemie Windows, przestawić go w tryb "programisty", wybrać operację na liczbach HEX a następnie wprowadzić wartość 0F00 i pomnożyć ją x2. W wyniku otrzymamy wartość = 0x1F00, i to właśnie tę wartość wpisujemy do makefile jako BLS_START. Tak jak na obrazkach niżej:

Obliczenia BLS_START dla ATmega8


Aby zakończy temat tych obliczeń, poniżej jeszcze przykład dla ATmega644P. Tutaj również spoglądamy na liczbę HEX znajdującą się po prawej stronie rozmiaru BLS, widzimy wartość = 0x7E00. Więc ponownie wpisujemy ją do kalkulatora i mnożymy x2, w wyniku czego otrzymujemy wartość BLS_START = 0xFC00. Obrazki poniżej i mam nadzieję, że tym sposobem (analogicznie) już każdy we własnym zakresie obliczy sobie adres BLS dla dowolnego procesora i dowolnego rozmiaru BLS

 

Obliczenia BLS_START dla ATmega644P
   




Ustawienie rozmiaru dla BLS to jedna rzecz, ale nie można zapomnieć o tym aby przestawić także Fusebit o nazwie BOOTRST, który dopiero powoduje takie zachowanie mikrokontrolera, że ten po każdym resecie, nie rozpoczyna wykonywać programu z pamięci FLASH od początku, a w zamian za to procesor zaczyna od początku wskazanej sekcji BLS, dzięki czemu to właśnie nasz program bootloadera ma szansę wystartować jako pierwszy i oczekiwać na rozpoczęcie ew. transmisji nowej wersji firmware. Dlatego proszę zawsze zwrócić uwagę jak na ilustracji poniżej, aby zaznaczyć i zaprogramować także ten Fusebit.

 

Fusebit BOOTRST

Jeszcze kilka słów na temat czasu oczekiwania BOOT_WAIT. Domyślnie jest ustawiona 1 sekunda i jest to minimalny czas jaki możemy ustawić, Krócej nie da rady. Przy połączeniach kablowych jest to zupełnie wystarczający czas zwłoki, przed przekazaniem sterowania do wgranego wsadu (firmware). Jednak jak wspominałem wyżej gdy korzystamy z modułów ATB-BTM-222, potrzebują one co najmniej 1-2 sekund na nawiązanie połączenia z modułem czy przejściówką USB/BT w komputerze lub z innym modułem tego typu. Dlatego na zapas ja dodaję jeszcze zwykle dodatkową sekundę albo nawet dwie, gdy korzystam z bezprzewodowej opcji wgrywania wsadu do mikrokontrolera.

UWAGA! bardzo często spotykam się z pytaniem, o możliwość nawiązania połączenia z BLS'em w mikrokontrolerze z poziomu programu na PC, w przypadku gdy nie mamy możliwości użycia sprzętowego klawisza RESET ponieważ np. nie jest on wyprowadzony w urządzeniu albo podczas korzystania z Bluetooth. Naturalnie istnieje taka możliwość, Trzeba tylko zaimplementować we własnym wsadzie rozpoznawanie polecenia otrzymanego przez RS232, które spowoduje prawidłowy ale PROGRAMOWY RESET mikrokontrolera. Dlatego też w programie MkBootloader jest domyślnie zaimplementowane takie polecenie, z którego ja najczęściej korzystam AT+RST?. Mechanizm programowego resetu polega na tym, iż wsad musi cały czas nasłuchiwać na linii RX procesora w trakcie normalnej pracy, czy nie nadleciał taki ciąg znaków zakończony np znakiem CR (enter). A jeśli tak ? to wystarczy wykonać reset przy pomocy sprzętowego modułu wbudowanego w każdy mikrokontroler AVR jakim jest Watchdog. Poniżej przedstawiam krótki przykładowy kod jak można tego dokonać. Przykład w języku C. Ale oczywiście na podobnej zasadzie można to zrobić czy to w Bascomie albo w asemblerze:

 

Przykład programowej wersji Resetu z użyciem Watchdog'a
 
//*** RESET UKŁADU NA POTRZEBY BOOTLOADERA (MkBootloader) ***
 
             cli();              // wyłącz przerwania
             wdt_enable( 0 );  // ustaw watch-dog
             while(1);           // czekaj na RESET


Jeśli ktoś będzie miał kłopoty ze zorganizowaniem nasłuchiwania takiej komendy we własnym programie tak aby nie przeszkadzało to w realizacji bieżących zadań wsadu, to proszę zapoznać się z ostatnim rozdziałem w naszej książce pt: "Język C Pasja programowania mikrokontrolerów 8-bitowych", rozdział: "RS232 - transmisja ASCII". W tym rozdziale wszystko jest nie tylko przejrzyście wyjaśnione ale także dostępne są gotowe przykładowe kody źródłowe na dołączonej płycie DVD. Jeśli już mamy zaimplementowaną taką metodę we własnym wsadzie to wystarczy w programie MkBootloader zaznaczyć ptaszka w ramce "software RESET", i program bezpośrednio po nawiązaniu połączenia RS232 (niezależnie czy przy pomocy kabla czy Bluetooth), pierwsze co zrobi to wyśle do procesora takie polecenie. Można oczywiście w tym polu wpisać własne, dowolne. Powinno to jednak spowodować wykonanie we wsadzie procedury przedstawionej powyżej i nastąpi RESET procesora oraz skok do bootloadera (BLS'a).

 

Użycie opcji "software RESET"


W programie MkBootloader widoczna jest jednak także ramka o nazwie "hardware RESET". Można ją wykorzystać do automatycznego zresetowania procesora z poziomu komputera PC o ile wcześniej przygotujemy w naszym urządzeniu sprzętowe połączenia pomiędzy pinami DTR lub RTS z portu szeregowego RS232 do pinu RESET mikrokontrolera. Wtedy z kolei nie będzie trzeba stosować programowej wersji resetu. Mowa tu oczywiście o wykorzystaniu połączenia za pomocą kabla RS232 (przejściówki USB/RS232) pomiędzy komputerem a naszym urządzeniem. Ale UWAGA! - nie należy podłączać bezpośrednio linii DTR lub RTS do pinu RESET mikrokontrolera!. Należy to zrobić za pomocą kondensatora ceramicznego o pojemności 100nF. Dopiero takie szeregowe wpięcie kondensatora da oczekiwany efekt i uchroni procesror przed ewentualnym uszkodzeniem w przypadku omyłkowego podłączenia.

Pozostałe opcje programu dostępne przy pomocy klawiszy: "INFO" , "Wstrzyknij wsad" czy też "Wybierz wsad" są już na tyle intuicyjne iż nie wymagają dodatkowych objaśnień, a w razie czego sposoby ich wykorzystania przedstawione zostały w filmie instruktażowym na początku tego artykułu.



UWAGA! Watchdog - Bootloader oraz Enhanced Watchdog Timer
Niektóre mikrokontrolery AVR takie jak te z serii: ATmega88/168/328 lub ATmega644P(A) i wiele podobnych (zawsze trzeba sprawdzić w nocie PDF), które korzystają z rozszerzonej wersji Watchdoga, wymagają specjalnego podejścia podczas startu mikrokontrolera. Jak wynika z noty PDF, dostajemy bowiem dodatkową możliwość dzięki której Watchdog, może być nadal aktywny po restarcie mikrokontrolera, jeśli został wcześniej włączony. Dla niektórych na początku bywa to utrapieniem, ponieważ nie mając o tym wiedzy, gdy pierwszy raz użyją Wachdoga, to mają wrażenie tak jakby mikrokontroler po resecie za pomocą Watchdoga, nigdy już nie chciał dalej wystartować aż do fizycznego wyłączenia i włączenia, bądź też fizycznego resetu. Jest to jednak normalne zjawisko, które ma tę zaletę, iż po resecie możemy się dowiedzieć, czy był on spowodowany właśnie działaniem układu Watchdog czy może nastąpił sprzętowy reset. Czasem taka wiedza bywa niezmiernie potrzebna a szczególnie podczas testów i debugowania programu. My od teraz wiemy, już dlaczego tak się dzieje. Musimy mieć zatem świadomość, że bezpośrednio po starcie mikrokontrolera należy wyłączyć moduł Watchdoga. W jaki sposób? Oto jest pytanie. Zakładając, że użyty został najkrótszy z możliwych czasów do programowego restartu mikrokontrolera - podczas gdy korzystamy z tej opcji aby aktualizować wsad i zrestartować procesor, tak jak zostało to pokazane w kodzie i opisane wyżej w tym artykule, musimy także jak najszybciej po starcie programu dokonać tej operacji. Niestety, może zdarzyć się tak, że próba dokonania tego na samym początku głównej funkcji programu main(), nie przyniesie skutku, gdy z jakichś względów inne wstępnie wygenerowane sekcje inicjalizacyjne będą trwały dłużej niż najkrótszy czas Watchdoga, więc nadal może dochodzić do ciągłego już resetowania się mikrokontrolera. Dlatego musimy skorzystać właśnie z jednej z takich sekcji, dostępnej dla programisty, i to takiej, która jest opatrzona najniższym możliwym numerem a zatem także czasem wykonania po restarcie. Będzie to zatem sekcja "init3". Poniżej prezentuję kod tej sekcji jaki możemy albo nawet powinniśmy umieszczać w kodzie własnego programu (można go umieścić jeszcze przed funkcją main), aby wyłączyć Watchdoga.

Kolejna UWAGA! - przypominam, że opisane tu działania będą się sprawdzać przy (domyślnie) wyłączonym Fusebicie WDTON (tam gdzie on występuje oczywiście). Jeśli ktoś ma potrzebę włączyć ten fusebit, musi sobie zmienić nieco podejście kodu BLS w procesorze wg własnych potrzeb.
 

Sekcja "init3" - wyłączanie Watchdoga po restarcie
 
void __init3( void ) __attribute__ (( section( ".init3" ), naked, used ));
void __init3( void )
{
    /* wyłączenie watchdoga (w tych mikrokontrolerach, w których watchdog
     * ma możliwość generowania przerwania pozostaje on też aktywny po
     * resecie) */
 
    MCUSR = 0;
    WDTCSR = (1<<WDCE) | (1<<WDE);
    WDTCSR = 0;
}


W omawianym przez nas przypadku, mamy jednakże świadomość, że po restarcie wykona się nie program główny ale kod BLS (bootloadera). Jak zatem łatwo się domyślić taka sekcja powinna się również znaleźć w kodzie naszego bootloadera. Na szczęście jest ona już przygotowana, jedyne o czym trzeba pamiętać to o tym aby odkomentować jedną linię kodu w pliku main.c zawierającym omawiany bootloader. Poniżej przedstawiam tę samą sekcję otoczoną jednak poleceniami preprocesora dokonującymi warunkowej kompilacji:
 

Sekcja "init3" w bootloaderze
/* dla procesorów typu ATmega88 itp trzeba włączyć poniższą opcję */

//#define WDIFr

#ifdef WDIFr
   void __init3( void ) __attribute__ (( section( ".init3" ), naked, used ));
   void __init3( void )
   {
       /* wyłączenie watchdoga (w tych mikrokontrolerach, w których watchdog
        * ma możliwość generowania przerwania pozostaje on też aktywny po
        * resecie) */
 
       MCUSR = 0;
       WDTCSR = (1<<WDCE) | (1<<WDE);
       WDTCSR = 0;
   }
#endif


Proszę zwrócić uwagę na zakomentowaną linię z definicją WDIFr

//#define WDIFr

W tym miejscu właśnie musimy w kodzie bootloadera skasować te dwa znaki backslash // dzięki czemu kod pomiędzy dyrektywami:
 

#ifdef WDIFr

#endif

Zostanie skompilowany. Prościej mówiąc, zostanie skompilowana sekcja "init3" w której to właśnie dokonujemy wyłączenia Watchdoga. Ten zabieg dopiero w zupełności zniweczy wszelkie efekty uboczne jakie mogą nas spotykać na początku, gdy nie mamy pełnej świadomości jak działa rozszerzony Watchdog w nowszych mikrokontrolerach AVR.

 

 

Program MkBootloader jest dostępny w naszym sklepie

ikona Strona główna ikona O nas ikona Wydawnictwo ikona Elektronika ikona Oprogramowanie ikona Kursy ikona Nowości ikona SKLEP ikona FORUM ikona Kontakt ikona Polityka Prywatności Cookie

ATNEL Nowoczesne Rozwiązania - programowanie AVR w C | pisanie programów dla AVR | pisanie programów ATmega | pisanie programów dla AVR | programowanie mikrokontrolerów |
mikrokontrolery AVR programowanie | programowanie w C mikrokontrolerów | programowanie ATmega | programy w C AVR
Realizacja: Dpl Agency - Projektowanie Stron Internetowych