Klasa QSettings rozwiązywała część tych problemów - pozwalając skierować grupę ustawień do pliku/rejestru. Niestety, pierwszy wymyślony sposób ich użycia stał się bardzo szybko uciążliwy - zapisywanie setek ustawień w jednym miejscu, pilnowanie aby odczyt zgadzał się z zapisem - jak łatwo się domyślić szybko stało się to nie do opanowania.

Niedawno czytając dokumentację, i stając przed podobnym problemem znalazłem sensowniejsze podejście - wraz z dostarczonymi metodami pozwalające zminimalizować nakład pracy.

Zacznijmy od samego początku naszego programu, dostarczając parę istotnych informacji:

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QApplication::setOrganizationName("RainLabs");
QApplication::setOrganizationDomain("rainlabs.pl");
QApplication::setApplicationName("Orbi Eye");
QApplication::setApplicationVersion("0.2 alpha");

AutoPhotoAdvanced b;
b.setWindowTitle(QApplication::applicationName()+" v"+QApplication::applicationVersion());
b.show();
return a.exec();

}

Po takim wywołaniu każda klasa potrzebująca skorzystać z ustawień może to zrobić niezwykle szybko i wygodnie - np. w konstruktorze/destruktorze, za pomocą:

QSettings settings;
settings.setValue(....) / settings.value(...)

dzięki takiemu podziałowi każde ustawienia są niezależne, zaś dokonane na początku ustawienia aplikacji pozwalają korzystać z domyślnego konstruktora, co ułatwia ich używanie w całym programie, nie uciekając się do kopiowania kawałka kodu tam i z powrotem lub co gorsza pamiętania jakie argumenty przekazać za każdym razem konstruktorowi.

Link: Integracja Eclipse CDT z CodeSourcery dla ARM Cortex-M3

Główną inspiracją był system Balsit, stworzony przez Rafała Bednarza na Bal w roku 2009. W przypływie nadmiernej chęci do pacy stwierdziłem, że można go napisać od nowa, rozbudowując niektóre możliwości/zmieniając funkcjonalność.

System składa się z front-endu do rejestracji gości - każdy chcący kupić bilet rejestrował się na komputerze, członek naszego samorządu sprawdzał poprawność wpisanych danych. Użytkownik otrzymywał unikalny numer, potrzebny zaraz przy następnym stanowisku.

Sprzedawca obsługiwał system sprzedaży - kupujący wybierał miejsce, wpłacał należność i otrzymywał wypisany bilet. Relacje tworzone były automatycznie, system ułatwiał sprzedaż biletu parom.

Całościowo  umożliwił osiągnięcie tempa powyżej 2 biletów na minutę

Sam system nie wykorzystywał innowacyjnych pomysłów - po prostu wykorzystywał wielkie możliwości frameworka

Załączam skompresowane źródła, włącznie z użytym Symfony 1.4.1: balsit 0.8.

Linkowanie bibliotek - ustawienia linkera

Pierwszym problemem z jakim się zetknęliśmy było linkowanie bibliotek - rzut oka do katalogu z bibliotekami utwierdził nas w przekonaniu, że tutorial, którego używamy jest przeznaczony dla OpenCV1.0 lub 1.1. Tak czy inaczej w ustawieniach linkera należy dodać uzupełnione w stosunku do poprzedniej wersji wywołania:

-lopencv200 -lcxcore200 -lcvaux200 -lml200 -lcxts200 -lhighgui200

Zaś jako ścieżkę bibliotek (-L) domyślnie:  C:\OpenCV2.0\lib

Taka modyfikacja wywołania pozwoli linkować nasze programy. Ważniejsze jest jednak rozwiązanie problemów związanych z samą kompilacją.

Używanie headerów

Kolejna rzecz, która przebiega sama w sobie bez niespodzianek, to dodanie katalogu z plikami *.h i *.hpp do wywołań kompilatora:

-IC:\OpenCV2.0\include\opencv

Rozwiązanie problemu z kompilacją

