42-ie Spotkanie ŚRGM i PLSSUG Katowice

Autor: Dondu

28 mara 2013 Śląska Regionalna Grupa Microsoft'u oraz Polish SQL Server Group organizują spotkanie, na którym omawiane będą dwa tematy, w tym temat XMEGA prowadzony przez Tomasza Francuza (Tmf). Wstęp wolny, po zarejestrowaniu.

Poradnik wdrażania Private Cloud czyli klient vs. architekt
2013-03-28 18:10:00 - 2013-03-28 19:25:00, Kamil Skalski
Chmura prywatna to nie tylko Hyper-V i System Center! Praktyczne podejście do wdrożenia rozwiązań Cloud wymaga wykorzystania znacznie większego zbioru technologii, a w szczególności ich właściwej integracji, by odpowiedzieć na potrzeby klientów. Gdy architekt rozwiązania Private Cloud spotyka się ze swoim klientem rozpoczyna się proces układania kolejnych elementów wielkiej układanki informatycznej. Podczas sesji przedstawione zostaną najczęściej spotykane problemy klientów, ich potrzeby oraz przykładowe sposoby praktycznych rozwiązań.

Mikrokontrolery AVR XMEGA - specyfika programowania
2013-03-28 19:35:00 - 2013-03-28 20:50:00, Tomasz Francuz
Małe jest piękne. Pisząc różne aplikacje na "duże" komputery czesto zapominamy, że nasze otoczenie nie kształtują rzeczy duże, lecz małe. Sprawne funkcjonowanie naszego świata w co raz większym stopniu zależy od mikrokontrolerów i aplikacji na nich działających. Począwszy od klawiatury, a skończywszy na bioimplantach - wszystkim tym zawiadują niestrudzeni mali robotnicy - mikrokontrolery. Warto więc poznać je bliżej, a może nawet nauczyć się nimi posługiwać. Tym bardziej, że większość potrzebnych w tym celu narzędzi i wiedzy już masz. Może dzięki tej prezentacji odkryjesz w sobie programistę embedded, znajdziesz nową, ciekawą pracę? Postaram się pokazać główne różnice w programowaniu "dużych" komputerów i małych mikrokontrolerów na przykładzie nowej rodziny wydajnych i superenergooszczędnych mikrokontrolerów AVR XMEGA.

Termin: 28 marca 2013

Miejsce: Katowice, ul. 1-go Maja 133, budynek Kamsoft S.A., sala kinowa, poziom -1

Dodatkowe informacje:
- otwarty, bezpłatny parking na tyłach budynku.
- dojazd z centrum Katowic - tramwajami w kierunku Zawodzia.

Agenda:
17:30 - 18:00 - Rejestracja
18:00 - 18:10 - Rozpoczęcie spotkania, sprawy organizacyjne
18:10 - 19:25 - Poradnik wdrażania Private Cloud czyli klient vs. architekt (Kamil Skalski)
19:25 - 19:35 - przerwa
19:35 - 20:50 - Mikrokontrolery AVR XMEGA - specyfika programowania (Tomasz Francuz)
20:50 - 21:00 - Losowanie nagród, zakończenie spotkania.

Rejestracja
Prosimy o rejestrowanie się na spotkanie.

Udział w spotkaniu jest bezpłatny.

Oficjalna strona: 42. Spotkanie ŚRGM i PLSSUG Katowice

DSO uLAB1 - Uruchomienie wyświetlacza.

Autor: drzasiek
Redakcja: dondu

Wielu początkujących programistów, stając przed potrzebą użycia w swoim projekcie wyświetlacza graficznego, nie zdaje sobie sprawy w jaki sposób taki wyświetlacz działa, oraz jak się z nim komunikować.

Dodatkowym problemem jest wybór wyświetlacza ze względu na cenę (kolorowe wyświetlacze graficzne niestety nie są tanie) oraz czy za taką cenę dany wyświetlacz będzie posiadał odpowiednie możliwości oraz czy zdoła go obsłużyć.

Warto w takich przypadkach skorzystać z gotowych modułów, gdzie nie trzeba się martwić o odpowiednie podłączenie i zasilenie wyświetlacza oraz najlepiej, jeśli można dostać przykładowy program demonstracyjny, aby nie trzeba było rozgryzać danego sterownika od zera wertując setki stron dokumentacji.

W poniższym artykule przedstawię moduł wyświetlacza HY-28A:

HY-28A

jaki został użyty w module DSO uLAB1 oraz omówię w skrócie i zamieszczę bibliotekę obsługi tego wyświetlacza wraz z przykładowym projektem demonstracyjnym, utworzonym w Atmel Studio 6.


Moduł HY-28A

Jest to moduł z wyświetlaczem LCD TFT o przekątnej 2.8 cala, rozdzielczości 320x240 pikseli i 16 bitowej głębi kolorów. Wyświetlacz obsługiwany jest za pomocą sterownika ILI9320, w tym konkretnym module poprzez interfejs SPI. Dodatkowo, wyświetlacz posiada zintegrowany rezystancyjny panel dotykowy wraz ze sterownikiem XPT2046 zamontowanym na module, z którym komunikacja odbywa się również za pomocą interfejsu SPI.

Moduł posiada dodatkowo wbudowany stabilizator napięcia 3.3V oraz sterownik podświetlenia (domyślnie załączony). Poniżej kilka dokumentacji technicznych, które warto pobrać i zapisać:

• Wymiary modułu
• Schemat ideowy modułu
• Dokumentacja sterownika ILI9320
• Nota aplikacyjna sterownika ILI9320
• Dokumentacja sterownika XPT2046

Podłączenie do mikrokontrolera

Sterowniki wyświetlacza oraz panelu dotykowego zostały podłączone z mikrokontrolerem za pomocą interfejsu USART. Ale zaraz zaraz, przecież dopiero pisałem, że z tymi układami komunikujemy się za pomocą interfejsu SPI. Co jest grane?

Już wyjaśniam. Ponieważ jeden z dwóch dostępnych w tym mikrokontrolerze interfejsów SPI nie mógł być wykorzystany ze względu na współdzielenie pinów z USB, a drugi został wykorzystany do karty pamięci, zmuszony byłem obejść ten problem w taki sposób, aby urządzenia ze sobą nie kolidowały. Ponieważ wyświetlacz i panel dotykowy komunikują się z mikrokontrolerem w innym trybie SPI niż karta pamięci, nie mogłem ich bez przeszkód umieścić na tym samym interfejsie, ponieważ by ze sobą kolidowały i znacznie spowalniały pracę.

Dlatego też do wyświetlacza postanowiłem wykorzystać USART w trybie SPI. Co to znaczy? To znaczy tyle, że USART w mikrokontrolerach XMEGA można tak ustawić, że będzie kompatybilny z SPI.

Podłączenie wyświetlacza do mikrokontrolera można znaleźć na schemacie całej płytki w poprzednim artykule: DSO uLAB1 - Opis modułu


Przykład

A oto przykładowy projekt demonstracyjny przygtowany w Atmel Studio 6.
Pobierz: DSO_uLAB_LCD.rar
Kopia: DSO_uLAB_LCD.rar

Biblioteka obsługi wyświetlacza może zawierać podobne do dostępnych w internecie przykładowych funkcji. Funkcje te powstawały przez pewien okres czasu, ewaluowały z projektu na projekt. Nie jestem w stanie powiedzieć, czy nazewnictwo nie zostało wzorowane na dostępnych w internecie przykładowych kodach.

Projekt składa się z następujących plików:

• main.c – główny plik źródłowy programu
• ILI9320.c – plik źródłowy z deklaracjami funkcji obsługi wyświetlacza
• ILI9320.h – plik nagłówkowy z definicjami wyprowadzeń, kolorów
• fonts.h – plik nagłówkowy z tablicami wartości czcionek
• images.h – plik nagłówkowy z tablicą wartości obrazka wyświetlanego na LCD
• config.c – plik źródłowy z deklaracjami funkcji konfigurujących mikrokontroler
• config.h – plik nagłówkowy z definicjami do konfiguracji

A oto program główny z opisem poszczególnych linii:

#include <avr/io.h>

#include <util/delay.h>

#include <inttypes.h>

#include "ILI9320.h"

#include "images.h"

 

int main(void)

