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

Na samym początku myślałem o zrobieniu miksera i wbudowaniu go w obudowę zestawu, pomysł ten jednak upadł z dwóch powodów… Po pierwsze nie chciało mi się A po drugie o 2 w nocy ciężko znaleźć otwarty sklep z elektroniką. Zatem stanęło na rozwiązaniu bazującym na tym, co miałem pod ręką, a to, co wyszło, to mikser tyle, że zupełnie pasywny. Rozwiązanie to w moim konkretnym przypadku jest OK, ponieważ wyjścia kart dźwiękowych dają sygnał o amplitudzie około 1 volta, natomiast sygnał potrzebny do wysterowania wzmacniacza wbudowanego w ten zestaw to ok. 0,775 volta. Tak, że mogłem sobie pozwolić na drobne straty w układzie.

Overview

A tak oto wyglądał mój pacjent przed całą operacją:

Z tyłu widać panel, który jest przykręcony sześcioma wkrętami, po ich odkręceniu… spodziewałem się, że elegancko zdemontuję go wraz z przyczepioną do niego elektroniką. Tak jednak się nie stało za sprawą jakiejś paskudnej pianki udającej klej, którą firma creative szczodrze obdarzyła cały ten układ gwarantując mu ochronę przed wibracjami (większości kobiet pewnie by się to nie spodobało).

Myślę, że kwestię wibracji można było rozwiązać bardziej elegancko, nawet w produkcie takim jak ten – z dolnej półki. Tak, że minus dla creativa za tego gluta! Po nieudanej próbie dostania się od strony głośniczka do wnętrza i zbadania tej sprawy nie pozostało mi nic innego jak tylko wyszarpać przylepione, a właściwie obglucone pcb.

Na płytce znalazła się typowa aplikacja układu TDA7378. Jedna rzecz, która wydaje mi się dość dziwna, to sposób zasilania całego układu. Otóż spodziewałem się, że po wyłączeniu całego układu za pomocą kółeczka w tym dziwnym „pilocie” na kablu, zostaje odcięte główne zasilanie w jakiś sposób. Tymczasem, układ jest tak zaprojektowany, że cały czas zasilanie jest podłączone, a przy wyłączeniu go, końcówka mocy ustawiana jest w trybie standby…

Układy wejściowe

Układ wejściowy creativa wygląda jak na schemacie poniżej:

Dla mniej wtajemniczonych pozwolę sobie wyjaśnić, co do czego i po co. JP435 i JP436 to zworki, które będą przez nas wykorzystane później. C59 i C60 to kondensatory „separujące”, które zapobiegają pojawieniu się składowej stałej na wejściu układu. Mówiąc inaczej, przewodzą tylko sygnały zmienne, a ewentualnie pojawiający się prąd stały jest „ignorowany”. Rezystory R59 i R60 służą do rozładowania kondensatorów separujących, gdy nie jest podawany żaden sygnał na wejście. Ma to na celu zapobieganie pojawiania się szpilek i innych śmieci, podczas włączania, wyłączania itp. Rezystory oznaczone Rs na schemacie należą już do dalszej części układu, które już mnie nie interesują z punktu widzenia tej modyfikacji. Zaznaczyłem je jednak na schemacie, ponieważ zostaną one wykorzystane jako rezystory „sumacyjne”, na których będą się „łączyć” sygnały z dwóch wejść – oryginalnego i nowo dodanego.

Modyfikacja

Schemat układów wejściowych po mojej modyfikacji można zobaczyć poniżej:

Jak widać na schemacie, jedyna modyfikacja w oryginalnej płytce polegała na zastąpieniu zworek JP435 i JP346 rezystorami 10k. A następnie dolutowaniu kolejnego identycznego układu wejściowego w pająku i spięcie ich wyjść na rezystorach Rs.

Poniżej kilka fotek całości.

Lista materiałów:

• Rezystory: 4 x 10k, 2x100k
• Kondensatory: 2x 1uF@50v
• Gniazdo jack 3.5mm stereo
• Narzędzia: lutownica, wiertarka, cążki
• Materiały: cyna, kawałek przewodu w izolacji, klej typu SuperGlue