Niestety, pomimo iż biblioteka o tym jawnie nie wspomina, nie została ona dobrze przygotowana do pracy z obecną, stabilną wersją GCC. Aby uniknąć kłopotów przy kompilacji (kłopot==nie działa:)) Najlepiej wybrać nowszą wersję GCC. Pod systemem Windows jednym z lepszych wyborów jeśli chodzi o instalację kompilatora c++, narzędzi do budowania etc. jest pakiet MinGW. Do tej pory korzystałem z oficjalnego wydania MinGW, które "niestety" zawiera oficjalną wersję kompilatora GCC. Świetnie radził sobie on np. z kompilacją programów z biblioteką Qt. Będąc zmuszonym do rezygnacji z tego rozwiązania, a jednocześnie nie chcąc instalować ręcznie całej otoczki (make, binutils, etc.) skorzystałem z strony http://www.tdragon.net/recentgcc/.  Najlepiej wybrać najnowszą wersję w wersji Bundled - nie ma wtedy ryzyka, że któraś z paczek zniknęła z serwera. Po instalacji nowego "pseudo" MinGW (która jest bardzo bezproblemowa) kompilacje z użyciem OpenCV rusza bez problemu.

Warto również zwrócić uwagę, iż Qt 4.5.3 również świetnie działa z GCC 4.4.1, zaś nowsze, "niestabilne" wersje GCC są coraz częściej używane (np pakiet GNU ARM używa GCC serii 4).

Konwersja 2 bajtowa:

Komentarze wyjaśniają mniej typowe rzeczy, zaś działanie pozostałych sprowadza się praktycznie do opisu działania instrukcji. W razie niezrozumienia jakiegoś szczegółów można zapytać na mailu komentarzu.

Wadą symulatora jest fakt, iż znalazłem go w formacie JAR, co czasem sprawia problemy z uruchomieniem (kilka osób zgłaszało iż  musiało zainstalować od nowa JRE).

Symulator rdzenia '51

Wkrótce zamieszczę proste programy napisane w tym symulatorze, będzie wtedy okazja dokładniej zerknąć w akceptowaną przez niego składnię.

Po pierwsze jako źródło informacji na temat samego rdzenia poza książkami (np. dobrą pozycją pana Rydzewskiego) polecam:
Atmel 8051 Microcontrollers Hardware Manual (oryginalny plik na serwerze Atmela)
Atmel 8051 Microcontrollers Hardware Manual (lokalna kopia na tej stronie)

Zaś więcej szczegółów na temat konkretnych mikrokontrolerów można znaleźć w Datasheetach producentów. Dla dostępnych w budynku b1, s. 315 płytek deweloperskich sa to układy AT89S51 Atmela:
AT89S51 Datasheet (oryginalny plik na serwerze Atmela)
AT89S51 Datasheet (lokalna kopia na tej stronie)

Poniżej zamieszczam link do sprawozdania z  drugiego ćwiczenia (pierwsze polegało na mruganiu diodą w pętli głównej, niestety nie byłem na nim obecny). Zawiera ono pierwszy program, przygotowany koncepcyjnie/na symulatorze przeze mnie i Kubę Tutro (ale napisany na zajęciach), oraz drugi napisany już na zajęciach prezentujący działanie PWM w celu regulacji jasności świecenia diod. Oba programy pisałem na zajęciach wspólnie z Pawłem Górką, on również uzupełnił komentarze i przygotował sprawozdanie w formacie PDF.

Sprawozdanie z laboratorium 8051. Paweł Górka, Krzysztof Wesołowski

Przy okazji podnoszenia jednej oceny powstał prosty program prezentujący 3 algorytmy operujące na grafach. Pozwala on wprowadzić dowolny graf, o rożnych wagach a następnie prezentuje jego rozwiązanie krok po kroku.