{

   PORTD_DIR |= (1<<5);//konfiguruje podświetlenie - wyjście

   PORTD_OUT &=~ (1<<5);//konfiguruje podświetlenie – stan niski (wyłączone)

   clock32MHz_init();//włącza zegar 32 MHz

   CCPWrite (&MCU_MCUCR, MCU_JTAGD_bm);//wyłącza JTAG

   PORTF_DIR |= (1<<7);//konfiguruje linię Touch Panel CS - wyjście

   PORTF_OUT &=~ (1<<7);//Touch Panel CS = 0

   LCD_Init();//inicjalizacja LCD

   LCD_Clear(BLACK);//czyści ekran (zapełnia kolorem)

   PORTD_OUT |= (1<<5);//włącza podświetlenie

   LCD_Clear(GREEN);//czyści ekran (zapełnia kolorem)

           
   lcd_str_med_pio("Test czcionki medium",0,3,YELLOW,GREEN);//wyświetla tekst

   lcd_str_small_pio("Test czcionki small",0,20,ORANGE,GREEN); //wyświetla tekst

   lcd_Pixel (20,50,RED);//rysuje pixel

   lcd_Line_poz(10,310,230,WHITE);//rysuje linię poziomą

   lcd_Line_pio(10,40,230,WHITE);//rysuje linię pionową

   lcd_Area(50,150,50,50,BLUE);//zapełnia obszar kolorem

   lcd_line(10,310,40,230,PINK);//rysuje dowolną linię

   lcd_Image(test_img,190,60,40,112);//rysuje obrazek z tablicy danych

   lcd_Frame(188,59,42,115,2,RED); //rysuje ramkę

  
   while(1);  //pętla główna

}

Myślę, że poszczególne funkcje są napisane w taki sposób, że nie potrzeba tłumaczenia jakich argumentów wymagają i co robią.

Obsługa została napisana w taki sposób, aby punkt (0,0) znajdował się w lewym górnym roku ekranu (w normalnym położeniu urządzenia).

A oto fotografia, co powinno pojawić się na ekranie po wykonaniu tego programu demonstracyjnego:

W kolejnym artykule pokażę jak uruchomić i korzystać z panelu dotykowego oraz zamieszczę prosty program demonstracyjny z jego wykorzystaniem.

XMEGA: Emulacja portu szeregowego na XMEGA

Autor: tmf

Redakcja: Dondu

Artykuł jest częścią cyklu: Wstęp do XMEGA

Czy tego chcemy, czy nie port RS-232 powoli wymiera. Nowe laptopy go praktycznie nie posiadają, płyty główne normalnych PC-ów jakoś się jeszcze bronią. Co prawda RS-232 nie jest już zazwyczaj wyprowadzany na złącze z tyłu płyty, niemniej gdzieś tam, w czeluściach PCB możemy zazwyczaj ciągle znaleźć małe, 10-pinowe złącze, pod które można podłączyć śledzia z gniazdem RS-232.

Pytanie tylko po co?

RS-232 niewątpliwie jest prosty, ale z punktu widzenia elektronika ma dwie poważne wady:

1. wymaga konwertera poziomów (tzw. transceivera, np. max232), jest to układ tani, ale zajmuje miejsce na PCB, wymaga zwykle 4 zewnętrznych kondensatorów, no i zawsze to jakiś element dodatkowy,
2. złącze RS-232 nie ma wyprowadzonego zasilania. Co prawda parenaście mA można wyciągnąć z nieużywanych linii interfejsu, jednak nie jest to za wiele.

A jakie RS-232 ma zalety? Dosyć poważne:

• prostota - nawet początkujący uruchomi transmisję w ciągu kilkunastu minut,
• w USART wyposażony jest praktycznie każdy mikrokontroler, a nawet jeśli nie jest, to stosunkowo łatwo go emulować programowo.
• możliwość komunikacji na duże odległości.

Wydaje się, że przedstawione zalety przeważają tym bardziej, że zanikający port RS-232 możemy zawsze protezować wykorzystując różnego typu przejściówki, z których najpopularniejsze oparte są na znanym układzie FT232 i różnych jego odmianach. Inna strategia polega na programowej emulacji USB bezpośrednio w procesorze dzięki bibliotece V-USB.

Emulacja programowa USB z pewnością jest tania i wymaga tylko kilku prostych elementów zewnętrznych, ale bardzo obciąża procesor i nie do końca jest zgodna ze standardem USB.

Z kolei wykorzystanie przejściówek opartych na FT232 kosztuje:

• sam układ FT232 około 14-18zł (cena 2013r.), 
• do tego zajmuje on trochę miejsca na PCB (co także kosztuje), 
• no i nie każdy lubi lutować układy SMD. 

Przejściówki USB-RS232

Dla tych co nie lubią lub boją się montażu SMD różne firmy oferują zmontowane przejściówki w cenie 30-60zł. Taką przejściówkę wystarczy połączyć przy pomocy listy kołkowej z naszym układem i możemy się cieszyć możliwością komunikacji z PC przy pomocy wirtualnego portu szeregowego. Co ważne, od strony mikrokontrolera komunikacja ciągle przebiega z wykorzystaniem interfejsu USART.


Alternatywy
Wszystko pięknie, ale świat idzie do przodu i to co było na topie 2-3 lata temu obecnie niekoniecznie jest najlepszym rozwiązaniem. Na rynku mikrokontrolerów, w tym mikrokontrolerów AVR, pojawiły się układy dysponujące wbudowanym interfejsem USB (w wersji host, jak i device).

W rodzinie AVR sprzętowy interfejs USB-device (co wystarcza do implentacji dowolnego urządzenia USB podłączanego do PC) posiadają mikrokontrolery ATMega z literką U w nazwie.

Literka U musi być przy oznaczeniu mikrokontrolera, a nie po myślniku – wtedy znaczy coś innego.

Czyli np. ATMega32U2 posiada interfejs USB, z kolei ATMega32-AU, to zwykły mikrokontroler bez tego interfejsu.

Tak samo jest w rodzinie Xmega - ATXMEGA128A1U posiada sprzętowy interfejs USB, a ATXMEGA128A1-AU nie posiada.

Niemniej obecnie (2013r.) nie ma właściwie żadnego uzasadnienia dla używania rodziny ATMega, gdyż pod każdym względem (także cenowym) lepsze od nich są mikrokontrolery XMEGA.

Taki interfejs posiadają także pokazane wcześniej minimoduły z mikrokontrolerami XMEGA256A3-BU i XMEGA128A3U. Co więcej, posiadane moduły są wyposażone w gniazdo USB i wszystko co do komunikacji jest wymagane. Spróbujmy więc je wykorzystać.

---

Podłączenie - schemat

Jeśli ktoś nimi nie dysponuje i nie jest przekonany do bezpośredniego łączenia procesora z USB poniżej pokazuję schemat takiego połączenia. Jak widzimy jest on banalnie prosty – odpowiednie linie sygnałowe D+ i D- łączymy bezpośrednio z odpowiednimi sygnałami w gnieździe USB.

Naprawdę prościej już się nie da :-)

Jak widzimy piny mikrokontrolera PD7 i PD6 są połączone bezpośrednio z odpowiednimi stykami gniazda USB. Jest to możliwe, gdyż XMEGA posiadają wewnętrzne układy dopasowujące. Oczywiście zwolennicy dmuchania na zimne mogą umieścić dodatkowe rezystory szeregowe na tych liniach (typowo 22Ω).


Zasilanie

Warto zwrócić uwagę na jeszcze jedną rzecz – USB dostarcza napięcia zasilającego, które możemy wykorzystać do zasilania podłączonego układu (maksymalna wydajność przed enumeracją to 100mA, po enumeracji 500mA dla USB do 2.0 i 900mA dla USB 3.0 lub 1,5A bez jednoczesnej transmisji danych).

Jednak napięcie na tym interfejsie (około 5V) jest wyższe niż dopuszczalne dla XMEGA (maksymalnie 3,6V). Stąd też jeśli chcemy zasilać XMEGA z USB musimy dodać zewnętrzny regulator napięcia, typu low-drop (bardzo ważne, ze względu na niewielką różnicę napięć pomiędzy wejściem a wyjściem). Nie jest to żadnym problemem, gdyż zazwyczaj i tak jakiś regulator w układzie mamy.

Warto podkreślić, że posiadacze pokazanych wcześniej modułów, mają już taki regulator zamontowany. Odpowiednią zworką mogą wybierać zewnętrzne źródło napięcia lub zasilanie z USB.

Jak widzimy połączenia elektryczne są niezwykle proste, warto ewentualnie pomyśleć o dodatkowym filtrowaniu napięcia z USB (komputer jest potężnym źródłem zakłóceń), ale dla naszych rozważań nie jest to niezbędne.


Kwarc, czy generator wewnętrzny RC?

Uważni obserwatorzy naszego bloga i osoby znające się co nieco na AVR-ach z pewnością zaprotestują – jak to, a gdzie kwarc? Przecież na wewnętrznym generatorze RC, to w życiu nie zadziała!

No i są w błędzie. XMEGA posiadają naprawdę stabilny wewnętrzny generator RC, w efekcie nie tylko do realizacji transmisji RS-232, ale nawet do pracy z wykorzystaniem USB żadne zewnętrzne elementy nie są potrzebne! Tak więc przedstawiony schemat jest kompletnym, działającym układem interfejsu XMEGA-USB.

---

Program

Ok, mamy sprzęt, czas na program. W pokazanej implementacji wirtualnego portu szeregowego wykorzystane zostanie oprogramowanie dostarczone przez firmę Atmel.

Firma ta jest tak miła, że za darmo dostarcza nam gotowych bibliotek i przykładów. Taką gotową biblioteką zawierającą wszystko co potrzeba do realizacji RS-232 przez USB jest ASF (Atmel Software Framework).