Hardware

Można by powiedzieć że jest on typowy – mikrokontroler, driver max232, karta przekaźników. Mimo wszystko postaram się pokrótce opisać zasadę działania sterownika i części wykonawczej.
Na rysunku poniżej widać schemat części sterownika karty.

Głównym jego elementem jest mikrokontroler AT90S2313 (U1) taktowany kwarcem 10,7 Mhz (Q1, C1, C2). Następnie mamy driver rs232 typu MAX232 wraz z elementami towarzyszącymi C3,C4,C5,C6 którego wyjście jest wyprowadzone na gniazdo DB9 typu męskiego (aby połączyć układ z komputerem należy korzystać z kabla z przeplotem, tzw. Null-modem). Dalej reset mikrokontrolera podciągnięty do plusa zasilania, a port B (piny PB) poprzez rezystory ograniczające prąd (R2-R9) podane na tranzystory sterujące przekaźnikami i diodami LED – T1..T8. Tranzystory te pracują w układzie wspólnego emitera (wzmocnienie prądowe jest większe od jedności). Z kolektorów tych tanzystorów sygnał jest podawany na 8 identycznych bloków przekaźników które wyglądają jak na rysunku poniżej.

Każdy blok składa się z przekaźnika wraz z diodą prostowniczą (na rysunku powyżej D9). Dioda ta służy do wytracenia energii impulsu wyindukowanego w cewce przekaźnika, wytworzonego podczas nagłego przerwania jej zasilania. Oprócz tego, w każdym bloku znajduje się dioda LED (D1) wraz z rezystorem ograniczającym prąd (R10). Styki samego przekaźnika zostały połączone równolegle tak aby zwiększyć dopuszczalny prąd przez nie płynący.

Firmware

Program dla mikrokontrolera został napisany w języku C a skompilowany przy pomocy avr-gcc a następnie wgrany do pamięci układu przy pomocy programatora USBasp.
Procedury odpowiedzialne za komunikację, podobnie jak część sprzętowa, są typowe, można by powiedzieć że książkowe i wyglądają jak poniżej.

#define UART_BAUD 9600 /* serial transmission speed */

void UART_init()
{
UBRR = (unsigned char)UART_CONST; //spped
UCR = _BV(RXEN)|_BV(TXEN); //RXEN - permit recive, TXEN - permit send, RXCIE - interrupt on recive
} // end of UART_init()


Jak widać w fragmencie powyższego kodu, mamy 3 procedurki: UART_init(), UART_putchar() oraz UART_getchar(), które służą kolejno do skonfigurowania, wysłania znaku oraz odebrania znaku. Oprócz tego jest jeszcze jedna ważna stała UART_BAUD która określa prądkość komunikacji i jest ustawiona na 9600.

Procedura UART_init() składa się jedynie z dwóch linijek, w pierwszej przypisywana jest do rejestru UBRR żądana prędkość transmisji, natomiast w drugiej ustawiamy bity RXEN i TXEN rejestru UCR, które odpowiednio uaktywniają nadawanie i odbieranie (jak można wywnioskować z ich nazw RX/TX recive/transmit, EN – enable).
Procedura UART_putchar() przyjmuje jeden parametr, którym jest znak który ma zostać wysłany. Znak ten jest przypisywany do rejestru UDR a następnie wykonywana jest pętla tak długo aż zostanie ustawiony bit TXC w rejestrze USR co oznacza wysłanie znaku.
Procedura UART_getchar() działa podobnie, z tym że tutaj najpierw wykonywana jest pętla tak długo aż zostanie ustawiony bit RXC w rejestrze USR co oznacza nadejście znaku, a następnie ten znak zostaje zwrócony.
Oprócz samej komunikacji został jeszcze w mikrokontrolerze zaprogramowany prosty protokuł, który składa się z dwóch komend. Pierwsza z nich służy do ustawiania stanów na porcie PB (włączania i wyłączania przekaźników) druga do odczytu aktualnego stanu urządzenia.
Poniżej fragment przykładowej sessji w której zostają włączone przekaźniki PK1 oraz PK6, a następnie urządzenie zostaje poproszone o zwrócenie aktualnego stanu.


