[Programowanie] Mikrokontrolery AVR, Xmega i AVR32 - środowiska i narzędzia

[OldSkull]

I Środowisko

1. Windows

Pod systemem windows istnieje kilka możliwości, pierwszą jest połączenie środowiska AVRStudio 4, oraz kompilatora avrgcc (najpościej można je znaleźć wraz z innymi narzędziami w pakiecie WinAVR, można również ściągnąć oddzielnie). W tym celu wykonujemy nastepujące czynności:

- ściągamy WinAVR ze strony http://sourceforge.net/projects/winavr/files/ (1)

- ściągamy AVRStudio ze strony http://www.atmel.com/tools/STUDIOARCHIVE.aspx (2)(trzeba się rejestrować, ale nie trzaba płacić i nie przychodzi spam)

- instalujemy najpierw WinAVR (w domyślnej lokalizacji). Warto przy tym pamiętać, że jeśli mamy jeszcze inne kompilatory na komputerze, może dojść do konfliktu, jeśli budujemy (my lub jakiś program) projekt z wiersza poleceń.

- następnie instalujemy AVRStudio 4

- uruchamiamy dowolny projekt, wchodzimy w opcje projektu (Project->Configuration options-> Custom options) i sprawdzamy czy mamy zaznaczone "use WinAVR" i ścieżki podane poniżej są poprawne

Jeżeli nie zainstalujemy avr-gcc, będziemy mogli korzystać tylko i wyłącznie z asemblera, a nie z języka C. Warto przejrzeć opcje projektu, w któych możemy ustawić wszelkie opcje kompilatora. Stanowczo odradzam używania "gołego" WinAVR, poniewać ani nie udostępnia wygodnego notatnika (chociaż ten w AVRStudio też do wygodnych nie należy), a przede wszystkim - nie generuje plików makefile (osobiście uważam, że choćby po to warto mieć AVRStudio).

Z poziomu programu możemy się komunikować z firmowymi programatorami, ale nie z tanimi projektami OpenSource jak np. USBasp. W tym celu najlepiej skorzystać z avrdude (wbudowany w WinAVR), będącym programem konsolowym, w którym przykładowa komenda programowania wygląda tak:

avrdude -p m8 -c usbasp -e -U flash:w:minisumo.hex:i

lub skorzystać z interfejsu graficznego - osobiście polecam Burn-o-mat (3), poza tym wielu użytkowników korzysta z Sinaprog (4). Oba pozwalają ręcznie wybrać procesor i plik z wsadem. Oba pozwalają na wybór fusebitów, z tym, że Burn-o-mat pozwala na wygodniejszy wybór dla większej liczby układów.

Dodatkowym AVRStudio 4 atutem jest całkiem niezły symulator i możliwość debuggowania. Niestety jesteśmy ograniczeni do procesorów serii AVR oraz nowszych Xmega. Po linuksem (Wine) działa wysoce niestabilnie, debugger jest bezużyteczny.

2. Windows

Kolejną alternatywą jest AVRStudio 5 (bądź też Atmel studio 6, który dodatkowo obsługuje ARMy od Atmela (5)). Nie wymaga ono dodatkowych narzędzi, gdyż jest kompletnym środowiskiem. Jakie są w takim razie wady?

- Po pierwsze jest oparte na Visual Studio, co oznacza, że przy instalacji musi zainstalować wszelkie komponenty związane z VS

- Po drugie może mieć problemy z uruchomieniem na niektórych komputerach (np. u mnie na dwóch Win XP Pro nie działa ze względu na błędy w jednej z wersji SQL Server, a w pracy już tak).

- Po trzecie instaluje się długo, a plik instalacyjny jest duży.

- Po czwarte łączenie projektów jest kłopotliwe jeżeli korzystamy z wbudowanych bibliotek, ponieważ są one rozbite na wiele katalogów w folderze projektu (najprościej biblioteki ASF - bo o nich mowa - dodać na nowo do projeku).

- Po piąte posiada mnóstwo błędów w debuggerze (objawiającymi się zawieszaniem bądź blokowaniem możliwości programowania, albo wybieganiem w program assemblerowy bez poglądu kodu w C) oraz w kompilatorze (dodanie komendy w jednej funkcji może popsuć działanie innej funkcji).