Biblioteka trochę ciężka i na pierwszy rzut oka skomplikowana, dlatego osobiście preferuję „własne” rozwiązania. Ale nie ma co wyważać otwartych drzwi – zamiast narzekać wykorzystałem gotowy kod, tylko nieco go „odchudziłem” wyrzucając zbędne komponenty ASF i niepotrzebne definicje.

Lecz dobra wiadomość jest taka – dzięki pokazanemu przykładowi w ogóle nie musisz zagłębiać się w tajniki implementacji CDC (USB communications device class – klasy urządzeń komunikacyjnych, do których zalicza się m.in. urządzenie wirtualnego portu szeregowego). Miało być prosto – i będzie prosto!

Tak więc mamy nieco zmodyfikowaną bibliotekę firmy Atmel implementującą klasę CDC, dzięki czemu w ogóle nas nie interesuje jak to wszystko działa. Natomiast interesuje nas (a przynajmniej powinno) poznanie jak z tego korzystać.

Czas więc ściągnąć przykładowy projekt – jest on przygotowany dla Atmel Studio 6.1 i w tym programie możemy go bezpośrednio otworzyć. Ze wszystkich plików, które są zawarte w tym projekcie interesuje nas plik main.c, w którym znajduje się cała obsługa RS-232:

Przykład 1 (w kompilatorze)

int main(void)
{
  //Włączamy wszystkie poziomy przerwań (potrzebujemy tylko najniższy)
  PMIC.CTRL = PMIC_LOLVLEN_bm | PMIC_MEDLVLEN_bm |
              PMIC_HILVLEN_bm; 
  sei();

  sysclk_init();
  udc_start();

  while (1) {
    char ch;

    if (udi_cdc_is_rx_ready()) {
      ch = udi_cdc_getc();
      switch(ch) {
         case 'n'       :
           udi_cdc_write_buf("Pozdrowienia z XMEGA!\n\r", 23);
           break;
         default        :
           udi_cdc_write_buf("O co chodzi?\n\r", 14);
           break;
      }
    }
  }
}

Co nasz przykład robi?

Jak widzimy najpierw włączane są przerwania. Ponieważ kontroler przerwań w XMEGA obsługuje trzy poziomy przerwań, włączamy je wszystkie (chociaż nasz sterownik USB wykorzystuje tylko przerwania najniższego poziomu) i ustawiamy globalną flagę zezwolenia na przerwania instrukcją sei().

Następnie inicjalizowane są podsystemy mikrokontrolera – zegar oraz włączany jest sterownik USB.
Implementacja USB zaproponowana przez firmę Atmel jest o tyle fajna, że wykorzystuje ona przerwania i bufory, w efekcie cała obsługa USB jest zupełnie niezależna od kodu użytkownika.

Od tego momentu nasz mikrokontroler może wymieniać dane z PC udając port szeregowy.

W pętli głównej, sprawdzamy czy w buforze odbiornika znajduje się jakiś znak - funkcja udi_cdc_is_rx_ready(), jeśli tak to go odbieramy. Po sprawdzeniu co to za znak podejmujemy odpowiednią akcję – wysyłamy do komputera PC łańcuch znaków - funkcja udi_cdc_write_buf().

Funkcja ta przyjmuje jako argumenty adres bufora, w którym znajduje się wysyłany łańcuch oraz jego długość. Oczywiście mamy też do dyspozycji funkcję udi_cdc_putc(int value), która wysyła jeden znak (argument value).

I to wszystko, prawda, że proste?

Część osób uważnie czytających ten artykuł z pewnością zapyta – a gdzie inicjalizacja portu szeregowego? Przecież musimy ustawić odpowiednią szybkość transmisji, prawda?

Otóż nie. Jedną z przyjemnych cech emulacji portu szeregowego jest to, że szybkość transmisji nas zupełnie nie interesuje. Dlaczego? Ano dlatego, że jest to parametr istotny dla fizycznego interfejsu RS-232  dzięki niemu odbiornik wie jak szybko nadawane są dane przez nadajnik, co jest niezbędne, gdyż typowa transmisja RS-232 jest transmisją asynchroniczną (czyli nie przesyłamy żadnego zegara taktującego transmisję).

Tu dane wysyłane są przez interfejs USB, w efekcie sposób ich wysyłania i szybkość zupełnie nas nie interesują. Przez interfejs USB przechodzą one zawsze tak szybko jak tylko się da. To aplikacja może je wysyłać lub pobierać wolniej. W efekcie w terminalu możemy ustawić dowolną szybkość transmisji danych!

Ale zanim to zrobimy musimy wczytać nasz przykładowy program do XMEGA. Możemy to uczynić przy pomocy programatora, albo tak jak wcześniej pokazałem przy pomocy programu FLIP – właściciele prezentowanych wcześniej modułów dysponują XMEGA z preprogramowanym bootloaderem.

Po uruchomieniu programu, nasz ulubiony system powinien wykryć nowe urządzenie USB. Jeśli naszym ulubionym systemem jest MS Windows, to zapewne nie będzie on dysponował odpowiednimi sterownikami. Nie ma problemu – odpowiednie sterowniki znajdują się w katalogu RS232overUSB/RS232overUSB – plik atmel_devices_cdc.inf. Jeśli system nie znalazł właściwych sterowników, należy mu wskazać ten plik. Po poprawnym zainstalowaniu sterowników powinniśmy w menagerze urządzeń zobaczyć nowe urządzenie:

Jest nim EVK1XXX Virtual Com Port (COM7).

Dlaczego taka dziwaczna nazwa? Problem w tym, że urządzenia USB muszą posiadać swój unikalny identyfikator VID/PID. W naszym przykładzie pasożytujemy nieco na firmie Atmel, wykorzystując ich identyfikatory (pamiętaj jednak, że absolutnie nie wolno robić tego w urządzeniach komercyjnych!). 

Ponieważ użyliśmy VID/PID, który w pliku .inf ma przypisaną powyższą nazwę, stąd też nasz układ tak się przedstawia. Oczywiście można to zmienić, ale skorzystanie z pliku .inf firmy Atmel ma jeszcze jedną zaletę – jest on podpisany cyfrowo. Tak, to nie bajki, pliki tekstowe .inf też mają w Windows swoje podpisy cyfrowe.

O ile dla Windows XP i Windows 7 brak podpisu nie jest zasadniczo problemem, o tyle użytkownicy Windows 8 mieliby problem. Jeśli plik opisu sterownika (urządzenia klasy CDC nie wymagają instalacji żadnych sterowników) jest podpisany cyfrowo, to także użytkownicy Windows 8 mogą z naszego przykładu korzystać bez problemów.

Ok, na tym etapie zakładam, że twój system rozpoznał nowy układ, a sterowniki są poprawnie zainstalowane. Co dalej? Warto w menagerze urządzeń sprawdzić numer wirtualnego portu COM – na powyższym zrzucie był to COM7, ale w twoim przypadku może to być zupełnie inny port.

Nadeszła więc pora na test – odpalamy nasz ulubiony terminal. Ja używam RealTerm – nie jest to żaden cud, ale ma wszystko co jest potrzebne, no i jest za darmo (jeśli go nie masz, to go możesz pobrać stąd: http://realterm.sourceforge.net).

Uruchamiamy więc terminal, wybieramy port, który jest połączony z naszą XMEGA (możemy wybrać po numerze lub nazwie, np. \USBSER000 i zaczynamy zabawę.

A co nasz przykład robi? Po jego uruchomieniu oczekuje on na dane z komputera, po otrzymaniu litery n wysyła pozdrowienia, które powinniśmy zobaczyć na terminalu, po wysłaniu dowolnego innego znaku wysyła zapytanie „O co chodzi?” – poniższy rysunek.

I to wszystko, prawda, że proste?

Mam nadzieję, że przekonałem Was do używania USB zamiast archaicznych rozwiązań typu emulacja USB lub przejściówki USB - RS232. Jeśl będzie taka potrzeba to pokażemy więcej przykładów rozwiązań opartych na USB.


Program zajmuje 7,5kB - to dużo, czy mało?

Chwila, ale czemu ten prosty przykład zajmuje prawie 7,5kB? A dlaczego nie, pamiętaj, to XMEGA, mamy pamięci sporo! A pamięć leżąca odłogiem, to pamięć zmarnowana.

Nie przekonuje cię to? Mnie też nie  Prawda jest prozaiczna – nasz przykład, to przycięty fragment ASF – biblioteki fajnej, ale uniwersalnej. A jak wiemy za uniwersalność się płaci – najczęściej wzrostem objętości kodu i wolniejszym działaniem. Jeśli by ją dalej przyciąć i np. ustawiać zegar systemowy wpisując gotowe wartości, to spokojnie można zejść do 2-3 kB. Ciągle więcej niż w przypadku USART, ale za to o ile fajniej? :-)


Do pobrania

Pliki projektu Atmel Studio 6.1: RS232overUSB.zip

Plik IntelHex do bezpośredniego programowania dla XMEGA256A3BU (moduły Xplained XMEGA256A3BU lub moduł z modulowo.pl): RS232overUSB-XMEGA256A3BU.zip

Plik IntelHex do bezpśredniego programowania dla XMEGA128A3U (moduł z Leon Instruments): RS232overUSB-XMEGA128A3U.zip

Inne XMEGA

Jeśli posiadasz inny XMEGA niż użyty w projekcie XMEGA256A3BU, to po prostu zmień w projekcie typ procesora i przekompiluj go. Uzyskasz nowy plik hex, do zaprogramowania.



Kilka RS-232

Oczywiście możesz na raz podłączyć do PC więcej mikrokontrolerów XMEGA – w takiej sytuacji pojawią się kolejne porty szeregowe:

A czy jedna XMEGA może udawać kilka urządzeń USB? Jak sądzisz? :-)
Oczywiście, że tak, nawet nie jest to dużo trudniejsze, ale to już całkiem inna historia ...