Program powstawał  przy mniejszej lub większe niechęci przez wakacje. Pierwsza część programu to edycja i implementacja struktur grafowych.  Klasy tam zaimplementowane pozwalają zaprojektować graf, zapisać go/wczytać i uruchomić fragment prezentujący dany algorytm. Drugą częścią jest abstrakcyjna klasa AbstractSolver, ułatwiająca pisanie klas rozwiązujących o spójnym wyglądzie i funkcjonalności. Właśnie te 3 przykładowe algorytmy stanowią drugą cześć, stworzoną już nie przeze mnie ale przez Jakuba Tutro i Pawła Górkę.

W tym projekcie najbardziej zadowala mnie rozplanowanie jego działania, i zaprojektowanie klas,  które choć zapewne nie jest idealne, umożliwiło jasny podział pracy, zminimalizowało ilość kodu i zwiększyło elastyczność takiego rozwiązania.

Program powstawał przy równoczesnej pracy, dlatego do jej synchronizacji wykorzystałem darmowy serwis http://www.assembla.com/, a konkretnie udostępniony przez niego serwer SVN. Zainteresowani mogą pobrać projekt prosto z repozytorium: http://subversion.assembla.com/svn/graph-algorithms.

Dla nie potrafiących korzystać z SVN, lub tylko chcących zerknąć na efekt prac zamieszczam tutaj gotowy instalator z potrzebnymi plikami DLL (całość opiera się o biblioteki QT4.5).

Instalator: Instalator programu Grafy-Algorytmy

Pliki: Pliki wykonywalne i skrypt instalatora

Źródła: Źródła programu Grafy-Algorytmy

Warning: Illegal offset type in symfony\plugins\sfPropelPlugin\lib\widget\sfWidgetFormPropelChoice.class.php on line 103

Rozwiązaniem generującym odpowiednie metody, zgodnym z informacją znalezioną np tutaj, było zrezygnowanie z primaryKey, i użycie klucza unikalnego.

To dwa określenia dotyczące tej samej magistrali. Jej twórcą była firma PHILIPS, która do teraz jest właścicielem znaku handlowego I2C. Dlatego też inne implementacje tego standardu są często określane w inny sposób - np.  Atmel nazywa ten interfejs TWI. Na połączenie składają się dwie linie, zegarowa (oznaczana najczęściej SCK/SCL) i danych (oznaczana SDA), łącząca wszystkie urządzenia na danej magistrali. Więcej o samym sposobie działania i podłączania można przeczytać w internecie.

Obsługa interfejsu I2C w mikrokontrolerach AVR

Zakładam, że korzystamy z mikrokontrolera posiadającego sprzętowe wsparcie dla tego interfejsu. Pozwala nam to obsługiwać ten interfejs na poziomie bajtów, z prędkościami nieosiągalnymi przy emulacji za pomocą zmian stanów portów (bitbang). Przykład, który tutaj zamieszczam został sprawdzony na uC ATmega8, jednak powinien być w pełni przenośny na każdy mikrokontroler AVR ze sprzętowym wsparciem I2C.

Program obsługuje zegar czasu rzeczywistego Maxim/Dallas,DS1338. Ze względu na stosunkowo rzadkie odczyty zrezygnowałem z trudniejszej obsługi za pomocą przerwań - odczyty i zapisy blokują pracę mikrokontrolera. Obsługę podzielono na dwa fragmenty:

• twi_basics.c, twi_basics.h, zawierające funkcje odnoszące się bezpośrednio do rejestrów kontrolnych (TWCR) i danych (TWDR) oraz oczekujące na ukończenie operacji.
• ds1338.c,ds1338.h, zawierające funkcje do bezpośredniej obsługi podłączonego zegara, odczyt/zapis czasu, wykorzystanie pozostałych 56bajtów NVRAM.

Cała obsługa sprawdza wartości zwracane przez magistralę i informuje o wyniku operacji za pomocą kodów błędu zdefiniowanych w plikach nagłówkowych. Ułatwia to znajdowanie ewentualnych problemów,  nie eliminuje niestety wszystkich możliwych problemów.

