Generujemy żądanie certyfikatu dla organu wydającego

Pierwszym krokiem, który musimy zrobić, aby uzyskać (a później też zainstalować) certyfikat, to wygenerowanie klucza prywatnego, a następnie przy jego pomocy stworzyć plik żądania (CSR), który wyślemy do organu wydającego certyfikaty. Następnie parę w postaci naszego klucza prywatnego + otrzymany certyfikat zainstalujemy na serwerze www.

Najpierw generujemy klucz. Najlepiej robić to wszystko w katalogu /etc/apache2/ssl:
Wersja z hasłem (hasło będzie konieczne podczas startu/restartu apache’a)

openssl genrsa -des3 -out PVK.pem 2048

lub bez hasła:

openssl genrsa -out PVK.pem 2048

Następny krok to stworzenie pliku żądania CSR:

openssl req -new -key PVK.pem -out CSR.pem

Po tym poleceniu program zapyta nas o kilka informacji, które należy podać w celu dostarczenia niezbędnych informacji organowi wydającemu certyfikaty.

Ok, mamy teraz dwa pliki: PVK.pem – klucz prywatny oraz CSR.pem – plik żądania, który zaraz wyślemy do organu wydającego certyfikaty (CA).

Zanim wyślemy pliki, możemy sobie jeszcze je zweryfikować przy pomocy następujących poleceń:
Weryfikacja klucza prywatnego:

openssl rsa -noout -text -in PVK.pem

Weryfikacja pliku csr:

openssl req -noout -text -in CSR.pem

Wysyłamy pliki

Teraz należy wysłać do wybranego przez siebie CA (certificate Authority) – instytucji/firmy wydającej certyfikaty plik CSR.pem, w odpowiedzi powinniśmy dostać plik certyfikatu *.crt.

Instalujemy certyfikat w apache’u

W pierwszej kolejności musimy uruchomić ssl na serwerze…

a2enmod ssl

Jeśli nie mamy zainstalowanego open-ssl, należy to uczynić, korzystając np. z tej komendy:

sudo apt-get install apache2 libapache-mod-ssl

Dalej powiedzmy, że mamy już skonfigurowaną jakąś wirtualkę, np. example.com, zatem przechodzimy do katalogu /etc/apache2/sites-available

cd /etc/apache2/sites-available

I kopiujemy ją jako example.com-ssl

cp example.com example.com-ssl

Otwieramy plik example.com-ssl w swoim ulubionym edytorze tekstu i modyfikujemy port, na którym nasłuchuje server na 443 oraz dodajemy 4 linijki aktywujące ssl na tej wirtualce.

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/example_com.crt #certyfikat, który dostaliśmy od CA
SSLCertificateKeyFile /etc/ssl/certs/PVK.pem #klucz prywatny
SSLCertificateChainFile /etc/apache2/ssl/AddTrustExternalCARoot.crt #chain autoryzacyjny 2 pozycje, tutaj zależy co dostaniemy w odpowiedzi od CA
SSLCertificateChainFile /etc/apache2/ssl/COMODOHigh-AssuranceSecureServerCA.crt


Cały wpis virtual hosta może wyglądać m/w tak:

<VirtualHost *:443>
ServerAdmin webmaster@example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /home/www/example.com/public_html

CustomLog /home/www/example.com/log/access-ssl.log combined
ErrorLog /home/www/example.com/log/error-ssl.log
</VirtualHost>


I to właściwie tyle. Jeśli chcemy, możemy jeszcze ustawić przekierowania tak, aby wymusić zawsze oglądanie strony poprzez https. W tym celu w virtualce (tym razem tej „normalnej” na porcie 80), dodajemy krótką regułką mod_rewrite:

RewriteEngine on
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]

Cały VirtualHost może wyglądać m/w tak:

<VirtualHost *:80>
ServerAdmin webmaster@example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /home/www/example.com/public_html

RewriteEngine on
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]
</VirtualHost>


Teraz pozostaje nam tylko włączyć virtualkę…

a2ensite example.com-ssl

Oraz zrestartować apache’a:

/etc/init.d/apache2 restart

Jeśli w pierwszym punkcie wybraliśmy klucz prywatny chroniony hasłem, wówczas zostaniemy o to hasło poproszeni, a jeśli nie, apache powinien uruchomić się od razu.

No i mamy działający ssl Teraz po wpisaniu w przeglądarkę adresu http://example.com zostaniemy automatycznie przeniesieni na https://example.com, która będzie zabezpieczona nowo zainstalowanym certyfikatem.

Na początek odrobina teorii…

Zacznijmy od odrobiny teorii. Czym jest drabinka R-2R? Drabinka R-2R, jak sama nazwa wskazuje, to takie połączenie wielu rezystorów tej samej wartości, aby tworzyły one „drabinkę”, w której każdy kolejny szczebel ma wartość 2xR w stosunku do każdego kolejnego pionowego elementu. Poniżej widzimy, jak taka drabinka wygląda teoretycznie.

Bity od A0 do An są sterowane z wyjść bramek logicznych (np. wyjścia mikrokontrolera lub rejestru przesuwnego). Czyli mogą na nich występować dwa stany – niski i wysoki, który będzie odpowiednio na potencjale GND lub na potencjale napięcia zasilania danego układu – Vcc. (Oczywiście stan wysoki może być na innym poziomie, jednak w większości przypadków, gdy drabinka będzie podłączona bezpośrednio do wyjść np. mikrokontrolera, to właśnie w stanie wysokim będzie się pojawiało na wyjściach napięcie zasilania).
Jak już pewnie zauważyłeś/łaś, w dużym uproszczeniu mamy tu do czynienia z rezystorowym dzielnikiem napięcia. Spróbujmy sobie zatem obliczyć, jakie napięcie wyjściowe będziemy mieli na wyjściu takiego DAC’a w przypadku, gdy nasza drabinka będzie miała 8 strzebli (8bitów), a poziom wysoki każdego z nich będzie równy 5V.

Najpierw ogólnie:

Vout = Vref x VAL / 2^N