Wstęp do XMEGA: Spis treści

DSO uLAB1 - Przenośny oscyloskop i/lub płytka prototypowa z XMEGA - Opis modułu

Autor: drzasiek
Redakcja: dondu

7 Października 2013 roku firma Modulowo oraz MSX Elektronika wprowadziły do sprzedaży moduł przenośnego laboratorium elektronicznego, o nazwie DSO uLAB1 .

Moduł ten można nabyć w sklepie modułowo lub na Allegro u sprzedającego msx_elektronika.
Szczegółowe informacje o parametrach i funkcjonalności modułu można znaleźć na stronie producenta.

Moduł ten służyć może dodatkowo jako płytka prototypowa z wyświetlaczem lub osobno sama płytka lub wyświetlacz.

Ponieważ jestem autorem projektu, postanowiłem napisać kilka artykułów z opisem płytki oraz z przykładowymi bibliotekami w języku C, aby ułatwić potencjalnym nabywcom uruchomienie poszczególnych bloków systemu według własnych potrzeb.

W tym artykule przedstawię w skrócie część sprzętową modułu.


Mikrokontroler

Na płytce zamontowany został mikrokontroler ATXMega256A3BU.

Na etapie produkcji urządzenia, ma on wgrywany bootloader, a więc do programowania go nie potrzebujemy żadnego programatora. Wystarczy kabelek USB oraz darmowe oprogramowanie firmy Atmel o nazwie FLIP. Jak zaprogramować ten mikrokontroler za pomocą programu FLIP opisał Tomasz Francuz w artykule: XMEGA: Podłączamy przez USB

Aby wejść w tryb bootloadera, należy uruchomić urządzenie z wciśniętym przyciskiem TR (najwyżej położony przycisk).

Zasilanie

Urządzenie może być zasilane za pomocą kabla USB lub z baterii 3.7V. (standardowy akumulator li-ion lub li-pol). Na płytce umieszczony został także scalony układ kontroli ładowania – MCP73834.


Wyświetlacz

Zamontowany został moduł HY-28A z wyświetlaczem LCD TFT o przekątnej 2,8 cala, rozdzielczości 320x240, 65 tys. kolorów oparty o sterownik ILI9320. Wyświetlacz posiada zintegrowany rezystancyjny panel dotykowy ze sterownikiem XPT2046. Komunikacja z wyświetlaczem oraz sterownikiem panelu dotykowego obywa się za pomocą interfejsu SPI.

Bibliotekę obsługi wyświetlacza i przykładowy program opisałem w artykule: DSO uLAB1 - Uruchomienie wyświetlacza.


Interfejs

• 4 klawisze 
• wyprowadzone łącznie 16 nóg mikrokontrolera na listwy kołkowe
• buzzer
• dioda LED

Elementy dodatkowe

• bateria 3V (CR1220) do zasilania RTC
• kwarc zegarkowy

Wejścia analogowe

Dwa wejścia analogowe z gniazdami BNC, zakres wejściowy: +/- 20 V, rezystancja wejściowa 1MΩ, podłączone do 2 przetworników analogowo-cyfrowych mikrokontrolera. Możliwość próbkowania z częstotliwością do 2MHz na kanał.


Wyjście analogowe

Jedno wyjście analogowe z gniazdem BNC, rezystancja wyjściowa 600Ω, obciążalność max ±5mA, napięcie wyjściowe ±2V, podłączone do przetwornika cyfrowo-analogowego mikrokontrolera. Możliwość konwersji z częstotliwością 1MHz.


Wymiana danych

Gniazdo kart pamięci microSD.


Schemat modułu

A oto schemat ideowy modułu:

Schemat ideowy modułu.

W następnym artykule przedstawię bibliotekę obsługi wyświetlacza oraz zamieszczę prosty projekt demonstracyjny.


Pytania?

Jeżeli macie jakieś pytania to z chęcią odpowiem :-)

Pozdrawiam,
Drzasiek

Xplained Mini – czyli to, co Atmel już dawno temu zrobić był powinien

Autor: tmf
Redakcja: Dondu

Ostatnio ciągle trafiają mi w ręce nowe zestawy, co warto podkreślić, głównie polskie. I to bardzo dobrze, bo są świetne.

Tym razem testom poddam nowy zestaw Atmela – Xplained Mini. Serię zestawów rozwojowych Xplained wszyscy świetnie znamy, a szczególnie znają je czytelnicy moich książek – wszystkie dołączone do nich przykłady na nich bazują. W tej serii mieliśmy do tej pory Xplained z XMEGA 128A1, 256A3BU, 32E5, pojawiły się także wersje z ARM, oraz z „większymi” ATMegami.

Wszystko pięknie, tylko, że w stosunku do produktów konkurencji miały trzy poważne wady:

• brak wbudowanego programatora (co omija wgrany bootloader),
• brak sprzętowego debugera,
• cena – 120-150 zł – nie ma tragedii, ale pięknie też nie jest.

Co więc ma zrobić fan mikrokontrolerów, który z niskim budżetem chciały rozpocząć przygodę z programowaniem? Najtaniej (ale nie najprościej) po prostu było wybrać jakiś zestaw z ARM, np. STM Discovery. Ale to się zmieniło…

Co oferuje Xplained Mini?

Moduł Xplained Mini

Pomimo nazwy Mini, nowy moduł z Atmela jest całkiem wypasiony. Ale zacznijmy od końca – ceny. W sklepie Atmela kosztuje $8 za Xplained ATMega168 Mni, do $8.50 za Xplained ATMega328 Mini. W Polsce można go kupić już za około 40 zł. 

Co za te pieniądze dostajemy? Otóż całkiem sporo:

• na pokładzie mamy w zależności od wersji procesor ATMega168P lub ATMega328P – posiadający 16/32 kB FLASH, 1-2 kB SRAM, taktowanie 16 MHz (na stałe),
• LED, przycisk oraz pole prototypowe,
• i tu uwaga – wbudowany programator/debuger!

Wydaje się niemożliwe, a jednak – dostajemy możliwość programowania i debugowania mikrokontrolera, w dodatku wszystko działa wygodnie z poziomu Atmel Studio. Dzięki temu moduł ten jest godny polecenia dla każdej osoby zaczynającej przygodę z mikrokontrolerami. Nie musimy już ślęczeć godzinami nad kodem zastanawiając się, gdzie jest błąd. Teraz możemy na żywo podglądać jego wykonanie i korzystać z wszystkich możliwości jakie do tej pory były zarezerwowane dla posiadaczy sprzętowych debuggerów, z których najtańszy – Atmel ICE PCBA kosztuje około 160 zł.

Ale to nie wszystko – nasz moduł posiada pole prototypowe, które można wykorzystać do przylutowania elementów zewnętrznych – nic ciekawego i nie za bardzo ma to sens. To co jest ważne, to że w polu tym zostały wyprowadzone wszystkie sygnały mikrokontrolera (jego piny IO), w dodatku w formacie kompatybilnym z tzw. shieldami Arduino. Dzięki temu wszystkie moduły zaprojektowane dla Arduino będą wprost współpracować z naszym Xplained Mini!

Kompatybilność z Arduino

Kompatybilność z Arduino jest ciekawą cechą Xplained Mini. Moduł ten zawiera opcjonalnie mikrokontroler ATMega328P wspierany przez Arduino, a przy tym jest tańszy od zawierającego ten sam mikrokontroler Arduino UNO, w dodatku posiada wspomniany programator/debugger. Kompatybilność oznacza, że nasz moduł po wgraniu kodu Arduino będzie po prostu działał jak oryginalne Arduino.

Mała uwaga. Kupując Xplained Mini warto kupić wersję drugą (rev. 2) – wersja ta ma dwie zmiany w stosunku do pierwszej wersji Xplained – posiada wlutowane złącze mikroUSB zamiast złącza stykowego USB A, dodatkowo posiada wbudowany stabilizator 3,3V, dzięki czemu napięcie to jest dostępne na złączu.