Obsługę innych urządzeń można łatwo skonstruować korzystając z funkcji zawartych w twi_basics, dodając tylko interfejs do danego układu. Dla wielu urządzeń istniejąca biblioteka ds1338 będzie wymagała tylko niewielkich zmian, gdyż filozofia dostępu do danych jest identyczna.

Do samych plików dołączam przykład ilustrujący działaniem wystarczający do zrozumienia jej wykorzystania. Zachęcam do samodzielnego studiowania źródeł, zarówno tych jak i innych spotykanych w internecie, w celu lepszego zrozumienia problemu.

Załącznik:

Biblioteka DS1338, oparta o TWI

Po przetrząśnięciu kawałka internetu znalazłem rozwiązanie, którego efekty są naprawdę znaczące (usunięcie zbędnych funkcji potrafi zaoszczędzić dużo miejsca gdy korzystamy z bibliotek zawierających funkcje na każdą okazję), i w związku z tym warte powtórzenia w wielu innych programach - pozwoli to uniknąć ręcznego usuwania nieużywanego kodu z "biblioteki".

Ustawienie kompilatora

Okno Project Properties z dodanym poleceniem ffunctions-sections

Aby móc usuwać nieużywane funkcje, muszą one w pliku wynikowym kompilatora być odrębnymi częściami. Zachowanie takie wymusza dodatkowy argument w poleceniu kompilatora:

-ffunction-sections

Dodanie takiej komendy w projekcie przy użyciu Makefile:

CFLAGS += -ffunction-sections

Przy korzystaniu z Środowiska Eclipse dla AVR należy z kolei polecenie dodać w ustawieniach projektu.

Z menu Eclipse wybieramy Project -> Properties,
następnie odnajdujemy C/C++ build -> Settings.
I przy wybranym configu Release, w zakładce Tool Settings wybieramy Optimizations z zakładki AVR Compiler. W polu Other Optimizations flag dopisujemy nasze "-ffunction-sections"

Ustawienia linkera

Okno Project Properties z dodanym poleceniem gc-sections

Poprzednio dodane polecenie umieści każdą funkcję w osobnej części pamięci - sekcji. Teraz pozostaje poinformowanie linkera, iż sekcje nie używane mają zostać usunięte - umożliwia to polecenie przekazane do linkera -gc-sections (gc od garbage collector). Tego również można dokonać poprzez plik Makefile lub ustawienia projektu.

Dla Makefile wystarczająca modyfikacja to

-Wl,-gc-sections

Z kolei w Eclipse będąc już w Project -> Properties-> C/C++ build -> Settings ->(Release) Wchodzimy w zakładkę AVR C Linker->General, i dodajemy polecenie "-Wl,-gc-sections"

U mnie taka modyfikacja ustawień pozwoliła na przykład usunąć jedyną funkcję używającą arytmetyki zmiennoprzecinkowej, zamieniając 2,5kB programu w 600bajtów.

Kiedy próbujemy stworzyć oprogramowanie na uC stajemy często przed problemem wymiany danych z naszym komputerem PC.  Sposobów na połączenie własnego układu z komputerem PC jest przynajmniej kilka:

• Port LPT
  Możliwość niezależnego manipulowania bitami sprawia że to jedno z najprostszych rozwiązań. Poza zwykłym równoległym przekazywaniem informacji można również emulować interfejsy szeregowe. Obecnie laptopy bardzo rzadko posiadają taki interfejs, a nawet jeśli, są to często modele droższe od powszechnie spotykanych.