Gdzie:
N – liczba bitów (w naszym przykładzie będzie to

VAL – wartość podana na wejścia A0…An (dla N = 8, będzie to wartość z przedziału 00000000 do 11111111)
Vref – Napięcie referencyjne, czyli to, które reprezentuje stan wysoki układu. W naszym przykładzie będzie to 5V (dla typowej bramki CMOS będzie to 3.3V).

Weźmy teraz sobie konkretną wartość, np. 128, czyli binarnie będzie to 10000000 (2^8). Podstawiając do powyższego wzoru:

Vout = 5V x 128 / 2^8
Vout = 2.5V

To teraz policzmy sobie, jaka będzie rozdzielczość takiej drabinki…

Vout = 5V x 1 / 2^8
Vout ~= 0.02V

Czyli pojedynczy krok będzie zwiększał napięcie dokładnie o ok. 0.02V, co daje 255 kroków, aby osiągnąć napięcie 5V, czyli wszystko się zgadza! (Największa możliwa do zapisania wartość na 8bitach to właśnie 255, czyli mamy 255 bitowych kombinacji, czyli 255 kroków w naszym przetworniku).

Przejdźmy do praktyki…

Spróbuję teraz zademonstrować, jak w praktyce możemy wykorzystać taką drabinkę. W tym celu zbudujmy sobie prosty 16botowy DAC oparty na drabince R-2R.

Zbudujmy sobie układ jak z poniższego schematu…

U mnie to wyglądało m/w tak:

O tym, jak działa rejestr 74HC595, pisałem już w tym miejscu, więc nie będę przytaczał tego samego tekstu tutaj. Jedyna różnica między naszym układem a tym przedstawionym w linku powyżej to drabinka podłączona do wyjść Q0…Q7 układów U1 oraz U2, a także połączenie ich kaskadowo (z ang. daisy chaining), dzięki czemu możemy „wlać” w taką kaskadę wielokrotność liczby bitów każdej z nich. W tym przypadku dokładnie 16 bitów. Działa to w ten sposób, że gdy pierwszy z układów przepełni się, wówczas zaczyna „przelewać” kolejne bity do następnego układu.

Ok! Mamy już przetwornik, podłączmy go zatem do jakiegoś mikrokontrolera i spróbujmy wysłać na niego jakąś wartość. Żeby było prosto i przyjemnie, użyjmy do tego celu Arduino… które podłączymy jak na rysunku powyżej (wykorzystamy piny DIGITAL8, DIGITAL12, DIGITAL~11)

Jak już pewnie zauważyłeś/łaś, jest to takie same podłączenie jak w przypadku pozytywki z linku powyżej. Ba! Program sterujący będzie też bardzo podobny, z tą tylko różnicą, że będziemy wysyłać 16 bitów, a nie 8. Będzie to wyglądało m/w tak:

//Pin connected to ST_CP of 74HC595
int latchPin = 8;
//Pin connected to SH_CP of 74HC595
int clockPin = 12;
//Pin connected to DS of 74HC595
int dataPin = 11;
//Pin connected to UP button
int btnA = 2;
//Pin connected to DOWN button
int btnB = 3;

//int in arduino are 16bit length
int dataToSend = 0;

void setData(int data)
{
  byte dataA = 0;
  byte dataB = 0;
  
  //split 16bit var into two 8bit
  dataA = data & 0xff; 
  dataB = data >> 8;
  
  //ground latchPin and hold low for as long as you are transmitting
  digitalWrite(latchPin, LOW);
  //move ‘em out
  shiftOut(dataPin, clockPin, MSBFIRST, dataA);
  shiftOut(dataPin, clockPin, MSBFIRST, dataB);
  //return the latch pin high to signal chip that it
  //no longer needs to listen for information
  digitalWrite(latchPin, HIGH);
}

void setup() {
  pinMode(latchPin, OUTPUT);
  pinMode(clockPin, OUTPUT);
  pinMode(dataPin, OUTPUT);
  pinMode(btnA, INPUT);
  pinMode(btnB, INPUT);
}

void loop() {

  if(digitalRead(btnA)==HIGH && dataToSend<32768)
  {
    dataToSend++;
    setData(dataToSend);
  }
  else if(digitalRead(btnB)==HIGH && dataToSend>0)
  {
    dataToSend--;
    setData(dataToSend);
  }
    
}

No i mamy działający 16bitowy DAC za parę groszy

Problemy, ograniczenia, wady…

Tak, tak… To wszystko było zbyt piękne i gdyby nie było jakiegoś haczyka, to pewnie producenci specjalizowanych układów DAC by zbankrutowali… I rzeczywiście haczykiem jest precyzja, a dokładniej precyzja, jaką muszą się charakteryzować rezystory, z których składamy taką drabinkę, aby napięcia wyjściowe na niej wygenerowane choć trochę odpowiadały tym, które sobie wyliczyliśmy i których oczekujemy na wyjściu. Przykładowo dla 8bitowej drabinki rezystory muszą mieć dokładność większą niż 0.4%, co już stanowi spory problem, zarówno finansowy, jak i w realizacji praktycznej układu. Można oczywiście taką drabinkę próbować kompensować programowo, jednak jest to rozwiązanie mało eleganckie, które osobiście odradzam jako rozwiązanie w poważnym projekcie. Nie mniej jednak zachęcam do eksperymentowania z R-2R, które może się przydać wszędzie tam, gdzie potrzebna jest mała rozdzielczość lub zadowalający jest nastaw z grubsza.

Domyślnie program pcb (gEDA) nie daje nam możliwości dodawania obrazków bezpośrednio, trzeba to zrobić trochę na okrętkę.

Aby tego dokonać potrzebne nam będzie kilka narzędzi: Inkscape oraz pstoedit. Obydwa programy są dostępne w repozytorium ubuntu i można jest zainstalować przy pomocy poniższego polecenia:

$ sudo apt-get install inkscape pstoedit

Teraz gdy mamy już wszystkie niezbędne narzędzia, otwieramy obrazek, który chcemy umieścić w naszym projekcie pcb przy pomocy inkscape’a.

Plik → Importuj

A następnie, gdy program nas zapyta o to, czy chcemy importowany obrazek połączyć czy osadzić, odpowiadamy „łącze”.

Następnie zaznaczamy zaimportowany obrazek i z górnego menu wybieramy

Ścieżka → Wektoryzuj bitmapę

A następnie w oknie, które nam się pokazało dajemy po prostu OK (można dostroić również w nim parametry).

Następnie musimy dopasować rozmiar naszego obrazka tak, aby był odpowiedni dla naszego projektu PCB. W tym celu w inkscapie wybieramy z menu:

Plik → Właściwości dokumentu

I w oknie,które nam się pokazało, wybieramy jako jednostka mm i określamy wysokość i szerokość tak, jak widać to na poniższym rysunku:

Następnie, używając narzędzia strzałki, ustawiamy oraz zmieniamy rozmiar obrazka tak, aby mieścił się na stronie. Podczas zmiany rozmiaru przytrzymujemy Ctrl, w ten sposób podczas zmiany rozmiaru nie zmienią się proporcje obrazka.

Teraz mamy już gotowy obrazek, który zapisujemy jako postscript:

Plik → Zapisz jako

W tym momencie kończy się nasza praca z Inkscapeam. Teraz należy otworzyć konsolę i przejść do katalogu, w którym zapisaliśmy nasz plik ps, a następnie wydać polecenie:

$ pstoedit -f pcb Rysunek.ps Rysunek.pcb

W ten sposób nasz obrazek został zmieniony w plik pcb. Otwieramy teraz go w programie pcb i oto efekt:

Jak widzimy, nasz obrazek został umieszczony na warstwie oznaczonej jako „poly”, która jest tak naprawdę warstwą „components”, czyli widokiem ścieżek od strony elementów. Aby nasz obrazek przenieść na warstwę opisową „silkscreen”, należy otworzyć plik pcb w edytorze tekstu i przekopiować odpowiedni fragment na odpowiednią warstwę. Widać to na poniższym zrzucie ekranu:

Fragment opisujący nasz obrazek (Polygon(„clearpoly”) (…)) możemy równie dobrze przekopiować do innego pliku.

Po zapisaniu obrazka i otwarciu naszego pliku PCB mamy nasz obrazek na warstwie silk…

I to wszystko, osadziliśmy nasz obrazek w projekcie PCB. Swoją drogą, dziwi mnie fakt, że nie ma bezpośrednio opcji zaimportowania obrazka do projektów prosto z gedy i trzeba korzystać z takich udziwnień…

• max6126.sym (Ultra-High-Precision, Ultra-Low-Noise, Series Voltage Reference)
• max531.sym (+5V, Low-Power, Voltage-Output, Serial 12-Bit DACs)
• max144.sym (+2.7V, Low-Power, 2-Channel, 108ksps, Serial 12-Bit ADCs in 8-Pin μMAX)
• INA168.sym (High-Side Measurement CURRENT SHUNT MONITOR)
• DS18B20.sym (DS18B20 Programmable Resolution 1-Wire Digital Thermometer)

Jak to działa?

Jest to typowa klawiaturka numeryczna 0-9 dodatkowo wyposażona w 4 przyciski funkcyjne (a,b,c,d), zasilana z 5V DC, z wyjściem szeregowym (9600 boud rate) lub spi. Przyciski w celu zaoszczędzenia pinów kontrolera są ułożone w macierz, tzn. wszystkie przyciski w danej kolumnie są połączone i wszystkie w danym wierszu również. Poniżej schemat takiego połączenia:

Następnie program zapisany w mikrokontrolerze (ja użyłem AT90S2313, jednak może to być cokolwiek innego rodziny avr np. jakaś atmega) „skanuje” taką macierz w poszukiwaniu zwartych styków. Odbywa się to w następujący sposób:

Wiersze od góry są podpięte do portów PD6, PB0, PB1 oraz PB7 mikrokontrolera, a kolumny do portów PB6, PB5, PB4, PB3, PB2, co widać na rysunku powyżej. W pierwszej kolejności porty podłączone do wierszy są ustawiane jako wyjścia:

	DDRB |= (1<<PB0); //port as output
	DDRB |= (1<<PB1); //port as output
	DDRB |= (1<<PB7); //port as output
	DDRD |= (1<<PD6); //port as output

a te podłączone do kolumn jako wejścia:

	DDRB &=~ (1 << PB2); //port as input
	DDRB &=~ (1 << PB3); //port as input
	DDRB &=~ (1 << PB4); //port as input
	DDRB &=~ (1 << PB5); //port as input
	DDRB &=~ (1 << PB6); //port as input

z włączonymi wewnętrznymi rezystorami podciągającymi je do plusa:

	PORTB |= (1 << PB2); //pull-up enable
	PORTB |= (1 << PB3); //pull-up enable
	PORTB |= (1 << PB4); //pull-up enable
	PORTB |= (1 << PB5); //pull-up enable
	PORTB |= (1 << PB6); //pull-up enable

a wszystkie porty ustawione jako wyjścia są ustawiane w stan wysoki.

Następnie po kolei od góry do dołu podawany jest stan niski na kolejne wiersze aż do ostatniego.
Po podaniu stanu niskiego na pierwszy wiersz program sprawdza po kolei od lewej do prawej strony, czy któryś z przycisków nie został zwarty, a tym samym nie powoduje stanu niskiego na jednym z wejść podłączonych do kolumn. Jeśli któreś z wejść jest ustawione na stan niski, wówczas odczytywana jest aktualna pozycja, tj. numer kolumny i wiersza, i na tej podstawie określany jest przycisk, który został wciśnięty. Jeśli w danej kolumnie żaden przycisk nie został wciśnięty, wówczas program kontynuuje przeszukiwanie aż do ostatniej kolumny i ostatniego wiersza, a następnie zaczyna od początku. Poniższa animacja obrazuje działanie algorytmu.

Po wykryciu, że któryś z przycisków został wciśnięty, zostaje uruchomiony prosty kod mający na celu debounce sygnału wejściowego z przycisku, a następnie zostaje wysłany przez port szeregowy znak odpowiadający danemu klawiszowi.

Obsługa portu szeregowego jest typowa i jest on skonfigurowany w trybie tylko do wysyłania znaków. Czyli po kolei mamy:

#define F_CPU       8000000L

Definiujemy sobie prędkość oscylatora mikrokontrolera, a następnie definiujemy żądaną prędkość transmisji:

#define UART_BAUD   9600

a także tworzymy sobie proste makro, które służy do obliczenia stałej dla portu wyjściowego:

#define UART_CONST  (F_CPU/(16ul*UART_BAUD)-1)

której wartość następnie przypisujemy do rejestru UBRR, czym jednocześnie definiujemy prędkość transmisji

UBRR = (unsigned char)UART_CONST;

a następnie korzystamy z rejestru UCR, w którym ustawiamy bit TXEN (TX Enable), który oznacza zgodę na wysyłanie znaków (analogicznie istnieje w tym rejestrze bit dla odbioru danych RXEN).

Po tych operacjach mamy już działający port szeregowy z prędkością 9600.

Teraz czas, aby coś na niego wysłać. W tym celu mamy stworzoną procedurkę UART_putchar(), która wygląda tak:

void UART_putchar(char c)
{ 
    UDR=c; 
    loop_until_bit_is_set(USR,TXC); 
    USR |= (1<<TXC); 
}//end of UART_putchar()

UDR to rejestr wyjściowy portu szeregowego – jego zawartość zostanie wysłana przez port, a kiedy się już to stanie (transmisja zostanie zakończona), zostanie ustawiony bit TXC w rejestrze USR, który po wysłaniu możemy już skasować (ostatnia linijka powyższej procedury), tym samym umożliwiając wysłanie kolejnego znaku.

Korzystając z portu szeregowego w swoich aplikacjach mikrokontrolerowych, należy zwrócić uwagę na dobór odpowiedniego kwarcu, którym napędzamy nasz układ. Jest to o tyle istotne, że dla różnych wartości prędkości oscylatora występują różne procentowe wartości błędów transmisji, które mogą wynosić od zera do kilku procent. W poniższej tabelce, która pochodzi z noty katalogowej, jest pokazana ta zależność.

Konstrukcja

Ja swój prototyp wykonałem na dwustronnym laminacie FR4 (szklano-epoksydowy), ścieżki przenosiłem termotransferem (pozdrowienia dla mojej laminarki , a całość jest zabezpieczona termoutwardzalną solder-maską.

Gumki stykowe oraz klawisze są wymontowane z kalkulatora ActiveJet ASC-8003 (koszt ok. 3 do 9zł), w kalkulatorku jest też fajny wyświetlacz LCD o dużych czytelnych cyfrach, który myślę, że w najbliższym czasie zhakuję i opiszę jak go podłączyć do kontrolera.

Obrazki, filmiki, pliki, szał!

Poniżej na filmiku prezentuję mój układ prototypowy klawiaturki. Jest ona na nim podłączona przejściówką USB->RS232 z wyjściami TTL bezpośrednio do komputera, na którym jest uruchomiony gtkterm.

Poniżej pliki do ściągnięcia oraz galeria zdjęć prototypu, have fun!

• PCB
• PCB – odbicie lustrzane
• Paczka z kodem oraz wszystkimi plikami

PWM (Puls Width Modulation)

PWM (Puls Withd Modulation), czyli modulacja szerokości impulsu, to nic innego jak stały przebieg prostokątny o zmiennym wypełnieniu od 0% do 100%. Jeśli ktoś nie wie jak wygląda taki przebieg, to poniżej może zobaczyć kilka oscylografów (jeśli tak można nazwać te kiepskie fotki), które powinny rozwiać wątpliwości. Aby jednak wykorzystać taki przebieg w naszej aplikacji, musimy go najpierw scałkować… Bez obawy! Nie będziemy tutaj przeprowadzać karkołomnych obliczeń matematycznych, my naszą całkę zrobimy przy pomocy filtru RC.

Oscylografy przebiegów PWM

Zacznijmy od wygenerowania takiego przebiegu przy pomocy mikrokontrolera. Ja użyję tutaj atmega8, jednak nie ma to większego znaczenia (może to być z powodzeniem inna atmega).

Atmega8 jest wyposażona w 3 kanały pwm (2 podpięte pod 16bitowy Timer1 oraz 1 na 8bitowym Timer2). Nas interesują te dwa kanały na 16 bitowym liczniku / tajmerze, ponieważ tylko one pozwalają (w przypadku atmegi8) na generowanie sygnału o rozdzielczości 10bitów.

Dostęp do timera 1 zapewnia nam kilka rejestrów, do których mamy dostęp, nas jednak interesować będą tylko: TCCR1A , TCCR1B oraz OCR1A/B. Rejestry TCCR1A/B są to rejestry kontrolne, w których ustawiamy parametry timera, które nas interesują, natomiast OCR1A/B jest rejestrem porównawczym, który jest ciągle porównywany (w każdym cyklu timera) z aktualną wartością timera. Mówiąc prostymi słowy, jeśli nasz licznik naliczy tyle, ile mamy zapisane w OCR1A/B, wówczas __coś__ się stanie… w naszym przypadku, wartość ta będzie ustalała wartość wypełnienia przebiegu wyjściowego.

TCCR1A

Przyjrzyjmy się teraz bliżej rejestrom kontrolnym. Zgodnie z dokumentacją jest on zbudowany jak na poniższym rysunku:

Bity COM1A1, COM1A0, COM1B1, COM1B0 służą do ustawiania trybu porównywania wyjścia licznika, a ich dokładny opis można znaleźć w tabelce poniżej:

FOC1A/B są wykorzystywane tylko w trybach niezwiązanych z PWM tak że pomińmy je sobie teraz.
Dalej mamy WGM11 oraz WGM10 (w starszych układach było to odpowiednio PWM11 oraz PWM10), a także WGM12 i WGM13, które znajdują się już w rejestrze TCCR1B, służą one do ustawiania trybu pracy wyjścia. Poniższa tabelka przedstawia dostępne opcje.

Nas będzie interesował tryb numer 3, czyli PWM, Phase Correct, 10-bit (ustawione bity WGM10 i WGM11). W tym trybie będziemy mieli do dyspozycji 10 bitowy PWM z korekcją fazy. Co to oznacza? Oznacza to tyle, że nasz przebieg będzie mógł mieć 1024 (10bit) różne wartości wypełnienia oraz będzie pracował w trybie korekcji fazy, który polega na tym, że timer zlicza od zera do góry, a następnie z powrotem z góry do zera, przy czym zeruje się, gdy jego wartość jest równa wartości zapisanej w rejestrze OCR1A/B. Dzieje się tak w obydwu kierunkach – podczas zliczania w górę, jak i w dół. W rezultacie na wyjściu otrzymujemy bardziej symetryczny przebieg. Częstotliwość tak generowanego sygnału jest niestety około dwukrotnie mniejsza niż w przypadku trybu fast-pwm, co wynika z konieczności zliczania w obu kierunkach.

TCCR1B

Rejestr TCCR1B jest zbudowany tak, jak pokazuje poniższy rysunek.

Bity ICNC1 oraz ICES1 służą odpowiednio do włączania redukcji szumów wejściowych na nóżce oznaczonej jako ICP1 oraz do określenia zbocza, które aktywuje ICP1. Nie będą one jednak przez nas wykorzystywane.

Bit 5 nie służy do niczego Jest on po prostu zarezerwowany dla przyszłych ficzersów.

Bity WGM12 oraz WGM13 służą do ustalania trybu pracy timera i są opisane w powyższej tabelce.

Bity CS10, CS11 oraz CS12 służą do ustawiania preskalera. Czyli dzięki nim jesteśmy w stanie ustawić częstotliwość, z jaką będzie pędził nasz generator PWM! Na poniższym rysunku przedstawiony jest sposób ich ustawienia oraz odpowiadające im wartości podziału częstotliwości zegara (clk i/o).

I to by było tyle, jeśli chodzi o te dwa rejestry kontrolne. W praktyce wszystko sprowadza się do wybrania trybu pracy (bity WGM*), trybu porównywania (bity COM*) oraz ustawienia preskalera (bity CS*).

Program testowy

Wyposażeni już w wiedzę na temat rejestrów odpowiedzialnych za kontrolowanie pracy timera zbudujmy sobie prosty układ testowy i napiszmy program testowy…

Poniżej schemat układu testowego (jest to właściwie ten sam układ co w części 1 artykułu)

Oraz nasz program testowy:

int PWMval = 0;

void init_dac()
{
	OCR1A = 0;
	TCCR1A = _BV(COM1A1)|_BV(COM1A0)|_BV(WGM10)|_BV(WGM11);
	TCCR1B = 1<<CS10;
}

int main()
{
 char buffer[7];

 init_encoder();
 init_lcd();
 init_dac();

  while(1)
  {
    read_encoder();
    if(tackt != NEUTRAL)
    {
      
		if(tackt == LEFT && PWMval > 0)
		{
			PWMval--;
		} 
		else if(tackt == RIGHT && PWMval < 1023)
		{
			PWMval++;
		}
        
		lcd_clrscr();
		itoa(PWMval, buffer, 10);
		lcd_puts(buffer);

		OCR1A = PWMval;

		tackt = NEUTRAL;
	} 
  }
}

Jak widać na powyższym kodzie, mamy procedurkę init_dac()I, która ustawia timer 1 w trybie 10bitowego PWM z korekcją fazy, dalej ustawiamy bity COM1A0 oraz COM1A1 tak, aby rejestr OC1A był ustawiany, kiedy wartość licznika, podczas zliczania w górę, osiągnie wartość zadaną z rejestru OCR1A, oraz kasowany, kiedy wartości te będą takie same podczas zliczania w dół.

Dalej ustawiamy bit CS10 w rejestrze kontrolnym TCCR1B, co odpowiada ustawieniu preskalera na 1 oraz rozpoczęcie pracy generatora.

W głównej pętli programu, podczas manipulowania enkoderem w lewo i prawo, wartość zmiennej PWMval jest odpowiednio inkrementowana oraz dekrementowana, a następnie przypisywana do rejestru OCR1A i tym samym ustawiana jest nowa wartość wypełnienia przebiegu wyjściowego.

I to tak naprawdę wszystko. Prawda, że proste? Raptem tylko 3 linijki dzielą nas od działającego 10bitowego PWM’a

Co dalej z prostokątem ?

Ok, potrafimy już wygenerować przebieg prostokątny o wypełnieniu od 0% do 100%, teraz potrzebujemy, aby ten sygnał zmienił się w napięcie proporcjonalne do jego wypełnienia. Aby tego dokonać, należy sygnał ów uśrednić. Do tego celu zastosujemy odpowiedni filtr dolnoprzepustowy RC.

Problem z tego typu filtrami polega na tym, że stosując zbyt małą pojemność (wysoka częstotliwość odcięcia), przebieg na wyjściu nie nadaje się jako źródło napięcia odniesienia czy też napięcia sterującego cokolwiek, a z drugiej strony, zwiększając wartość C (niska częstotliwość odcięcia), zwiększa się czas propagacji, czyli czas, który upłynie pomiędzy przekręceniem gałką a pojawieniem się żądanego napięcia na wyjściu. Aby zniwelować w pewnym stopniu tę niedogodność, możemy zastosować filtry aktywne. Filtr taki jest zbudowany na wzmacniaczu operacyjnym, który ma bardzo dużą rezystancję wejściową, co dodatkowo jest nam na rękę, ponieważ podłączając wyjście naszego filtra RC (pasywnego) do odbiornika, którego rezystancja wejściowa jest niewielka, odbiornik ten rozładowuje w pewnym stopniu kondensator C, co negatywnie wpływa na stabilność całego budowanego przetwornika DAC.

Częstotliwość odcięcia dla filtru pokazanego na powyższym rysunku jest określana następującym wzorem:

Łącząc takie filtry w szereg, zwiększamy nachylenie filtru, tworząc filtr n-rzędu, jednak wówczas sygnał jest odpowiednio tłumiony (np. dla filtru 2go rzędu sygnał jest tłumiony dwa razy o 6db).
Nie chciałbym tutaj się rozwodzić na temat filtrów, ponieważ jest to temat bardzo obszerny i ten artykuł mógłby urosnąć do gigantycznych rozmiarów… Niemniej jednak, aby nie pozostawiać Wam niedosytu w tym temacie, polecam pobrać darmowy program Filter Pro wydany przez texas instruments i poeksperymentować w nim z różnego rodzaju filtrami.
Program ten jest dostępny pod tym linkiem: http://www.ti.com/tool/filterpro?DCMP=hpa_amp_general&HQS=NotApplicable%252bOT%252bfilterpro

Parametry

Wiemy już, jak zrealizować prosty przetwornik cyfrowo-analogowy przy wykorzystaniu pwm. Spróbujmy sobie teraz przeanalizować jego parametry, możliwości ich poprawy oraz przydatność tego rozwiązania w naszej aplikacji.

Wbrew pozorom parametry tak wykonanego DACa mogą być całkiem przyzwoite, a wyjścia portów I/O, zresztą tak jak cały kontroler, są wykonane w technologi CMOS, dzięki czemu w stanie wysokim na wyjściu pojawia się praktycznie napięcie zasilania, natomiast w stanie niskim zero.
Wykorzystując tę właściwość można zastosować popularną technikę zwiększającą precyzję tak generowanego sygnału, która polega na zasilaniu całego mikrokontrolera ze źródła napięcia odniesienia. Dzięki czemu otrzymywany na wyjściu sygnał jest całkiem niezłej jakości.
Nie chcę tutaj jednak wchodzić w szczegóły i rzucać konkretnymi danymi liczbowymi, ponieważ tak zbudowany przetwornik ma jedną zasadniczą wadę, która dyskryminuje go całkowicie w naszym zastosowaniu. Jest nią nieakceptowalnie długi czas ustalania średniego napięcia na wyjściu filtra dolnoprzepustowego podłączonego do wyjścia generatora PWM.
W przypadku gdyby nasz zasilacz korzystał z histerezy wykonanej przy pomocy wzmacniaczy operacyjnych, a kontroler służyłby tylko do zadawania odpowiednich napięć referencyjnych dla ustalenia napięcia i prądu wyjściowego, takie rozwiązanie byłoby akceptowalne. Niestety czas ustalania, nawet wykorzystując aktywne filtry dolnoprzepustowe, jest znacznie za długi i w przypadku zadziałania ogranicznika prądu lub przy skokach napięcia, zanim zdążyłoby się ustabilizować napięcie wyjściowe, podłączony do naszego zasilacza układ mógłby się upiec.

Podsumowanie

Niemniej jednak, polecam wszystkim eksperymenty z PWM, gdyż jest to technika bardzo szeroko wykorzystywana w różnych aplikacjach i na pewno przyda się Wam jeszcze nieraz!
W następnym odcinku postaram się zaprezentować rozwiązanie DAC’a oparte o drabinkę rezystorową R2R, pokażę Wam, jak zrealizować 16bitowy przetwornik oparty na r2r, wykorzystując tylko 3 piny procesora, a do tego nie będzie to kosztowało więcej niż 2 zł

Jako że zbliża się Nowy Rok, a niestety przed Świętami czasu na pisanie nie było, życzę Wam wszystkim (tak, tak, Wam, spam-boty nękające mnie codziennie – też!!), wszystkiego najlepszego w nadchodzącym nowym roku numer 0x7DC! (miejmy nadzieję, że nie będzie on ostatnim..)

Stay tuned!

Zaczynamy

Zanim zaczniemy cokolwiek projektować, musimy przygotować sobie odpowiednie narzędzia – w naszym przypadku będą to odpowiednie biblioteki programistyczne / komponenty, których później będziemy używać. Zacznijmy na początku od sterowania. Pierwsze, co przychodzi do głowy jako wejście danych do naszego programu/układu, to klawiatura i wszelkie jej odmiany: klawiatura up/down/ok, klawiatura numeryczna 0…9, joystick itp. itd. Kolejna opcja to sterowanie poprzez port szeregowy bezpośrednio z komputera. Pomysł ok, ale bardziej jako ficzers niż jako główne sterowanie (który nota bene zostanie przez nas dodany w następnych odcinkach) – nie wyobrażam sobie sytuacji, kiedy uruchamiam jakiś nowy układ i za każdym razem, kiedy chcę zmienić wartość napięcia albo ustawić ogranicznik prądu sięgam po laptopa.
To, co wydaje się, że byłoby najlepsze to mieć dużą wygodną gałkę, najlepiej potencjometr wieloobrotowy… zostaje tylko pytanie jak go podłączyć do procesora ? Otóż nie podłączać go wcale! W naszym projekcie użyjemy enkodera obrotowego…

Enkoder obrotowy? Co to takiego?!

Enkoder obrotowy to takie małe pokrętełko (foto powyżej), a właściwie sprytny przełącznik, który zmienia swoje stany w zależności od tego, czy kręcimy go w prawo, czy w lewo. Schemat enkodera typu ENC-11 znajduje się poniżej.

Dlaczego akurat ten typ? Bo akurat jest dostępny na pewnym znanym portalu aukcyjnym i jest naprawdę tani. Koszt takiego enkodera to tylko kilka eurocentów, co dodatkowo czyni go jak najbardziej odpowiednim dla nas. Model, który udało mi się zakupić miał dodatkowo wbudowany przełącznik, który zamykał styki po naciśnięciu gałki – fajnie! Będziemy mogli zrobić takie fajne sterowanie menu jak np. w komputerku pokładowym w BMW E39

Zanim zaczniemy podłączać go do kontrolera i programować, przyjrzyjmy się, co jest napisane w dokumentacji.

Na powyższym rysunku zaczerpniętym z noty katalogowej widzimy, jak wygląda sygnał wyjściowy z naszego enkoderka w momencie, gdy go kręcimy w lewo i w prawo. Jak już pewnie zauważyłeś, w zależności od tego, w którą stronę go kręcimy, sygnał na końcówce B jest przesunięty w fazie, tak że mamy albo zbocze opadające albo narastające w stosunku do sygnału wyzwalającego A. Tę właśnie właściwość wykorzystamy w programie. Sygnał z końcówki A będzie nam generował „przerwanie”, natomiast sygnał z końcówki B w zależności od zbocza będzie nas informował o kierunku, w jakim się on obraca.

Podłączamy!

W celu zaprogramowania oraz testowania układu, zbudujmy sobie (najlepiej na płytce stykowej) następujący układ:

Schemat układu testowego

Jak widać na schemacie, będzie nam potrzebny kontroler (ja użyłem Atmega8, może to być jednak dowolny inny rodziny Atmega8..32), wyświetlacz oparty na układzie HD447780, no i nasz enkoder.

Do obsługi samego enkodera wykorzystamy dwa porty procesora ustawione jako wejścia + dodatkowe jedno wejście dla wbudowanego przełącznika.

Pora na kod…

Zanim zacząłem pisać ten artykuł, zrobiłem małe rozeznanie w sieci, jak robią to inni ludzie, jednak ich metody mi się nie podobały. A to dlatego, że wszystkie rozwiązania, które widziałem były oparte o przerwania, co w naszym zastosowaniu nie jest najszczęśliwsze, gdyż kontroler będzie się zajmował również stabilizacją napięcia wyjściowego zasilacza. Zatem ewentualne opóźnienie, które mogłoby wprowadzić takie rozwiązanie obsługi enkodera, mogłoby skutkować niestabilną pracą zasilacza, a co za tym idzie – skokami napięcia wyjściowego.

Nasz program (biblioteka?) będzie się składał z dwóch procedur. Pierwsza z nich będzie uruchamiana na początku programu i będzie się w niej znajdował kod odpowiedzialny za inicjalizację i konfigurację portów – nazwijmy ją init_encoder(). Druga z kolei będzie uruchamiana w głównej pętli programu, a jej zadaniem będzie uaktualnianie zmiennej globalnej tackt, która będzie nas informowała o aktualnym stanie enkodera: LEFT, RIGHT, CLICK – nazwijmy ją read_encoder().

Konfiguracja

Poniższy kod przedstawia ciało procedury init_encoder()

#define ENC_PIN_1_PIN       PINC
#define ENC_PIN_1_REG       DDRC        //first encoder pin register
#define ENC_PIN_1_PORT      PORTC       //first encoder pin port
#define ENC_PIN_1           PC4         //first encoder pin

#define ENC_PIN_2_PIN       PINC
#define ENC_PIN_2_REG       DDRC        //second encoder pin register
#define ENC_PIN_2_PORT      PORTC       //second encoder pin port
#define ENC_PIN_2           PC5         //second encoder pin

#define ENC_BTN             PD7         //encoder button pin
#define ENC_BTN_PORT        PORTD       //encoder button port
#define ENC_BTN_REG         DDRD        //encoder button register
#define ENC_BTN_PIN         PIND

#define LEFT    1
#define RIGHT   2
#define CLICK   3
#define NEUTRAL 0

uint8_t tackt;

void init_encoder(void )
{
    ENC_PIN_1_REG &=~ (1 << ENC_PIN_1);        /* Pin 1 input              */
    ENC_PIN_1_PORT |= (1 << ENC_PIN_1);        /* Pin 1 pull-up enabled    */

    ENC_PIN_2_REG &=~ (1 << ENC_PIN_2);        /* Pin 2 input              */
    ENC_PIN_2_PORT |= (1 << ENC_PIN_2);        /* Pin 2 pull-up enabled    */

    //click button
    ENC_BTN_REG &=~ (1 << ENC_BTN);        /* Pin button input              */
    ENC_BTN_PORT |= (1 << ENC_BTN);        /* Pin button pull-up enabled    */
}//end of init_encoder()

Jak widać, nie ma tutaj wielkiej filozofii, po prostu ustawiamy 3 wybrane przez nas porty kontrolera jako wejścia oraz aktywujemy dla nich pull-up`y (podciągnięcia wewnętrznym rezystorem do plusa zasilania). Oprócz tego w globalnej przestrzeni programu definiujemy dwie zmienne globalne: 8mio bitową zmienną tackt, która będzie nas informowała o aktualnym stanie enkodera, oraz zmienną pomocniczą last.
Zdefiniowałem oprócz tego jeszcze kilka stałych LEFT, RIGHT, CLICK, NEUTRAL – te 4 stale są listą enumeratywnych wartości stanów enkodera, ENC_PIN_*, w których definiujemy, do których portów kontrolera jest podłączony enkoder.

Czytanie stanu enkodera

Poniższy fragment kodu przedstawia ciało procedury, która służy do odczytu aktualnego stanu enkodera.

void read_encoder(void )
{
    uint8_t current = 0;
    unsigned int i = 0;

    if(bit_is_clear(ENC_BTN_PIN, ENC_BTN))
    {
        for(i=0;i<65535;i++)
        {
            if(!bit_is_clear(ENC_BTN_PIN, ENC_BTN))
                return ;
        }

        tackt = CLICK;
        return ;
    }

    if(bit_is_clear(ENC_PIN_1_PIN, ENC_PIN_1))
        current = 1;
    else
        current = 0;

    if(last != current)
    {
        if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_1))
        {
            if(bit_is_clear(ENC_PIN_2_PIN,ENC_PIN_2))
                tackt = LEFT;
            else
                tackt = RIGHT;
        }
        else
        {
            if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_2))
                tackt = RIGHT;
            else
                tackt = LEFT;
        }

        last = current;
    }
}//end of read_encoder()

W pierwszej kolejności sprawdzamy, czy został przyciśnięty przycisk wbudowany w pokrętło enkodera.

    if(bit_is_clear(ENC_BTN_PIN, ENC_BTN))
    {
        for(i=0;i<65535;i++)
        {
            if(!bit_is_clear(ENC_BTN_PIN, ENC_BTN))
                return ;
        }

        tackt = CLICK;
        return ;
    }

Jeśli na pinie ustawionym jako wejście przycisku enkodera pojawi się stan niski, wówczas do zmiennej globalnej tackt przypisujemy wartość CLICK i kończymy wykonywanie procedury.
Dodatkowo znajduje się tam pętla, która sprawdza, czy przez 65535 cyklów, cały czas przycisk jest non-stop wciśnięty – jest to bardzo prymitywny kod debouncujący. Co to znaczy? Podczas przełączania każdego elektromechanicznego przełącznika, zanim znajdzie się on w stabilnym stanie (włączonym bądź wyłączonym), to w czasie przełączania występuje zjawisko iskrzenia i „podskakiwania styków”, wejście kontrolera jest natomiast na tyle czułe, że wyłapuje te „migotania” i interpretuje je jako zmiany stanu portu. Natomiast dzięki takiej pętli debouncującej upewniamy się, że przycisk jest już wciśnięty „na stałe”.

Dalej zaczyna się właściwy kod odpowiedzialny za wykrywanie aktualnego stanu enkodera

    if(bit_is_clear(ENC_PIN_1_PIN, ENC_PIN_1))
        current = 1;
    else
        current = 0;

Na początku sprawdzamy, czy na pinie podłączonym do wyjścia A enkodera (nasze wyjście wyzwalające), został ustawiony stan niski, jeśli tak, to zapisujemy w zmiennej current jedynkę, jeśli natomiast nie, zapisujemy w niej wartość zero. W ten sposób w zmiennej current mamy aktualny stan wejścia wyzwalającego.

Dalej mamy warunek, w którym sprawdzamy, czy aktualnie odczytana wartość wejścia wyzwalającego jest różna od ostatnio odczytanej wartości, jeśli tak, oznacza to, że pokrętło zostało poruszone, nadal jednak nie wiemy, czy w lewo, czy w prawo. Aby to określić, mamy dalej odpowiednie warunki, w których sprawdzamy, czy ruch nastąpił w lewo, czy w prawo. Poniekąd można powiedzieć, że do tej pory kod, który został wykonany, jest swoistym substytutem przerwania, które mogłoby być wygenerowane podczas zmiany stanu enkodera.
Mamy zatem następujący kod:

    if(last != current)
    {
        if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_1))
        {
            if(bit_is_clear(ENC_PIN_2_PIN,ENC_PIN_2))
                tackt = LEFT;
            else
                tackt = RIGHT;
        }
        else
        {
            if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_2))
                tackt = RIGHT;
            else
                tackt = LEFT;
        }

        last = current;
    }

Najpierw sprawdzamy, czy na nóżce A enkodera jest aktualnie stan niski, jeśli tak, to sprawdzamy, czy na nóżce B enkodera jest również stan niski, jeśli tak, oznacza to sytuację z górnej części rysunku z datasheetu, czyli wiemy, że gałka enkodera została przesunięta w kierunku ruchu wskazówek zegara (clockwise). Jeżeli natomiast na nóżce B enkodera stan jest wysoki, oznacza to sytuację z dolnej części tego rysunku, czyli gałka została przekręcona w kierunku odwrotnym do ruchu wskazówek zegara (counter-clockwise). Po tych warunkach przypisujemy odpowiednią wartość do zmiennej globalnej tackt. Jeśli natomiast pierwszy warunek nie zostanie spełniony (na nóżce A enkodera jest stan wysoki), dokonujemy analogicznego testu. Jedynie tylko należy uwzględnić, że wartości z rysunku (datasheet) są przesunięte o pół okresu.

Na końcu przypisujemy aktualną wartość wejścia wyzwalającego (nóżka A enkodera) do zmiennej last. I na tym kończy się procedura.

Złóżmy to do kupy…

Poniżej cały złożony razem kod.

define ENC_PIN_1_PIN       PINC
#define ENC_PIN_1_REG       DDRC        //first encoder pin register
#define ENC_PIN_1_PORT      PORTC       //first encoder pin port
#define ENC_PIN_1           PC4         //first encoder pin

#define ENC_PIN_2_PIN       PINC
#define ENC_PIN_2_REG       DDRC        //second encoder pin register
#define ENC_PIN_2_PORT      PORTC       //second encoder pin port
#define ENC_PIN_2           PC5         //second encoder pin

#define ENC_BTN             PD7         //encoder button pin
#define ENC_BTN_PORT        PORTD       //encoder button port
#define ENC_BTN_REG         DDRD        //encoder button register
#define ENC_BTN_PIN         PIND

#define LEFT    1
#define RIGHT   2
#define CLICK   3
#define NEUTRAL 0

uint8_t tackt = NEUTRAL;
uint8_t last = 0;

void init_encoder(void )
{
    ENC_PIN_1_REG &=~ (1 << ENC_PIN_1);        /* Pin 1 input              */
    ENC_PIN_1_PORT |= (1 << ENC_PIN_1);        /* Pin 1 pull-up enabled    */

    ENC_PIN_2_REG &=~ (1 << ENC_PIN_2);        /* Pin 2 input              */
    ENC_PIN_2_PORT |= (1 << ENC_PIN_2);        /* Pin 2 pull-up enabled    */

    //click button
    ENC_BTN_REG &=~ (1 << ENC_BTN);        /* Pin button input              */
    ENC_BTN_PORT |= (1 << ENC_BTN);        /* Pin button pull-up enabled    */
}//end of init_encoder()

void read_encoder(void )
{
    uint8_t current = 0;
    unsigned int i = 0;

    if(bit_is_clear(ENC_BTN_PIN, ENC_BTN))
    {
        for(i=0;i<65535;i++)
        {
            if(!bit_is_clear(ENC_BTN_PIN, ENC_BTN))
                return ;
        }

        tackt = CLICK;
        return ;
    }

    if(bit_is_clear(ENC_PIN_1_PIN, ENC_PIN_1))
        current = 1;
    else
        current = 0;

    if(last != current)
    {
        if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_1))
        {
            if(bit_is_clear(ENC_PIN_2_PIN,ENC_PIN_2))
                tackt = LEFT;
            else
                tackt = RIGHT;
        }
        else
        {
            if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_2))
                tackt = RIGHT;
            else
                tackt = LEFT;
        }

        last = current;
    }
}//end of read_encoder()

int main()
{
  init_encoder();
  init_lcd();
  
  while(1)
  {
    read_encoder();
    if(tackt != NEUTRAL)
    {
      lcd_clrscr();
      
      if(tackt == LEFT)
        lcd_puts(PSTR("Left"));
      else if(tackt == RIGHT)
        lcd_puts(PSTR("Right"));
      else if(tackt == CLICK)
        lcd_puts("Click");
        
      tackt = NEUTRAL;
    } 
  }
}//end of main()

Zobaczmy po kolei, co się dzieje. Program wchodzi w funkcję main, najpierw inicjalizuje porty kontrolera odpowiedzialne za obsługę kontrolera oraz bibliotekę obsługi wyświetlacza.
Dalej program przechodzi do głównej pętli, w której za każdym „przelotem” wywoływana jest procedura read_encoder(), która odczytuje aktualny stan enkodera. Następnie sprawdzamy, czy stan jest różny od NEUTRAL, czyli czy cokolwiek się dzieje z enkoderem, jeśli tak sprawdzamy jego stan i wyświetlamy odpowiedni komunikat na lcd. I na samym końcu czyścimy zmienną globalną tackt poprzez przypisanie jej wartości NEUTRAL. Jest to niezbędne, aby przy następnym wywołaniu procedury read_encoder() wykonała się ona poprawnie.

Co dalej ?

Wypadałoby przenieść nasz kod do osobnych plików, ustawić zmienną tackt jako extender oraz wszystko ładnie sformatować. Poniżej gotowy sformatowany kod:

encoder.h:

#ifndef ENCODER_H
#define ENCODER_H

#define ENC_PIN_1_PIN       PINC
#define ENC_PIN_1_REG       DDRC        //first encoder pin register
#define ENC_PIN_1_PORT      PORTC       //first encoder pin port
#define ENC_PIN_1           PC4         //first encoder pin

#define ENC_PIN_2_PIN       PINC
#define ENC_PIN_2_REG       DDRC        //second encoder pin register
#define ENC_PIN_2_PORT      PORTC       //second encoder pin port
#define ENC_PIN_2           PC5         //second encoder pin

#define ENC_BTN             PD7         //encoder button pin
#define ENC_BTN_PORT        PORTD       //encoder button port
#define ENC_BTN_REG         DDRD        //encoder button register
#define ENC_BTN_PIN         PIND

#define LEFT    1
#define RIGHT   2
#define CLICK   3
#define NEUTRAL 0

extern uint8_t tackt;

void init_encoder(void );
void read_encoder(void );

#endif

encoder.c:

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

#include "encoder.h"

uint8_t tackt = NEUTRAL;
uint8_t last = 0;

void init_encoder(void )
{
    ENC_PIN_1_REG &=~ (1 << ENC_PIN_1);        /* Pin 1 input              */
    ENC_PIN_1_PORT |= (1 << ENC_PIN_1);        /* Pin 1 pull-up enabled    */

    ENC_PIN_2_REG &=~ (1 << ENC_PIN_2);        /* Pin 2 input              */
    ENC_PIN_2_PORT |= (1 << ENC_PIN_2);        /* Pin 2 pull-up enabled    */

    //click button
    ENC_BTN_REG &=~ (1 << ENC_BTN);        /* Pin button input              */
    ENC_BTN_PORT |= (1 << ENC_BTN);        /* Pin button pull-up enabled    */
}//end of init_encoder()

void read_encoder(void )
{
    uint8_t current = 0;
    unsigned int i = 0;

    if(bit_is_clear(ENC_BTN_PIN, ENC_BTN))
    {
        for(i=0;i<65535;i++)
        {
            if(!bit_is_clear(ENC_BTN_PIN, ENC_BTN))
                return ;
        }

        tackt = CLICK;
        return ;
    }

    if(bit_is_clear(ENC_PIN_1_PIN, ENC_PIN_1))
        current = 1;
    else
        current = 0;

    if(last != current)
    {
        if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_1))
        {
            if(bit_is_clear(ENC_PIN_2_PIN,ENC_PIN_2))
                tackt = LEFT;
            else
                tackt = RIGHT;
        }
        else
        {
            if(bit_is_clear(ENC_PIN_1_PIN,ENC_PIN_2))
                tackt = RIGHT;
            else
                tackt = LEFT;
        }

        last = current;
    }
}//end of read_encoder()

Podsumowanie

Polecam samemu poeksperymentować z enkoderem. Imo jest on bardzo wygodnym sposobem obsługi menu i generalnie dobrym interfejsem użytkownik->sprzęt. W następnym odcinku zajmiemy się kolejnym ważnym elementem, jakim jest przetwornik DAC. Będziemy również podejmować pierwsze poważne decyzje projektowe, które będą rzutować na dalszy przebieg prac i ostateczny produkt! Stay tuned!

Sauerbraten, aby zoptymalizować liczbę przesyłanych danych do/z serwera, większość pracy wykonuje po stronie klienta. Daje to możliwość wykonania pewnych modyfikacji kodu, które chciałbym tutaj przedstawić. Nie są to typowe cheaty, które nie dają przeciwnikowi żadnych szans, a jedynie drobne modyfikacje, które sprawiają, że gra się lepiej.

Zaczynamy

Po ściągnięciu źródeł gry (są one dołączone do jej dystrybucji), możemy przystąpić do modyfikacji. To, co będzie nas interesowało, to structura zawarta w pliku src/fpsgame/game.h. Odpowiada ona za zachowanie się konkretnych typów broni używanych w grze. Wygląda ona następująco:

static const struct guninfo { short sound, attackdelay, damage, projspeed, part,
			      kickamount, range; const char *name, *file;
			    } guns[NUMGUNS] =
 {
 { S_PUNCH1, 250, 50, 0, 0, 0, 14, "fist", "fist" },
 { S_SG, 1400, 10, 0, 0, 20, 1024, "shotgun", "shotg" }, // *SGRAYS
 { S_CG, 100, 30, 0, 0, 7, 1024, "chaingun", "chaing"},
 { S_RLFIRE, 800, 120, 80, 0, 10, 1024, "rocketlauncher", "rocket"},
 { S_RIFLE, 1500, 100, 0, 0, 30, 2048, "rifle", "rifle" },
 { S_FLAUNCH, 500, 75, 80, 0, 10, 1024, "grenadelauncher", "gl" },
 { S_PISTOL, 500, 25, 0, 0, 7, 1024, "pistol", "pistol" },
 { S_FLAUNCH, 200, 20, 50, PART_FIREBALL1, 1, 1024, "fireball", NULL },
 { S_ICEBALL, 200, 40, 30, PART_FIREBALL2, 1, 1024, "iceball", NULL },
 { S_SLIMEBALL, 200, 30, 160, PART_FIREBALL3, 1, 1024, "slimeball", NULL },
 { S_PIGR1, 250, 50, 0, 0, 1, 12, "bite", NULL },
 { -1, 0, 120, 0, 0, 0, 0, "barrel", NULL }
};

Pola, które będą nas interesowały, to:

Numer kolejny pola	Nazwa	Opis
2	attackdelay	Zwłoka potrzebna na przeładowanie broni. Szczególnie uciążliwa dla rifle.
6	kickamount	Siła odrzutu po wykonaniu strzału. 0 – brak odrzutu, 1024 – zaczynamy latać po każdym strzale
4	projspeed	Szybkość „projekcji”, czyli czas potrzebny na przebycie drogi przez pocisk… Przydatne przy graniu z wyrzutnią rakiet, wówczas pocisk nie leci w powietrzu, zanim trafi w cel. 0 – trafia od razu, 1024 – wlecze się okrutnie

Polecam poeksperymentować z tymi parametrami i ustawić je pod siebie tak, aby grało się nam komfortowo, dla przykładu poniżej moja własna structurka.

static const struct guninfo { short sound, attackdelay, damage, projspeed, part,
			      kickamount, range; const char *name, *file;
			    } guns[NUMGUNS] =
{
    { S_PUNCH1,    250,  50, 0,   0, 0,   4,  "fist",            "fist"  },
    { S_SG,       1400,  10, 0,   0, 0, 1024, "shotgun",         "shotg" },  // *SGRAYS
    { S_CG,        100,  30, 0,   0, 0, 1024,  "chaingun",        "chaing"},
    { S_RLFIRE,    800, 0, 0,  0, 0, 1024, "rocketlauncher",  "rocket"},
    { S_RIFLE,     200, 100, 0,   0, 0, 2048, "rifle",           "rifle" },
    { S_FLAUNCH,   500,  75, 80,  0, 0, 1024, "grenadelauncher", "gl" },
    { S_PISTOL,    500,  25, 0,   0,  0, 1024, "pistol",          "pistol" },
    { S_FLAUNCH,   200,  20, 50,  PART_FIREBALL1,  0, 1024, "fireball",  NULL },
    { S_ICEBALL,   200,  40, 30,  PART_FIREBALL2,  0, 1024, "iceball",   NULL },
    { S_SLIMEBALL, 200,  30, 160, PART_FIREBALL3,  0, 1024, "slimeball", NULL },
    { S_PIGR1,     250,  50, 0,   0,  0,   12, "bite",            NULL },
    { -1,            0, 120, 0,   0,  0,    0, "barrel",          NULL }
};

Celność

Oprócz powyżej opisanych własności broni możemy jeszcze poprawić celność shotguna. W tym celu należy zmodyfikować plik src/fpsgame/weapon.cpp około linii 130 wygląda on tak:

void offsetray(const vec &from, const vec &to, int spread, float range, vec &dest)
   {
       float f = to.dist(from)*spread/1000;
       for(;;)
       {
           #define RNDD rnd(101)-50
           vec v(RNDD, RNDD, RNDD);
           if(v.magnitude()>50) continue;
           v.mul(f);
           v.z /= 2;
           dest = to;
           dest.add(v);
           vec dir = dest;
           dir.sub(from);
           dir.normalize();
           raycubepos(from, dir, dest, range, RAY_CLIPMAT|RAY_ALPHAPOLY);
           return;
       }
   }

Zmieniamy linijkę

#define RNDD rnd(101)-50

na

#define RNDD rnd(2)-1

Co minimalizuje rozrzut shotguna i daje mu celność rifle’a.

Po tych modyfikacjach możemy cieszyć się na nowo grą, którą sobie sami skompilujemy. Kompilacja jest banalnie prosta i polega na wydaniu jednego polecenia make, piszemy po prostu make i to wszystko. Jedyne, o czym należy pamiętać, to zależności, których wymaga sauerbraten do kompilacji i są to wersje developerskie następujących pakietów:

• OpenGL
• SDL
• SDL_mixer
• SDL_image
• zlib

W razie problemów dokładniejszy opis kompilacji znajduje się w pliku src/readme_source.txt

Inne możliwości modyfikacji ?

Bardzo często spotykaną u graczy modyfikacją jest manipulacja w pliku client.cpp, polegająca na tym, że klient wysyła do serwera strukturę, w której znajdują się koordynaty, w których się aktualnie znajduje, tyle tylko, że te koordynaty nie są prawdziwe. Efekt jest taki, że wszyscy gracze widzą Cię w innym miejscu, niż naprawdę się znajdujesz. Nie przedstawiłem jednak w tym wpisie dokładnie, jak to zrobić, ponieważ moim zdaniem modyfikacja ta odbiera przyjemność z gry zarówno nam, jak i innym współgraczom.

Części na sprzedaż - real foto

• Atmega8A-PU – 7,50 zł (brutto)
• DS18B20 – 3,50 zł (brutto)
• MAX232 – 2,00 zł (brutto)

Po przerobieniu niemalże wszystkich dostępnych w sieci „instrukcji”, oczywiście żadna z nich nie doprowadziła do sukcesu. Znalazłem… sterowniki dla linuxa dla tego modelu, wydane przez firmę Movistar (hiszpański telecom), które działają w sposób automagiczny…
Jedyne co jest potrzebne, aby uruchomić ten modem, to paczka zip, która jest dostępna na dole artykułu.
Po jej ściągnięciu i rozpakowaniu, należy nadać znajdującemu się w nim plikowi `install` prawa do wykonywania, można to zrobić z konsoli (chmod +x install) lub z poziomu managera okien, we właściwościach pliku. Po tym wystarczy go uruchomić.
Automatycznie skompiluje się i zainstaluje sterownik dla jądra oraz program Movistar.
Po tej operacji dobrze jest zrestartować komputer. Następnie, gdy włożymy modem w gniazdo USB, automatycznie zostanie uruchomiony program Movistar, który wygląda jak poniżej.

Movistar Main screen

Domyślnie interfejs jest po hiszpańsku, można go zmienić na angielski, wybierając z menu kolejno „Herramientas -> Idioma -> English”. Później już wystarczy tylko dodać nowy profil w Tools->options->Profile Management, dla sieci Era (blueconnect), będzie to wyglądać jak poniżej.

Profile Management

Po czym zatwierdzamy wszystko przyciskiem OK i wybieramy na głównym ekranie ‘Connect’. To wszystko! 5 min i mamy działającego blue connecta w linuxie

• Sterowniki – Linux.zip