Aby móc podłączyć shieldy Arduino należy w pole prototypowe wlutować żeńskie gniazda dla goldpinów o rozstawie 100 milsów (2,54 mm). Proces ten jest prosty i szybki. Gniazda te warto także wlutować jeśli nie planujemy skorzystać z shieldów – można w nie wkładać kable łączące z płytką stykową lub budowanymi przez nas układami.

Podłączenie

Podłączenie naszego modułu jest niezwykle proste – po prostu we wlutowane gniazdko mikroUSB wkładamy kabel – możemy moduł w ten sposób podłączyć zarówno z komputerem PC, możemy je wykorzystać po także jako zasilanie. W tym celu kabel z wtyczką USB może pochodzić z np. zasilacza smartfona. Dzięki temu nie musimy inwestować w osobny zasilacz. Należy tylko pamiętać, że wydajność prądowa portu USB w komputerze jest dla USB 2.0 ograniczona do 500 mA, a dla USB 3.0 do 900 mA lub 1,5 A jeśli nie transmitujemy danych.

W praktyce większość płyt głównych pozwala na pobieranie znacznie większego prądu nawet z portu USB 2.0. Musimy jednak pamiętać, że jeśli pobieramy poprzez zwykły kabel USB znaczący prąd, to indukowane zakłócenia mogą uczynić niemożliwym przesył przez ten sam kabel danych. Nasz układ będzie działał, ale raczej możemy zapomnieć o programowaniu/debugowaniu, stąd też warto nie przeginać z pobieranym prądem.

Ten sam kabel USB posłuży nie tylko do zasilania układu – będzie on wykorzystywany także do programowania i debugowania w Atmel Studio. Ale to nie wszystko. Po podłączeniu do komputera nasz moduł zgłosi się jako urządzenie hybrydowe – oprócz debugera w menadżerze urządzeń zobaczymy też wirtualny port szeregowy.

Po co on jest? Tu ujawnia się kolejna miła cecha Xplained Mini. Port szeregowy mikrokontrolera ATMega168/328 jest podłączony do znajdującego się na płytce modułu mEDBG, który dokonuje translacji wszystkich danych z portu szeregowego mikrokontrolera i przesyła je przez USB na wirtualny port szeregowy utworzony w komputerze. Dzięki czemu z procesorem możemy bezpośrednio komunikować się z wykorzystaniem RS232! Odpada więc użycie translatora poziomów (MAX232) i konieczność posiadania w komputerze rzeczywistego interfejsu szeregowego. Jest to superwygodne rozwiązanie. Oczywiście jeśli chcemy, możemy podłączyć MAX232 i komunikować się z wykorzystaniem normalnego portu szeregowego, pytanie tylko po co?

Uwaga! Przed podłączeniem modułu zainstaluj Atmel Studio w wersji co najmniej 6.2. Zawiera ono wszystkie sterowniki do płytki, dzięki czemu moduł będzie od razu gotowy do pracy.

Pierwsze podłączenie

Po połączeniu modułu Xplained z komputerem, po chwili zobaczymy gotowe do pracy urządzenie. Aby się upewnić, że wszystko jest ok możemy kliknąć na menadżer urządzeń:

Widok Menagera

Pojawią nam się dwa urządzenia – pierwsze mEDBG to urządzenie za pomocą, którego Atmel Studio będzie komunikował się z modułem w celu programowania i debugowania. Drugie – port komunikacyjny – to wirtualny interfejs szeregowy, poprzez który będziemy mogli wymieniać dane z pisanym programem z wykorzystaniem RS232.

Jeśli włączymy Atmel Studio to pokaże nam się zakładka sygnalizująca gotowość modułu do pracy:

Widok w Atmel Studio

Od tej chwili jesteśmy gotowi do pracy z modułem i możemy zacząć pisać swój pierwszy kod. Jak widzimy start z mikrokontrolerami jeszcze nigdy nie był tak prosty.

Pierwszy program

Nasz moduł jest widoczny w systemie, jak napisać na niego program? Przede wszystkim tworząc nowy projekt musimy wybrać mikrokontroler jaki znajduje się w naszym module – ATMega168P lub ATMega328P. Po utworzeniu projektu musimy pamiętać o jednej rzeczy – mikrokontroler zawarty w module Xplained zawsze taktowany jest z generatora kwarcowego o częstotliwości 16 MHz – musimy więc w opcjach projektu zdefiniować symbol F_CPU i nadać mu wartość 16000000UL. I to wszystko – możemy zacząć pisać program.

A co jeśli 16 MHz nam nie odpowiada? Częstotliwość taktowania MCU możemy zmienić, ale wyłącznie korzystając z wbudowanego preskalera zegara – umożliwia on podział częstotliwości, dzięki czemu mikrokontroler może być taktowany wolniej. Innych możliwości oferowanych wprost (np. przestawienia na wewnętrzny generator RC) nie ma – ale nie za bardzo to przeszkadza.

Programowanie

Aby zaprogramować naszą płytkę we właściwościach projektu klikamy na zakładkę Tool i wybieramy typ programatora oraz interfejs programowania układu:

Widok programatora

Pamiętaj, że jeśli w oknie wyboru programatora (Selected debugger/programmer) nie widzisz urządzenia mEDBG to najprawdopodobniej jako typ mikrokontrolera w opcjach projektu nie wybrałeś mikrokontrolera znajdującego się na posiadanej płytce Xplained (a więc ATMegi 168P lub ATMegi 328P).

Jako interfejs programowania/debugowania warto wybrać debugWire – umożliwi to sprzętowe debugowanie pisanej aplikacji. I to już naprawdę wszystko – od tego momentu możemy pisać i debuggować nasz kod tak jak to zostało pokazane w kursie Atmel Studio.

Pliki do pobrania

Dla zainteresowanych poniżej linki do plików do pobrania:

• Xplained Mini - Opis modułu (kopia z dnia 18 września 2014 r.)
• Xplained Mini - Schemat modułu (kopia z dnia 18 września 2014 r.)

Kurs XMega (09): Generator kwarcowy

Autor: Dominik Leon Bieczyński
Redakcja: Dondu

Artykuł jest fragmentem cyklu: Kurs mikrokontrolerów XMega by Leon-Instruments

W 8 części kursu zapoznaliśmy się z wbudowanymi generatorami RC dostępnymi w mikrokontrolerach XMEGA, a w tej części zostanie przedstawiony generator kwarcowy. Generatory tego typu cechują się większą dokładnością i mają zastosowanie wszędzie tam, gdzie potrzebne jest precyzyjne odmierzanie czasu.

W tym odcinku, korzystając z modułu prototypowego X3-DIL64 z Leon Instruments, zobaczymy, jak działa generator kwarcowy. Podczas ćwiczeń zbudujemy układ, którego schemat przedstawiono poniżej – schemat ten będzie przydatny dla wszystkich części kursu od 7 do 10.

Do pobrania: XMega-sygnaly-zegarowe.zip (kopia)

Generator kwarcowy

Sercem generatora tego typu jest rezonator kwarcowy, w skrócie zwany kwarcem. Podłączamy go do pinów R0 i R1 portu R. Są to piny ogólnego przeznaczenia i jeśli nie korzystamy z generatora kwarcowego, możemy je wykorzystać w innym celu. Oprócz kwarcu, musimy także podłączyć kondensatory o niewielkiej pojemności, widoczne na schemacie, w sposób znany z mikrokontrolerów ATmega i ATtiny.

Większość producentów płytek testowych narzuca częstotliwość kwarcu, lutując go do płytki na stałe. Odlutowanie kwarcu, w szczególności SMD, może spowodować jego uszkodzenie lub oderwanie miedzianych ścieżek od laminatu.

Moduł prototypowy X3-DIL64 z Leon Instruments wyposażono w podstawkę pod kwarc, dzięki czemu użytkownik może szybko i bez lutowania podłączyć taki kwarc, jaki uzna za najlepszy do swoich potrzeb - w konkurencyjnych płytkach kwarcu nie da się wymienić bez użycia lutownicy i odsysacza!

Wymienny kwarc na płytce X3-DIL64

W mikrokontrolerach XMEGA możemy korzystać z kwarców zegarkowych 32 kHz oraz kwarców o częstotliwości od 0,4 MHz do 16 MHz. Chcąc uzyskać częstotliwość taktowania procesora większą od 16 MHz, musimy zastosować układ PLL, który zostanie omówiony później.

Konfiguracja generatora kwarcowego jest trochę bardziej skomplikowana niż generatory omawiane dotychczas, aczkolwiek nie jest to problem, z którym sobie nie poradzimy. Za generator kwarcowy odpowiedzialny jest rejestr OSC.XOSCCTRL. Zobaczmy fragment dokumentacji:

Rejestr XOSCCTRL

Musimy zatem zastanowić się nad czterema parametrami. Pierwszy z nich, FRQRANGE, określa przedział wewnątrz którego musi znajdywać się częstotliwość kwarcu. X32KLPM służy do uruchamiania trybu oszczędzania energii dla kwarcu 32 kHz. XOSCPWR zwiększa prąd w obwodzie rezonatora, co w większości przypadków nie jest potrzebne. XOSCSEL wyznacza m. in. czas potrzebny do stabilizacji generatora.