• Port COM
• Powszechny interfejs szeregowy. Poza podstawowymi liniami służącymi do transmisji i odbioru danych zawiera też linie sterujące przepływem danych. Pod względem sposobu transmisji do komunikacji wystarczy połączenie naprzemiennie sygnałów Tx<->Rx portu COM i mikrokontrolera. Niestety, w warstwie fizycznej całkiem inne poziomy napięć nie pozwalają na takie połączenie. Powstało wiele układów służących do konwersji napięć między poziomem uC a portu COM. Często więc na płytce montowało/montuje się po prostu MAX232 do konwersji napięć podpięty pod odpowiednie nóżki mikroprocesora, i łączony z portem COM komputera. Stety/niestety porty COM też należą już do laptopowej rzadkości. Rozwiązanie polegające na używaniu przejściówek USB<->COM wraz z takimi układami jest często spotykane, pomimo wiążącego się z tym narzutu - dwukrotna konwersja napięć nie ma sensu.
  
• Port USB
  Jeśli odrzucimy to czego w laptopie nie ma, i zrezygnujemy z przejściówek pozostaje nam po prostu użycie portu  USB, który zadomowił się w komputerach już na dobre.  Tutaj też mamy kilka możliwości:
  • Emulacja interfejsu USB za pomocą uC.
    Niestety programowa realizacja interfejsu USB utrudnia wykonywanie innych zadań, dlatego maksymalna wydajność takiego rozwiązania nie jest oszałamiająca. Mikro kontroler musiałby zajmować się wyłącznie obsługą USB, lub zrezygnować z wykonywanych przez siebie czynności. Urządzenia tak działające często komunikują się programowo z USB i np. przesyłają dane dalej przez wspierane sprzętowo interfejsy (np. UART, SPI)
  • Wykorzystanie specjalizowanego układu
    Sama firma FTDI produkuje kilka układów umożliwiających komunikacje za pomocą UART, użytym rozwiązaniem jest najprostszy z nich FT232RL. Umożliwia on w pełni sprzętowe przejście USB<->UART, wraz z dodatkowymi liniami (sterującymi przepływem, pochodzącymi z portu COM) oraz dodatkowymi 4 portami, które można zastosować jako dowolne wejścia wyjścia. Układ posiada również bardzo dobre wsparcie producenta: sterowniki pod większość systemów operacyjnych, biblioteki ułatwiające programowanie komunikacji czy też przykłady zastosować w nocie katalogowej (możliwe aplikacje układu). Poza przedstawionym tutaj zastosowaniem istnieje wiele wiele innych - wystarczy przejrzeć dokumentacje: na http://www.ftdichip.com/Documents/DataSheets/DS_FT232R.pdf

Wykonany układ

Opierając się właśnie na wspomnianych notach aplikacyjnych, i materiałach samemu przejrzanych jak i konsultacjach z bardziej doświadczonymi kolegami, zaprojektowałam układ będący interfejsem Komputer PC <-> mikrokontroler. Główne zalety wykonanego urządzenia:

• Sprzętowy, niezawodny i wydajny interfejs.
• Współpraca z urządzeniami zasilanymi praktycznie dowolnym napięciem - za pomocą zworki do wyboru 3.3 jak i 5 volt, ewentualnie możliwość podpięcia własnego napięcia VCCIO do układu.
• Dodatkowe 4 porty GPIO, które można kontrolować z poziomu aplikacji pisanych z wykorzystaniem bibliotek dostarczonych przez FTDI.
• Dodatkowe wyprowadzenia zasilania, poza wspólną masą dodatkowo 2 linie 3.3V o łącznej wydajności prądowej 50mA i 6 linii 5V pochodzących z portu USB o wydajności ograniczonej komputerem/standardem USB - w moim przypadku komputer jest w stanie dostarczyć tyle prądu, limitem jest więc standardowe 500mA.
• Sygnalizacja transmisji jak i poprawnego zasilania za pomocą diod LED.

Poniżej kilka zdjęć wykonanego układu:

Oraz schemat urządzenia:

usb2uart-schemat

Układ przynajmniej pod względem poprawności połączeń i transmisji UART przetestowany wraz z prezentowanym poprzednio mikrokontrolerem.

Jako, że tematyka tych małych i tanich procesorów wciąż jest dla mnie interesująca zamieszczam schemat i wzór płytki PCB oraz opisu dla małego urządzenia, które wykonałem w ostatnim czasie.

