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.