W naszym przykładzie wykorzystamy kwarc o częstotliwości 16 MHz, a jego typowy czas startu wynosi 16 tys. cykli zegarowych. W takiej sytuacji wystarczy wpisać poniższą linijkę kodu, by skonfigurować generator.

    OSC.XOSCCTRL    =   OSC_FRQRANGE_12TO16_gc|        // wybór kwarcu od 12 do 16 MHZ
                        OSC_XOSCSEL_XTAL_16KCLK_gc;    // czas na uruchomienie generatora

Następnie, uruchamiamy generator kwarcowy.

    OSC.CTRL        =    OSC_XOSCEN_bm;                // uruchomienie generatora kwarcowego

Powinniśmy teraz poczekać, aż generator się ustabilizuje. Jednak nie możemy czekać w pustej pętli na ustawienie się odpowiedniego bitu w rejestrze statusowym, bo jeśli generator się nie uruchomi, to procesor będzie czekał w nieskończoność.

Dlatego musimy wprowadzić pętlę, która odliczy przykładowo 255 cykli i sprawdzi status 255 razy – jeśli w tym czasie generator się nie ustabilizuje, program stwierdzi brak kwarcu i będzie mógł powiadomić użytkownika o błędzie.

    // czekanie na ustabilizowanie się generatora
    for(uint8_t i=0; i<255; i++) {                        
        if(OSC.STATUS & OSC_XOSCRDY_bm) {              // sprawdzanie statusu
            CPU_CCP       =    CCP_IOREG_gc;           // odblokowanie zmiany źródła sygnału zegarowego
            CLK.CTRL      =    CLK_SCLKSEL_XOSC_gc;    // wybór źródła sygnału zegarowego na XTAL 16MHz
            LcdClear();                                // czyszczenie wyświetlacza
            Lcd("XTAL");                               // komunikat o uruchomieniu generatora
            
            // układ nadzorujący kwarc
            CPU_CCP       =    CCP_IOREG_gc;           // odblokowanie modyfikacji ważnych rejestrów 
            OSC.XOSCFAIL  =    OSC_XOSCFDEN_bm;        // włączenie układu detekcji błędu
            return;                                    // wyjście z funkcji gdy generator się uruchomi
        }
        _delay_us(10);
    }     
    
    // komunikat w przypadku braku uruchomienia generatora kwarcowego
    LcdClear();
    Lcd("Brak XTAL");

Mikrokontrolery XMEGA wyposażono w szereg rozwiązań zwiększających bezpieczeństwo i stabilność pracy. Jednym z nich jest układ nadzorujący pracę generatora kwarcowego. Jeśli z jakiegokolwiek powodu zostanie wykryta nieprawidłowość w pracy generatora, układ zgłosi przerwanie niemaskowalne OSC_OSCF_vect i samoczynnie przełączy źródło sygnału na wbudowany generator RC 2 MHz.

Tradycyjne procesory ATtiny i ATmega w takiej sytuacji się zawieszały i nie były w stanie nic zrobić, a w skrajnych przypadkach bez sygnału zegarowego nie mogły nawet nawiązać połączenia z programatorem.


Zanim zostanie uruchomiony układ detekcji błędu generatora kwarcowego, musimy wpisać wartość CCP_IOREG_gc do rejestru CPU_CCP, aby zezwolić na modyfikację rejestrów kluczowych dla funkcjonowania procesora. Następnie, do rejestru XOSCFAIL wpisujemy wartość OSC_XOSCFDEN_bm i układ detekcji zostanie uruchomiony. Trzeba zaznaczyć, że tego układu nie można wyłączyć bez zresetowania procesora.

    // układ nadzorujący kwarc
    CPU_CCP         =    CCP_IOREG_gc;                 // odblokowanie modyfikacji ważnych rejestrów 
    OSC.XOSCFAIL    =    OSC_XOSCFDEN_bm;              // włączenie układu detekcji błędu

W razie stwierdzenia usterki generatora, zostanie wygenerowane przerwanie OSC_OSCF_vect, a generator RC 2 MHz włączy się automatycznie.

ISR(OSC_OSCF_vect) {
    OSC.XOSCFAIL   |=    OSC_XOSCFDIF_bm;              // kasowanie flagi przerwania
    LcdClear();
    Lcd("Awaria!");    
}

Powyższy program możesz testować np. na płytce X3-DIL64.

Dominik Leon Bieczyński
leon-instruments.pl

Kurs XMega (08): Generator RC

Autor: Dominik Leon Bieczyński
Redakcja: Dondu

Artykuł jest fragmentem cyklu: Kurs mikrokontrolerów XMega by Leon-Instruments

W poprzedniej części kursu przedstawiłem ogólnie, jakie mikrokontrolery XMEGA mają dostępne do wybory generatory sygnału zegarowego i jakie mamy dostępne możliwości.

W tym odcinku, korzystając z modułu prototypowego X3-DIL64 z Leon Instruments, zobaczymy, jak uruchamia się wbudowane generatory RC. Poniższy schemat będziemy wykorzystywać do wszystkich ćwiczeń z sygnałami zegarowymi, opisanymi w odcinkach od 7 do 10.

Do pobrania: XMega-sygnaly-zegarowe.zip (kopia)

Schemat układu.

Generatory RC 32MHz i 2MHz

Po wciśnięciu przycisku FLIP, podłączonego na płytce X3-DIL64 z Leon Instruments do pinu E5, zostanie wywołana funkcja Osc32MHz(), uruchamiająca wbudowany generator 32 MHz.

Bardzo miło, że projektanci mikrokontrolerów XMEGA udostępnili nam wbudowany generator, który bez podłączania żadnych dodatkowych elementów umożliwi osiągnięcie maksymalnej mocy obliczeniowej. Poza tym, generator RC nie wymaga żadnej konfiguracji, więc możemy od razu przystąpić do jego uruchomienia.

Aby to zrobić, musimy wpisać odpowiednią wartość do rejestru kontrolnego oscylatora, a mianowicie do OSC.CTRL. Zobaczmy fragment dokumentacji:

Opis rejestru OSC.CTRL

…zatem aby uruchomić generator 32 MHz, powinniśmy do rejestru OSC.CTRL wpisać wartość OSC_RC32MEN_bm.

Zwróćmy uwagę, że dokumentacja wyraźnie ostrzega nas, że musimy poczekać aż oscylator się ustabilizuje, zanim wykorzystamy go jako źródło sygnału zegarowego.

W tym celu musimy w pętli sprawdzać rejestr OSC.STATUS i czekać tak długo, aż bit OSC_RC32MRDY_bm przyjmie wartość 1.

void Osc32MHz(void) {
    OSC.CTRL     =    OSC_RC32MEN_bm;       // włączenie oscylatora 32MHz
    while(!(OSC.STATUS & OSC_RC32MRDY_bm)); // czekanie na ustabilizowanie się generatora
    CPU_CCP      =    CCP_IOREG_gc;         // odblokowanie zmiany źródła sygnału
    CLK.CTRL     =    CLK_SCLKSEL_RC32M_gc; // zmiana źródła sygnału na RC 32MHz
    LcdClear();                             // czyszczenie wyświetlacza
    Lcd("Wewn RC 32MHz");                   // komunikat o uruchomieniu generatora
}

Po wykonaniu tej funkcji, na wyświetlaczu powinien pojawić się komunikat o taktowaniu procesora zegarem 32MHz, a dioda podłączona do pinu E0 powinna migać wyraźnie szybciej.
Uruchomienie wbudowanych generatorów 2 MHz oraz 32 kHz wykonuje się bardzo podobnie – wystarczy zmienić tylko RC32M na RC2M lub RC32K.

void Osc2MHz(void) {
    OSC.CTRL     =    OSC_RC2MEN_bm;        // włączenie oscylatora 2MHz
    while(!(OSC.STATUS & OSC_RC2MRDY_bm));  // czekanie na ustabilizowanie się generatora
    CPU_CCP      =    CCP_IOREG_gc;         // odblokowanie zmiany źródła sygnału
    CLK.CTRL     =    CLK_SCLKSEL_RC2M_gc;  // zmiana źródła sygnału na RC 2MHz
    LcdClear();                             // czyszczenie wyświetlacza
    Lcd("RC 2MHz");                         // komunikat o uruchomieniu generatora
}

Powyższy program możesz testować np. na płytce X3-DIL64.

Dominik Leon Bieczyński
leon-instruments.pl

Kurs XMega (07): Sygnały zegarowe

Autor: Dominik Leon Bieczyński
Redakcja: Dondu

Artykuł jest fragmentem cyklu: Kurs mikrokontrolerów XMega by Leon-Instruments

W mikrokontrolerach ATmega i ATtiny układ dystrybucji sygnałów zegarowych był tak prosty, że wręcz aż prymitywny. W szczególności w procesorach starej generacji, takich jak ATmega8, mogliśmy wybrać źródło sygnału zegarowego przy pomocy fusebitów i podczas pracy procesora w żaden sposób nie można było go zmienić.