Za to otrzymujemy darmowe środowisko z wygodnym interfejsem, mnóstwem bibliotek, wieloma gotowymi przykładami (dla płytek Atmela, ale łatwo je przerobić do własnych potrzeb). Oprócz tego możemy importować projekty napisane w AVRStudio 4 oraz w AVR32Studio (uwaga na problemy z wersjami bibliotek!). Posiada również możliwość debuggowania (wygodnego, m.in. z podglądem rejestrów, zmiennych lokalnych i dwoma oknami watcha) przez JTAG bądź symulator. Oczywiście dla osób przyzwyczajonych do Eclipse może być niewygodne, np. są inne skróty, jak chociażby do szybkiego skoku do deklaracji jak w Eclipse (tam ctrl+klik, tutaj kli->Alt+G->wybór miejsca). Oczywiście nie jest pozbawione błędów, np. wymienione problemy z JTAGiem. Mimo to szczerze polecam.

Nie da się zainstalować po linuksem, gdyż wymaga .NET (w wersji wymagającej Windows Installer).

3. Windows i linux

Eclipse + EclpseAVRtools. Jest to znany wielu Eclipse (do ściągnięcia z: http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/junor (6)) połączony z wtyczką dostępną pod linkiem: http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin (7) (trzeba doinstalować kilka innych wtyczek, ale program sam pokaże jakie jeśli ich nie ma). Oczywiście cały czas potrzebujemy kompilator (ponownie: pod Windows polecam cały pakiet WinAVR, pod linuksem należy ściągnąć avr-gcc oraz avrdude wraz ze wszystkimi zależnymi pakietami).

Co otrzymujemy? Środowisko w którym możemy wygodnie programować mikrokontrolery AVR (prawdopodobnie również xmega, ale nie sprawdzałem), korzystając ze wszystkich dobrodziejstw Eclipse (zawijanie bloków, np. funkcji i petli, szybki skok do deklaracji, szybki podgląd funkcji/deklaracji) oraz wbudowaną obslugą programatora, generowaniem plików makefile, obsługą lockbitów (warto o tym pamiętać, bo np. Burn-o-mat tego nie posiada) itd. Niestety w celu debuggowania musimy skonfigurować (i zainstalować) gdb-server, co nie jest ani łatwe ani nie musi działać. Do tego symulator jest tylko na niewielką grupę układów, do tego o ile skonfigurowany wg instrukcji nie działa (przynajmniej pod Ubuntu 11.04).

Programowanie układów AVR32 jest możliwe w Eclipse w przypadku zainstalowania toolchaina udostępnionego przez Atmela na stronie (toolchain pasuje również do AVRów), aczklwiek lepszym pomysłem jest skorzystanie z gotowego pakietu AVR32Studio, o czym mowa za chwilę.

4. Windows i linuks

Atmel w pewnym momencie postanowił wesprzeć platformę linux. Efektem jego prac jest program AVR32Studio (8), oparty o Eclipse (wraz ze wszystkimi zaletami i wadami). Co mozna powiedzieć? Otóż można w nim programać układy AVR32, posiada ogromną bazę biliotek do peryferiów (podobną do tej w AVRStudio5) oraz przykładów dla płytek rozwojowych (AVRS5 ma większą). Jakie są w takim razie wady? Otóż projekt został zarzucony jakiś czas temu i nie jest już rozwijany, przez to wraz z rozwojem bibliotek od których jest zależny jest coraz mniej użyteczny. Przykładowo debugger wymaga biblioteki glibc - na nowej wersji nie działa w ogóle (aczkolwiek programowanie działa), na wersji sprzed roku potrafi jedynie pokazać miejsce w kodzie asemblerowym w którym się znajduje oraz wartości zmiennych, ale nie miejsce w kodzie w C. Dodatkowo, żeby pod linuksem zainstalować starszą wersę tej biblioteki (o ile nie mamy starego systemu z "zablokowaną" wersją tej biblioteki) to w praktyce trzeba zainstalować (i nie uaktualniać) stary system, gdyż zbyt wiele programów jest od niej zależnych. W praktyce? Pod windowsem do debuggowania procesorów AVR32 należy korzystać z AVRStudio 5, pod linuksem można próbować na wirtualnej maszynie (bądź normalnie) próbować instalować coraz starsze systemy, aż trafimy na taki, w którym będzie działać, kupić Windowsa, spróbować połączyć Toolchain i poszukać czy do naszego procesora jest dostępny symulator, bądź zrezygnować z debuggowania.