Na początek kilka zdjęć finalnej wersji płytki:

Płytka umożliwia proste budowanie układów dzięki wyprowadzeniu wszystkich złącz na goldpiny. W przeciwieństwie jednak to prostych modułów rozprowadzających wszystkie nóżki na pary goldpinów, tutaj zintegrowano również podstawowe, przydatne funkcjonalności:

• Zintegrowany kwarc 16 MHz, pozwalający korzystać z największej teoretycznie możliwej prędkości tego mikro kontrolera.
  Za pomocą fusebitów możemy ten zegar podzielić przez 8 lub też z niego zrezygnować na rzecz wewnętrznego generatora RC.
• Zintegrowany kwarc 32768Hz, wpięty do pinów przeznaczonych na taki kwarc/służących jako zwykłe IO.
  Podwójny Dipswitch umożliwia jego odcięcie w przypadku chęci skorzystania raczej z portu IO.
• Wyprowadzone złącze do ISP, 10 pinowa zgodne z standardem KANDA. Zamiast zwykłych goldpinów zastosowano Gniazdo, co ułatwia poprawne wpięcie programatora.
• Wyprowadzono 10 pinowe złącze JTAG, zgodne z JTAG ICE.
• Przycisk umożliwiający ręczne zresetowanie procesora.
• I oczywiście zasilanie wraz z kondensatorami.

Do wpisu załączam schemat, w razie potrzeby proszę o kontakt mailowy- podeślę  pozostałe pliki.

Schemat płytki prototypowej

Silniki_krokowe - pobierz

Instalacja WinAVR

Pierwszą częścią zestawu, niezbędną w pracy będzie kompilator WinAVR, dostępny pod adresem http://winavr.sourceforge.net/. Nie będę się rozpisywał na jego temat, gdyż przekracza to zakres tego wpisu, w dodatku jest bardzo szeroko opisane w internecie. Sama strona pobierania WinAVR na SourceForge.net znajduje się tutaj.

W trakcie instalacji najlepiej nie zmieniać domyślnej ścieżki, i pozwolić na dopisanie jej do zmiennej systemowej PATH, zwłaszcza jeżeli nie używamy innych kompilatorów korzystających z make (jeśli używamy, warto skorzystać np. ze skryptu wsadowego do odpalania środowisk tak, aby zmienną PATH modyfikować dynamicznie, i zawsze odpalać właściwy make, gdyż często różne wersje dołączane do aplikacji nie są ze sobą kompatybilne). Jeśli zamierzamy używać Eclipse, warto odznaczyć również instalacje Programmers Notepada.

Po instalacji warto uruchomić ponownie komputer tak, aby dopiski do zmiennej PATH zaczęły działać.

Instalacja i konfiguracja Eclipse

Podstawowym  środowiskiem edycyjnym będzie Eclipse, wraz z narzędziami do programowania w języku C/C++ rozprowadzany jako Eclipse CDT. Jego instalacja jest prosta, opisałem ją zresztą jakiś czas temu tutaj.

Po zainstalowaniu Eclipse, będziemy potrzebowali jeszcze dodatkowej wtyczki, która ułatwia tworzenie projektów, zarządzanie nimi, pisanie kodu jak i jego kompilacje.

Wtyczka ta jest dostępna pod adresem http://avr-eclipse.sourceforge.net, konkretnie na stronie pobierania. Najprostsza droga instalacji to skorzystanie z menedżera pakietów dostępnego w Eclipse, ją tez krótko opiszę.

1. Uruchamiamy Eclipse, ewentualnie tworzymy już nowy Workspace na projekty AVR.
2. Wybieramy z menu Help->Software Updates.
3. W zakładce Available Software wybieramy Add Site...
4. Wpisujemy/wklejamy adres znaleziony na stronie pobierania, w moim wypadku to http://avr-eclipse.sourceforge.net/updatesite/.
5. Na liście, która prawdopodobnie automatycznie się rozwinie, zaznaczamy oba pola, czyli w praktyce całą stronę wklejoną wcześniej.
6. Klikamy Install, i po przejściu przez prostą procedurę instalacji w stylu Next, Accept, Next i zamknięciu okienka Software Updates nastąpi instalacja zakończona propozycją ponownego uruchomienia środowiska Eclipse.