Tylko część mikrokontrolerów ATtiny i ATmega ma możliwość prostej zmiany częstotliwości taktowania mikrokontrolera, o czym przeczytasz w artykule: Ustawianie i zmiana częstotliwości taktowania mikrokontrolera w trakcie jego działania

Ponadto, błędne ustawienie fusebitów mogło prowadzić do zablokowania procesora. Najwyższy czas, by porzucić poczciwą ósemkę i przejść na mikrokontrolery nowej generacji!

W XMEGA układ zegarowy jest zdecydowanie bardziej rozbudowany. Mamy do dyspozycji różne źródła sygnału zegarowego, takie jak wbudowany generator szybki 32 MHz, energooszczędny 32 kHz oraz normalny 2 MHz, który uruchamia się zawsze po włączeniu zasilania. Możemy te częstotliwości podzielić preskalerem lub pomnożyć wbudowanym układem PLL. Oprócz tego, możemy oczywiście podłączyć różne kwarce, a w razie uszkodzenia kwarcu, procesor samoczynnie przełączy się na wbudowany generator. Mało tego – podczas pracy możemy zmieniać nie tylko częstotliwość zegara, ale również źródło sygnału. Różne peryferia mogą być taktowane różnymi zegarami, a niektóre z nich mogą pracować nawet z częstotliwością 128 MHz!

Do pobrania: XMega-sygnaly-zegarowe.zip (kopia)

Uproszczony schemat układu dystrybucji sygnałów zegarowych przedstawiono na rysunku poniżej. Po wybraniu jednego z pięciu dostępnych źródeł, mamy do dyspozycji aż trzy preskalery, umożliwiające taktowanie poszczególnych peryferiów mikrokontrolera różnymi zegarami. CLKCPU to zegar dla rdzenia procesora i może mieć maksymalnie 32MHz. CLKPER taktuje większość peryferiów. CLKPER2 i CLKPER4 służą do taktowania peryferiów zdolnych do pracy z zegarem szybszym od CLKCPU. Oprócz tego, mamy jeszcze osobne zegary dla RTC i USB, jeśli mikrokontroler jest wyposażony w te peryferia.

Preskalery

Sposób wyboru źródła sygnału zegarowego sprowadza się do trzech punktów:

• Konfiguracja i uruchomienie generatora
• Oczekiwanie na stabilizację generatora
• Przełączenie źródła

W tej części kursu napiszemy kilka funkcji, umożliwiających przełączenie źródła sygnału taktującego oraz obserwację efektów tej zmiany przy pomocy migającej diody i wyświetlacza LCD ze sterownikiem HD44780. Wykorzystamy wewnętrzny generator RC 2 MHz, 32 MHz, a także zewnętrzny generator kwarcowy i układ PLL.

Schemat

Po zmontowaniu na płytce stykowej uzyskamy mniej więcej taki układ:

Zdjęcie układu

Zacznijmy od przeanalizowania funkcji main().

#define F_CPU 62000000UL
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include "hd44780.h"

int main(void) {
    
    // zmienna
    uint8_t pll         =    4;
    
    // diody
    PORTE.DIR           =    PIN0_bm;             // dioda LED
                    
    // przyciski
    PORTA.DIRCLR        =    PIN0_bm;             // przycisk - RC 2MHz
    PORTA.PIN0CTRL      =    PORT_OPC_PULLUP_gc;  // podciągnięcie do zasilania
    PORTE.DIRCLR        =    PIN5_bm;             // przycisk FLIP - RC 32MHz
    PORTE.PIN5CTRL      =    PORT_OPC_PULLUP_gc;  // podciągnięcie do zasilania
    PORTE.DIRCLR        =    PIN6_bm;             // przycisk - XTAL
    PORTE.PIN6CTRL      =    PORT_OPC_PULLUP_gc;  // podciągnięcie do zasilania
    PORTF.DIRCLR        =    PIN4_bm;             // przycisk - PLL
    PORTF.PIN4CTRL      =    PORT_OPC_PULLUP_gc;  // podciągnięcie do zasilania
    
    // wyświetlacz LCD
    LcdInit();
    
    // komunikat o źródłe sygnału zegarowego
    LcdClear();
    Lcd("RC 2MHz");
    
    // włączenie przerwań
    sei();
    
    while(1) {
        PORTE.OUTTGL    =    PIN0_bm;
        _delay_ms(50);
        
        if(!(PORTA.IN & PIN0_bm)) Osc2MHz();
        if(!(PORTE.IN & PIN5_bm)) Osc32MHz();
        if(!(PORTE.IN & PIN6_bm)) OscXtal();
        if(!(PORTF.IN & PIN4_bm)) {    
            pll++;                   // zwiększ zmienną pll
            if(pll > 31) pll = 1;    // jeśli pll większe od 31 to ustaw na 1
            OscPLL(pll);             // funkcja konfigurująca PLL
        }
    }
}

Zwróćmy uwagę na funkcję opóźniającą _delay_ms(50); Co w niej jest nie tak? Funkcja powoduje, że procesor kręci się w pustej pętli nic nie robiąc, aż upłynie żądany czas. Jednak funkcja _delay_ms() oblicza ilość potrzebnych cykli na podstawie definicji #define F_CPU 62000000UL.

W przypadku kiedy częstotliwość taktowania się zmienia, to pamiętajmy, że standardowe funkcje opóźniające nie uwzględniają aktualnej częstotliwości, w związku z czym odmierzony czas nie będzie prawidłowy. Zaobserwujemy ten problem w naszym programie testowym – dioda podłączona do E0 będzie mrugać z różną częstotliwością, mimo że w pętli głównej jest _delay_ms(50) ze stałym argumentem równym 50.

Ściągnij poniższe pliki źródłowe – będziemy używać biblioteki do obsługi wyświetlacza autorstwa Radosława Kwietnia, którą opisałem w 5 części kursu (wyświetlacz LCD w XMEGA). W kolejnych odcinkach przedstawię, jak działają poszczególne generatory i jak skonfigurować ich rejestry kontrolne.

Dominik Leon Bieczyński
leon-instruments.pl

Kurs XMega (06): Przerwania

Autor: Dominik Leon Bieczyński
Redakcja: Dondu

Artykuł jest fragmentem cyklu: Kurs mikrokontrolerów XMega by Leon-Instruments

W procesorach ATmega kontroler przerwań był tak prosty, że prostszy już być nie może. Można go było włączyć lub wyłączyć. W XMEGA kontroler przerwań został znacznie rozbudowany i traktowany jest jako pełnoprawny układ peryferyjny o nazwie PMIC, czyli Programmable Multilevel Interrupt Controller.

Pliki do pobrania: XMega-przerwania-int.zip (kopia)

Największym plusem PMIC jest to, że mamy do dyspozycji trzy priorytety przerwań – niski, średni i wysoki. Oznacza to, że procedura obsługi przerwania o niskim priorytecie może być przerwana przez przerwanie o priorytecie średnim lub wysokim. Przerwanie o priorytecie wysokim nie może być przerwane wcale (wyjątek: wykrycie nieprawidłowego sygnału taktującego). Dzięki temu możemy ustalić jakie zadania są dla nas najważniejsze, by procesor mógł na nie reagować jak najszybciej, a mniej ważne zadania zostawił do dokończenia na później. Jest też dostępny scheduler round-robin, by mieć kontrolę nad kolejnością wykonywanych przerwań o tym samym priorytecie, w razie natłoku zgłoszeń. Jest to konieczne, gdyż w procesorach XMEGA mamy bardzo wiele różnych przerwań do dyspozycji – w ATxmega128A3U, zamontowanym na płytce X3-DIL64 z Leon Instruments, jest ponad 100 wektorów przerwań!

Przerwania dzielą się na maskowalne i niemaskowane. Niemaskowalne jest zaledwie jedno – wykrycie nieprawidłowego działania generatora sygnału zegarowego. Przerwania maskowalne mogą generować wszystkie układy peryferyjne i podobnie jak w ATmega, musimy je odblokować, aby móc je wykorzystać. Kolejnym podobieństwem jest konieczność użycia makra sei(), aby uruchomić system przerwań.

W tej części kursu zrobimy prosty program, demonstrujący działanie przerwań o różnych priorytetach. Poznamy również jak skonfigurować przerwania INT od portów, omawianych w 4 części kursu. W pętli głównej procesor będzie zajmował się wyłącznie mruganiem diodą, podłączoną do pinu B0. Przerwania będą wywoływane przyciskami na pinach E5 i E6, a procedury tych przerwań będą powodowały mruganie diodami, odpowiednio, podłączonymi do pinów C1 i C0.

Oprócz mrugania diodami, wykorzystamy również popularny wyświetlacz tekstowy 16x2 ze sterownikiem HD44780. Nie będę tu omawiał jego obsługi i wykorzystamy gotową bibliotekę, którą omawialiśmy w 5 odcinku kursu. Biblioteka jest autorstwa Radosława Kwietna (radzio.dxp.pl) i przystosowałem ją do wykorzystania w mikrokontrolerach XMEGA.