II Narzędzia - programatory i JTAGi

1. Złącza i interfejsy

Wśród mikrokontrolerów firmy Atmel wyróżnia się kilka strandardów programowania, różniących się złączem:

- najpopularniejsze to tzw. KANDA (9) - 10-pinowe złącze (IDC) programatora z wyprowadzonymi sygnałami: Reset, SCK, DI(często podłączone do MOSI), DO(zwykle MISO), Vcc oraz 4xGND. Występuje również w wersji 6-pinowej z pojedynczym wyprowadzeniem masy. Programatory korzystajace z tego złącza należą do najtańszych. Służy tylko i wyłącznie programowaniu w układzie, tzw. ISP (InSystemProgramming), nie można za jego pomogą debuggować.

- JTAG 10pin - cały czas uzywany złącze 10-pinowe. Służy zarówno do programowania, jak i debuggowania. Wymaga podłączenia do pięciu nóżek procesora, zasilania i dwukrotnie do masy. Mimo iż złącze jest wspólne zarówno dla AVR jak i AVR32, układy z wyższą architekturą można debuggować tylko nowszymi programatorami

- PDI - wymaga połączenia tylko z dwoma nóżkami(wykorzystuje reset do komunikacji) +zasilanie. Występuje w Xmegach. Umożliwia zarówno debuggowanie jak i programowanie, ale istnieją programatory, które posiadaja PDI, ale nie umożliwiają debuggowania.

- TPI (Tiny Programming Interface) - służy do programowania niektórych najmniejszych procesorów. Wykrozystuje 2 linie do komunikacji+zasilanie

- aWire - jednonóżkowy system programowania pocesorów serii UC3L AVR32

- HVSP(szeregowy) i HVPP(równoległy) - dwa tryby programowania wysokonapięciowego. Polegają na podaniu 12V na nóżkę resetu, która została zdezaktywowana celem zyskania dodatkowej nóżki (bądź przypadkiem). Dodatkowo HVPP jest użyteczny jeśli procesor może być programowany przed montażem.

2. Programatory i JTAGi

Wymienię tutaj tylko obecnie najpopularniejsze i najciekawsze programatory i JTAGi. Część z nich jest wyprodukowana przez ATmela, część ma otwarty kod i projekt, część to klony.

- USBasp/STK200v2 ( linki (10) i (11)) - oba programatory są oparte o mikrokontroler ATmega8/48, korzystają z (V-USB (12)) i oferują tylko i wyłączenie jeden standard programowania - ISP ze złączem KANDA. Kosztują 30-40zł, ale posiadają wady:

*nie posiadają zabezpieczeń wyjść (nie licząc wielu DIY, sprzedawane są zwykle w formie "budżetowej")

*USBasp często nie działa pod Windows 7

*STK500v2 często wymaga zmodyfikowania polecenia konsolowego, ponieważ niektóre nie sa wykrywane jako STK500v2 - zwykle w przypadkach, kiedy sprzedawca sprzedaje podobny (o innym wsadzie w procesorze) - niekoniecznie gorszy - programator i opisuje go jako STK500

*USBasp z nowszym firmware pozwala na kontrolę prędkości programowania (ważne dla układów taktowanych mocno zaniżonym zegarem, np. kwarcem zegarkowym) od bardzo niskich, z poziomu konsoli

*można zaprogramować tylko i wyłącznie za pomocą jednego interfejsu

- AVRICE (JTAG ICE) - obecnie klony kosztują około 70-90zł, są oparte o mikrokontroler ATmega16 i (zwykle) układ FT232. Są to tylko i wyłącznie JTAGi, ale mają bardzo ograniczony zakres zastosowań (można programować tylko i wyłącznie podstawowe AVRy, bez xmeg)