Po zakończeniu powyższych czynności dysponujemy już zarówno kompilatorem, jak i środowiskiem edycyjnym.

Instalacja AVRStudio

Pomimo wielu prób stworzenia symulatora z możliwością debugowania programów napisanych na mikrokontrolery, wciąż najlepszym rozwiązaniem (ze znanych mi w tej chwili) pozostaje oryginalny debugger zintegrowany z AVRStudio, pozwalający na symulację i debugowanie programów na uC AVR.

Pobierania AVR Studio należy rozpocząć tutaj: http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=2725. Niestety, sam doświadczyłem niekompatybilności najnowszej wersji (4.15 przy poprzedniej instalacji), z moim system Windows XP sp3 PL, dlatego w razie problemów należy spróbować użyć innej wersji (4.14 zadziałała wtedy, 4.16 też już działa).

Samo pobieranie wymaga wyjątkowo denerwującej rejestracji- Atmel nie tworzy nam konta, tylko pyta o te same dane przy każdym pobieraniu. Dlatego nie warto skrupulatnie wypełniać rubryczek, zwłaszcza, że zawierają szczegółowe dane o naszej osobie.

Instalacja przebiega bezproblemowo, AVR Studio gotowy do pracy.

Pierwszy projekt w Eclipse

Utworzę teraz nowy projekt, oraz podpowiem jak go skonfigurować, aby możliwa była współpraca z ww debugerem. W tym celu uruchamiamy Eclipse, i wykonujemy nastepujące kroki:

1. Z menu File->New wybieramy "C Project".
2. Uzupełniamy jego nazwę, i w Project Type wybieramy "AVR Cross Target Application".
3. Przechodzimy dalej (Automatycznie zaznaczył nam się jedyny dostępny Toolchain).
4. Na następnej stronie pozostawiamy zaznaczone obie konfiguracje, wchodzimy w Advanced Settings.
5. W zakładce AVR ustawiamy typ docelowego procesora, jego częstotliwość oraz ewentualnie konfigurujemy programator (opiszę to przy następnej okazji).
6. Wchodzimy w zakładkę "C/C++ build", w część Settings.
7. Widzimy teraz listę ustawień kompilatora, linkera etc, w dodatku możemy modyfikować ją dla obu konfiguracji kompilatora, wybierając Debug/Release u góry okna.
8. Aby debugować kod w AVR Studio potrzebujemy posiadać niezbędne informację w pliku elf, w tym celu w wyżej wymienionych ustawieniach, w sekcji Debugging, zarówno dla AVR Assembler jak i AVR Comiler ustawiamy Debug info format  na dwarf-2.
9. Akceptujemy wszystkie ustawienia klikając OK i przechodzimy do następnego etapu.
10. W następnym oknie ponownie wybieramy docelowy MCU oraz wpisujemy jego częstotliwość.

Utworzony projekt jest pusty, dlatego musimy jeszcze dodać przynajmniej jeden plik źródłowy, klikając na File, New, C Source File i wypełniając go treścią. Ja wykorzystałem listing pochodzący z kursu programowania mikroprocesorów w C z czasopisma "Elektronika dla wszystkich":

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
	DDRD=0x7c;
	for(;;)
	{
		PORTD=0x7c;
		_delay_loop_2(0xffff)
		PORTD=0;
		_delay_loop_2(0xffff);
	}
	return 0;
}

Po zapisaniu pliku pozostaje zbudowanie pliku, za pomocą menu Project->Build.

W katalogu Debug, wewnątrz naszego projektu powstanie m.in. plik nazwaprojeku.elf, który można symulować wraz z podglądem źródeł w AVR Studio.