Schemat

A tak wyglądać powinien zmontowany układ.

Zdjęcie układu

Program zaczynamy, jak zwykle, od konfiguracji portów. W tym fragmencie kodu jedyna nowość to PORT_ISC_FALLING_gc wpisane do rejestrów PINxCTRL. W ten sposób decydujemy, jakie konkretnie zdarzenie ma wywoływać przerwanie. FALLING oznacza zbocze opadające, a możliwe są jeszcze opcje: RISING (zbocze rosnące), BOTHEDGES (zbocze rosnące lub opadające) oraz LEVEL, czyli stan logicznego zera.

    PORTE.DIRSET    =    PIN0_bm;            // pin E0 jako wyjście
    PORTC.DIRSET    =    PIN0_bm | PIN1_bm;  // pin C0 i C1 jako wyjście
    PORTE.DIRCLR    =    PIN5_bm | PIN6_bm;  // pin E5 i E6 jako wejście
    PORTE.PIN5CTRL  =    PORT_OPC_PULLUP_gc| // pull-up na E5
                         PORT_ISC_FALLING_gc;// przerwanie wywołuje zbocze opadające
    PORTE.PIN6CTRL  =    PORT_OPC_PULLUP_gc| // pull-up na E6
                         PORT_ISC_FALLING_gc;// przerwanie wywołuje zbocze opadające

Każdy port w XMEGA może generować przerwanie INT0 i INT1, jednak to my sami możemy wybrać, który pin jakie przerwanie ma wywoływać. Mało tego, nawet kilka pinów może wywoływać tę samą procedurę przerwania! Nic nie stoi na przeszkodzie, by jeden pin wywoływał zarówno INT0 i INT1, choć takie rozwiązanie raczej nie ma sensu praktycznego.

Na przykładzie poniższego kodu widać, jak przypisać piny do poszczególnych przerwań. Następnie, w rejestrze INTCTRL musimy ustalić priorytety przerwań INT0 i INT1 – dostępne opcje to LO, MED, HI albo można przerwanie wyłączyć wpisując PORT_INTxLVL_OFF_gc.

    PORTE.INT0MASK  =    PIN5_bm;            // pin E5 ma generować przerwania INT0
    PORTE.INT1MASK  =    PIN6_bm;            // pin E6 ma generować przerwania INT1
    PORTE.INTCTRL   =    PORT_INT0LVL_HI_gc| // poziom HI dla przerwania INT0 portu E
                         PORT_INT1LVL_LO_gc; // poziom LO dla przerwanie INT1 portu E

Przejdźmy teraz do skonfigurowania kontrolera przerwać PMIC. Musimy w jego rejestrze CTRL odblokować przerwania o priorytecie HI oraz LO. Na koniec, należy wpisać instrukcję sei(), dobrze znaną z ATmega i ATtiny, aby procesor mógł obsługiwać przerwania INT0.

    PMIC.CTRL       =    PMIC_HILVLEN_bm|    // włączenie przerwań o priorytecie HI
                         PMIC_LOLVLEN_bm;    // włączenie przerwań o priorytecie LO
    sei();

Pętla główna naszego programu jest trywialnie prosta.

    while(1) {
        LcdClear();                          // czyszczenie wyświetlacza
        Lcd("main");                         // wyświetlenie napisu
        PORTB.OUTTGL  =    PIN0_bm;          // mruganie diodą na B0
        _delay_ms(500);                      // czekanie 500ms
    }

Zobaczmy, jak należy napisać procedurę obsługi przerwania.

    ISR(PORTE_INT0_vect) {                   // procedura przerwania INT0 portu E
        for(uint8_t i=0; i<20; i++) {        // 10-krotne mrugnięcie diodą na C0
            LcdClear();                      // czyszczenie wyświetlacza
            Lcd("INT0");                     // wyświetlenie napisu
            Lcd2;                            // przejście do drugiej linii
            Lcd("priorytet HI");
            PORTC.OUTTGL    =    PIN0_bm;    // mruganie diodą na C0
            _delay_ms(100);
        }
    }

Każdy port może generować przerwanie INT0 i INT1 – stąd nazwa przerwania PORTE_INT0_vect. Procedura zawiera pętlę, dzięki której dioda na pinie C0 mrugnie dziesięciokrotnie. Procedura przerwania INT1 jest bardzo podobna.

    ISR(PORTE_INT1_vect) {                   // procedura przerwania INT1 portu E
        for(uint8_t i=0; i<20; i++) {        // 10-krotne mrugnięcie diodą na C1
            LcdClear();                      // czyszczenie wyświetlacza
            Lcd("INT1");                     // wyświetlenie napisu
            Lcd2;                            // przejście do drugiej linii
            Lcd("priorytet LO");
            PORTC.OUTTGL    =    PIN1_bm;    // mruganie diodą na C1
            _delay_ms(100);
        }
    }

Zobaczmy więc, jak to działa w praktyce, wykorzystując płytkę rozwojową X3-DIL64 z Leon Instruments. Po wgraniu programu mruga dioda podłączona do B0. Naciśnięcie przycisków wywołuje odpowiadające im procedury przerwań. Co się stanie, jeśli wciśniemy przycisk E6, wywołujący przerwanie o priorytecie niskim, a chwilę potem E5, który wywoła przerwanie o wyższym priorytecie? Dioda C1 przestanie mrugać, a dioda na C0 zacznie. Kiedy C0 skończy migać, procesor wróci do mrugania diodą C1, a potem wróci do pętli głównej i mrugania diodą na B0.

Należy wyraźnie zaznaczyć, że procedury przerwań powinny być wykonywane jak najszybciej i nie powinno być w nich żadnych funkcji opóźniających.

W niniejszym artykule została zastosowana funkcja _delay_ms(), aby móc zobaczyć działanie przerwań i ich priorytetów.

Pamiętaj, że w normalnym programie stosowanie opóźnień w przerwaniach jest wysoce niewskazane.

#define  F_CPU    2000000UL
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include "hd44780.h"

int main(void) {
    
    // konfiguracja portów
    PORTE.DIRSET   = PIN0_bm;            // pin E0 jako wyjście
    PORTC.DIRSET   = PIN0_bm | PIN1_bm;  // pin C0 i C1 jako wyjście
    PORTE.DIRCLR   = PIN5_bm | PIN6_bm;  // pin E5 jako wejście
    PORTE.PIN5CTRL = PORT_OPC_PULLUP_gc| // pull-up na E5
                      PORT_ISC_FALLING_gc;// przerwanie wywołuje zbocze opadające
    PORTE.PIN6CTRL = PORT_OPC_PULLUP_gc| // pull-up na E6
                     PORT_ISC_FALLING_gc;// przerwanie wywołuje zbocze opadające
    
    // konfiguracja przerwań portów
    PORTE.INT0MASK = PIN5_bm;            // pin E5 ma generować przerwania INT0
    PORTE.INT1MASK = PIN6_bm;            // pin E6 ma generować przerwania INT1
    PORTE.INTCTRL  = PORT_INT0LVL_HI_gc| // poziom HI dla przerwania INT0 portu E
                     PORT_INT1LVL_LO_gc; // poziom LO dla przerwanie INT1 portu E
    
    // włączenie przerwań
    PMIC.CTRL      = PMIC_HILVLEN_bm |   // włączenie przerwań o priorytecie HI
                     PMIC_LOLVLEN_bm;    // włączenie przerwań o priorytecie LO
    sei();                               // globalne włączenie przerwań
    LcdInit();                           // inicjalizacja wyświetlacza
    
    // pętla główna
    while(1) {
        LcdClear();                      // czyszczenie wyświetlacza
        Lcd("main");                     // wyświetlenie napisu
        PORTE.OUTTGL    =    PIN0_bm;    // mruganie diodą na B0
        _delay_ms(500);                  // czekanie 500ms
    }
}

ISR(PORTE_INT0_vect) {                    // procedura przerwania INT0 portu E
    for(uint8_t i=0; i<20; i++) {         // 10-krotne mrugnięcie diodą na C0
        LcdClear();                       // czyszczenie wyświetlacza
        Lcd("INT0");                      // wyświetlenie napisu
        Lcd2;                             // przejście do drugiej linii
        Lcd("priorytet HI");
        PORTC.OUTTGL    =    PIN0_bm;     // mruganie diodą na C0
        _delay_ms(100);
    }
}

ISR(PORTE_INT1_vect) {                    // procedura przerwania INT1 portu E
    for(uint8_t i=0; i<20; i++) {         // 10-krotne mrugnięcie diodą na C1
        LcdClear();                       // czyszczenie wyświetlacza
        Lcd("INT1");                      // wyświetlenie napisu
        Lcd2;                             // przejście do drugiej linii
        Lcd("priorytet LO");
        PORTC.OUTTGL    =    PIN1_bm;     // mruganie diodą na C1
        _delay_ms(100);
    }
}

Dominik Leon Bieczyński
leon-instruments.pl