- AVRISP II - ponownie urządzenie kosztujące 70-90zł, ale tym razem oferujące tylko i wyłącznie programowanie, za to w wielu standardach (ISP, PDI, TPI). Można nim programować prawdopodobnie wszystkie procesory z rdzeniem AVR (czyli mega, tiny i xmega), za żadnego ARMa i AVR32. Jest to najtańsze rozwiązanie dla osób chcących pobawić się Xmegami.

- AVR Dragon - urządzenie kosztujące 200-220zł, ale o największych możliwościach z dotychczas wymienionych. Jest to zarówno JTAG, jak i programator różnych standardów (ISP, JTAG, HVSP, PP, debugWire). Z doświadczenia mogę powiedzieć, że jest naprawdę wart swojej ceny, ma naprawdę spore możliwości, jest wygodny (każdy standard to inne złącze, więc nie trzeba nosić przejściówek) łatwo dostępny w kraju (np. Kamami, Seguro itd.) idzie debuggować nawet najnowsze układy, a aktualizacje wychodzą z każdą nową wersją AVR/ATmel Studio. Wady? Jest ich kilka:

*stosunkowo łatwo go uszkodzić (jak na urządzenie za 200zł), jeśli się uszkodzi zasilanie, to mniejszy problem (trzeba tylko ściągnąć i przelutować układ zasilania), ale ze względu na raczej średnie zabezpieczenie wyjść, można uszkodzić układ

*nie ma obudowy jako takiej - jest dostarczony w ładnym, tekturowym pudełku, w którym polecam wyciąć otwór na złącze USB i w nim go zostawić. Nie radzę go niczym przyduszać, ani upychać ciasno np. do plecaka

*jest najsłabszy z programatorów Atmela - najmniej pamięci, najmniej breakpointów itd. Różnica będzie widoczna najprawdopodobniej przy dużych projektach w szybkości działania debuggera i częstotliwości występowania błędów

- AVRICE II (13)- kolejny JTAG od ATmela. Tym razem koszt jest sporo większy: 299$ u ATmela, bądź około 110-130$ za klon z Chin (chiński klon w Polsce kosztuje ok. 850zł). Otrzymujemy za to programator w porządnej, plastikowej obudowie, z wyłącznikiem (z racji częstości zawieszania debuggera, naprawdę się przydaje), z jedynie jednym wystającym przewodem (i kompletem przejściówek do różnych standardów). Posiada on lepsze parametry od Dragona, ale też jest sporo droższy. Osobiście nie uważam, że warto go kupować za tę cenę, nawet klon z Chin, gdyż i tak 2x większa cena nie jest rekompensowana dużo lepszą funkcjonalnością (pomijając lepszą wytrzymałość)

- AVRICE III (14) - wyższy model, kosztujący 200$ (taniej!) u Atmela. Za to otrzymujemy niemal to samo co w AVRICE II, ale w metalowej obudowie i z tylko nieco lepszymi parametrami (szybszy, ale bez pamięci SRAM). Łatwo dostępny w Polsce (850-1140zł).

- AVR ONE! (15) - najdroższy, najszybszy, z dużą ilością pamięci SRAM, ale o zaporowej dla amatorów cenie (599$). Trudno dostępny w Polsce.

Celowo pomijam programatory na port szeregowy bądź równoległy - obecnie służą co najwyżej do zaprogramowania własnego USBasp na komputerze stacjonarnym (czasami jakimś starszym w domu albo u kolegi), bo porty LPT i COM są już bardzo rzadkie. Zaletą programatorów na LPT jest niewątpliwie cena - w granicach 5zł wliczając przewód i wtyczkę (lub 10-15zł jeśli mają bufor zabezpieczający płytę główną komputera), ale jest to tylko i wyłącznie urządzenie przejściowe między nieposiadaniej niczego, a posiadaniem programatora na USB. Można również kupić tani programator na USB (USBASP) z Chin, który kosztuje np. 5$ z wysyłką (z DX).

3. Mamy sprzęt, ale czym wgrać program do procesora?