s10000100sOK
g10000100


Jak widać powyżej, wysyłamy do urządzenia ciąg znaków 0 i 1 (są to znaki nie liczby!) reprezentujące kolejne wyjścia urządzenia i tak kolejno 0 oznacza przekaźnik wyłączony natomiast 1 oznacza przekaźnik włączony. Ponadto ciąg zer i jedynek jest rozpoczęty i zakończony znakiem ‘s’. W odpowiedzi odtrzymujemy 4 znaki kolejno: ‘OK\n\r’ jeśli operacja została wykonana poprawnie, natomiast jeśli coś poszło by nie tak w samym urządzeniu, zwróciło by ono ciąg znaków: ‘Error 2\n\r’ lub ‘Error 3\n\r’.
W następnej linijce powyższego przykładu mamy odczyt aktualnego stanu urządzenia. Wysyłany jest znak ‘g’ natomiast w odpowiedzi otrzymujemy 8 znaków, zer i jedynek, które reprezentują stany kolejnych portów urządzenia.
Reasumując można by powiedzieć że mamy dwie komendy ‘s’ (set) oraz ‘g’ (get). W przypadku gdy do układu zostanie wysłany jakiś inny – niezrozumiały, ciąg znaków zostanie zwrócony ciąg znaków: ‘Error 0\n\r’. Tak mniej więcej wygląda cały protokół komunikacyjny.

Software

Od strony komputer / serwera, zostały przygotowane 3 różne aplikacje, konsolowy program dla środowiska linux, aplikacja okienkowan napisana w Javie/Swing, oraz klasa w php umożliwiająca sterowanie za pośrednictwem interfejsu www – to rozwiązanie jednak wykorzystuje oprogramowanie ser2net jako proxy.

Aplikacja konsolowa dla linux-a

Aplikacja ta umożliwia sterowanie urządzeniem oraz odczytywanie jego stanów z poziomu konsoli. Osobiście wykorzystuję tą aplikację w swoich skryptach cron’a – mam w ten sposób zorganizowany budzik – o odpowiedniej godzinie włącza się wzmacniacz podłączony do karty dźwiękowej domowego serwerka a następnie zostaje odtworzona playlista przy pomocy MPD.
Opcje dostępne w tym programie wyglądają następująco:


$ ./io_card
Usage: ./io_card -p port [-s (8bit data)] [-g] [-1..8 (on|off)]


-p 	ścieżka do portu np. /dev/ttyS0 lub /dev/ttyUSB0 itp.
-s	ustawienie wyjść, jako parametr podajemy odpowiedni ciąg 8 zer i jedynek
-g	pobiera aktualny stan urządzenia, w tym przypadku zwracany jest ciąg 8 zer i jedynek
-1..8	ustawienie lub skasowanie wyjścia od 1 do 8. Jako parametr możemy podać on lub off.

Przykładowo, aby załączyć przekaźniki 4 i 6 możemy wykonać takie polecenie:

$ ./io_card -p /dev/ttyUSB0 -s00010100
OK

lub możemy to zrobić tak:


$ ./io_card -p /dev/ttyUSB0 -4 on -6 on
OK


teraz aby odczytać aktualny stan:


$ ./io_card -p /dev/ttyUSB0 -g
00010100


następnie aby wyłączyć przekaźnik numer 4 i włączyć przekaźniki 1 i 2 możemy wykonać polecenie:


$ ./io_card -p /dev/ttyUSB0 -4 off -1 on -2 on
OK


W załączniku na dole tego artykułu znajduje się spakowany plik zawierający między innymi tą aplikację wraz kodem źródłowym.

ser2net i PHP

Aby skorzystać z klasy napisanej w php należy najpierw zainstalować i skonfigurować program ser2net. Wybrałem taką właśnie metodą komunikacji ponieważ jest ona bardziej uniwersalny, odpowiednio konfigurując ser2net możemy wystawić urządzenie na jakimś adresie zewnętrznym i kontrolować je zdalnie przy pomocy innej aplikacji klienckiej.
I tak, aby zainstalować w ubuntu w/w program, musimy wykonać polecenie:


sudo apt-get install ser2net


Po wykonaniu tego polecenia zostaje ściągnięty a następnie zainstalowany pakiet ser2net, po czym możemy przystąpić do jego konfiguracji.
W pliku /etc/ser2net.conf należy dodać linijkę jak poniżej:


localhost,3000:telnet:600:/dev/ttyUSB0:9600 8DATABITS NONE 1STOPBIT


Możemy ją odczytać jako: wystaw port /dev/ttyUSB0 na porcie 3000 localhost`a, prądkość transmisji to 9600, 8 bitów danych, 1 bit stopu, brak sprzętowej kontroli.
Zmieniając odpowiednio ścieżkę do porty, oraz host i port można dostosować działanie ser2net do własnych potrzeb.
Po zapisaniu pliku musimy zrestartować deamon ser2net, możemy to zrobić przy pomocy poniższego polecenia:


sudo /etc/init.d/ser2net restart


Po tym zabiegu mamy na localhost:3000 zmapowany port /dev/ttyUSB0, możemy zatem przejść do zabawy z php.
W załącznikach na dole artykułu została dodana klasa php IoCart, która udostępnia następujący interfejs:

• IoCart::__construct($strHost, $strPort) – konstruktor, jako parametry podajemy host i port na jakim nasłuchuje ser2net
• IoCart::close() – zamknięcie połączenia
• IoCart::getStatus() – pobieranie aktualnego stanu urządzenia, wartość zwracana to string składający się z 8 znaków – zer i jedynek
• IoCart::checkStatus($intPortNumber) – sprawdzanie aktualnego stanu jednego wybranego porty – $intPorNumber, wartość zwracana to odpowiednio boolowskie true lub false
• IoCart::setPort($intPort, $bolState) – ustawienie jednego wybranego portu, $intPort – numer portu od 1 do 8, $bolState – wartość boolowska oznaczająca włączony lub wyłączony dany port
• IoCart::set($strByte) – ustawienie wszystkich portów naraz, jako parametr przyjmuje odpowiedni ciąg zer i jedynek, reprezentujący zadane stany kolejnych przekaźników.

Poniżej zrzut ekranu oraz kod przykładowego działającego skryptu (również dołączony do pczaki zip).



<?php 
 include "IoCart.php";
 $objCard = new IoCart('localhost',3000);

Aplikacja okienkowa

No i na koniec mały smaczek, aplikacja okienkowa w javie. Skompilowana również dostępna w załączniku.

Jak już prędzej wspominałem jest ona oparta na javie/swingu, oraz wykorzystuje do komunikacji bibliotekę RXTXcomm. Biblioteka ta jest również dołączona w pliku zip w katalogu lib. Jest to wersja .so jak i dll, niestety nie testowałem działania tego programu pod windowsem, jednak powinien on działać poprawnie

Nie dołączam pełnych źródeł tej aplikacji ponieważ oprócz klasy SerialHandler cała reszta to w zasadzie interfejs graficzny, który każdy kto zna choć trochę jave może sobie napisać (wyklikać) według własnego uznania i dostosowany do własnych potrzeb.

Uwagi końcowe

Oczywiście w tym całym mini-projekcie jest kilka mniejszych lub większych mankamentów lub wręcz błędów projektowych, których jestem świadomy (jak np. Nie najlepiej zaprojektowane pcb, brak kondensatorów filtrujących, brak układu resetu), samo oprogramowanie na PC również jest napisane na szybko i byle jak. Całość jednak działa i spełnia swoją rolę.

Jeśli ktoś był by zainteresowany zakupem całego układu w postaci kit`u (lub zmontowanego układu) lub chciał uzyskać dodatkowe informację lub pomoc podczas uruchomienia, zapraszam do kontaktu

Załączniki

• main.hex – wsad do konktrolera
• board_v2.ps – Płytka drukowana (PostScript)
• board_v2_mirror.ps – Płytka drukowana – odbicie lustrzane (PostScript)
• IO_Karta.zip – załącznik z wszystkimi plikami, wzorem pcb, schematem oraz aplikacjami klienckimi i wsadu.

Galeria