Oczywiście każdy wie, że posiadanie urządzenia nie wystarczy. W przypadku większości urządzeń podłączanych do komputera są potrzebne po pierwsze sterowniki, po drugie program obsługujący. Te pierwsze w przypadku innych urządzeń na USB są często instalowane automatycznie (czasami można bądź trzeba dosinstalować od producenta, aby mieć dostęp do wszystkich funkcjonalności). W przypadku programatorów tylko nieliczne są wykrywane automatycznie (jako urządzenie HID), należy albo wcześniej zainstalować sterownik producenta (np. razem z AVR/Atmel Studio), albo wskazać sterownik po podłączeniu urządzenia. Jeśli chodzi o program obsługujący mamy pewien wybór:

- avrdude - jest to bardzo użyteczny program konsolowy (Windows+Linux), z którego można korzystać albo z linii poleceń, albo z poziomu GUI (Graphic User Inteface). Osobiście polecam Burn-o-mat (przejrzysty edytor ustawień Fuse bitów), za to odradzem Sina Prog (dla wielu procesorów nie oferuje dobrej obsłui Fuse bitów, jedynie ich ustawianie i kasowanie). Podobnie AVREclipse posiada GUI do tego programu. Ogromną zaletą avrdude jest to, że pozwala zaprogramować za pomocą dowolnego programatora, a obsługa nowych jest uaktualniana i dodawana w kolejnych wersjach

- AVRStudio/ATmel Studio - same pozwalają tylko i wyłącznie na obsługę (w wygodny sposób) programatorów oryginalnych i ich klonów. Pozostałe można obsługiwać tylko i wyłącznie poprzez dodanie jako własnego narzędzia polecenia konsolowego wykorzystującego np. avrdude.

Na koniec małe porównanie możliwości i kosztów w zależności od typu procesora i systemu:

Mam nadzieję, że ułatwiłem zainteresowanym podjęcie dobrego wyboru jeśli chodzi o środowisko, system operacyjny i narzędzia.

1) http://sourceforge.net/projects/winavr/files/

2) http://www.atmel.com/tools/STUDIOARCHIVE.aspx

3) http://avr8-burn-o-mat.aaabbb.de/avr8_burn_o_mat_avrdude_gui_en.html

4) http://hobbyrobotyka.pl/wp-content/plugins/download-monitor/download.php?id=4

5) http://www.atmel.com/Microsite/atmel_studio6/default.aspx

6) http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/junor

7) http://avr-eclipse.sourceforge.net/wiki/index.php/The_AVR_Eclipse_Plugin

8) http://www.atmel.com/tools/AVR32STUDIO2_6.aspx

9) http://www.kanda.com/avr-isp-circuits.html

10) http://www.fischl.de/usbasp/

11) http://www.elektroda.pl/rtvforum/topic1279132.html

12) http://www.obdev.at/products/vusb/index.html

13) http://store.atmel.com/PartDetail.aspx?q=p:10500154;c:100112

14) http://store.atmel.com/PartDetail.aspx?q=p:10500269;c:100112

15) http://store.atmel.com/PartDetail.aspx?q=p:10500055;c:100112

[Zuk]

Cześć.

Fajne kompendium o programowaniu mikrokontrolerów i narzędziach.

Ze swojej strony dodam, że dragony współpracują dobrze tylko z układami zasilanymi napięciem 5V.

Praca z układami zasilanymi np 3,3V to porażka.

Tak czy inaczej tak samo jak autor raczej polecam ten programator.

Zwłaszcza, że 95% projektów robotów amatorskich jest zasilana właśnie z 5V.

Pozdrawiam

Zuk

[kling]

Bardzo fajny art;) na pewno przyda sie poczatkujacym;)

Jednak szkoda ze wspominasz tylko o toolchain'ie WinAVR. Projekt nie jest juz rozwijany od jakis dwoch lat. Mysle, ze warto porzucic stare przyzwyczajenia i przeniesc sie na toolchain od atmela: http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx

Funkcjonalnie oferuje to samo co WinAVR ( a moze i wiecej;] ) i jest dostepny zarowno na Windowsa jak i Linuxa.

instalujemy najpierw WinAVR (w domyślnej lokalizacji). Warto przy tym pamiętać, że jeśli mamy jeszcze inne kompilatory na komputerze, może dojść do konfliktu, jeśli budujemy (my lub jakiś program) projekt z wiersza poleceń.

O sama kwestie kompilatorow nie trzeba sie za bardzo martwic. Zazwyczaj popularne toolchainy oferuja inne nazwy dla tych samych programow: AVR: avr-gcc, ARM: arm-none-eabi-gcc, PC min32gw-gcc.

Problem jaki zauwazylem to dostarczane z winavr narzedzia unixopodobne (mkdir, rm). Ich dzialanie jest nieco okrojone, i warto zamienic je np. na te dostarczane w pakiecie YAGARTO Tools.

[Bobby]

Zuk, jeżeli dragon nie działa z 3v3 to straszna lipa, nawet po dostawieniu zewn. konwertera poziomów jest ciężko?

OldSkull, fajny art, chociaż przydałoby się może coś więcej opowiedzieć o samym eclipse - to kombajn gotowy przyjąć wyzwania w praktycznie każdym języku i na każdą platformę sprzętową Nie bez powodu dużo komercyjnych IDE jest opartych własnie o nie, np. LPCxpresso i chyba Keil uVision.

[Zaja]

Zuk, nie wiem jakie miałeś doświadczenia z dragonem, natomiast u mnie bez najmniejszego problemu programuje układy zasilane z 3,3V. Udaje mi się nawet programować megi zasilane napięciem 2,7V (rozładowana bateria 3V), więc może po prostu masz jakąś felerną sztukę. Poza tym nie wiem czy wziąłeś to pod uwagę ale do dragona oprócz sygnałów i masy powinno być również podłączone napięcie zasilające docelowy układ.

[BlackJack]

Tak patrząc po tych konkursowych artach, to Treker powinna być możliwość oceniania ich tak jak robotów w skali od 1 do 5, i dopiero na podstawie statystki zdobytych punków wyłaniania zwycięzców.

Dla mnie większość artykułów przedstawia tak wszystko i nic po trosze, że nie jest wręcz możliwe głosowanie typu TAK/NIE przez wskazywanie autorów.

[OldSkull]

Bobby, Keil z tego co ostatnio widziałem nie jest oparty na Eclipse.

Jeśli chodzi o sam Eclipse: jest niesamowity, ale jego największe zalety (np. uniwersalność i modułowość) są równocześnie największymi wadami: wiele elementów jest tworzonych przez różne grupy, a debuggery trzeba często instalować oddzielnie - i w pewnym momencie mogą odmówić posłuszeństwa. Poza tym jest silnie zależny od bibliotek zewnętrznych, co również może spraić problemy (jak np. to widać w AVR32Studio).

Zuk, używamy Dragona do AVR32 zasilanych 3.3V i nie ma problemów (poza tym, że umarł razem z płytką, która miała awarię ;( ). Przynajmniej interfejs JTAG, nie wiem jak ISP.

[Zuk]

Ja generalnie używam dragona do układów zasilanych 5V.

Zdarzyło mi się, że chciałem napisać program do robota zasilanego 3 paluszkami.

W fazie uruchamiania zamiast baterii podpiąłem ładowarkę na 3,7V.

Wtedy zaczęły się problemy z programowaniem.

Generalnie udawało się raz na kilka prób.

Procek to była mega88.

Pozdrawiam

Zuk

[nes86]

W artykule brakuje wzmianki o najnowszym Atmelstudio, które oparte jest na Visual Studio. Zostawia w daleko tyle wszystkie wymienione środowiska. Więc ktoś kto jest początkujący i przeczyta ten artykuł nie zapozna się z najprostszym i najwygodniejszym ze środowisk (w mojej opinii).

[OldSkull]

nes86, jak to nie?

Kolejną alternatywą jest AVRStudio 5 (bądź też Atmel studio 6, który dodatkowo obsługuje ARMy od Atmela (5)).

Niestety środowisko to stabilnością debuggowania nie grzeszy. Błędów teżma sporo. Ale mimo to zostawia w tyle Eclipse'a.