Fun with Fan part 2

Hardware poskładany, czas przysporzyć trochę problemów software'owcom.

Nasz program powinien przyspieszyć obroty wiatraczka w momencie, gdy temperatura wzrośnie ponad zdefiniowane maksimum i wrócić do jałowych obrotów w momencie, gdy spadnie poniżej założonego minimum. Proste. Zatem do dzieła.

Zdefiniujmy nasze wartości graniczne:

	double minTemperature = 23.5;
	double maxTemperature = 24.6875;

view raw minmax.c hosted with ❤ by GitHub

Oraz zdefiniujmy graniczne obroty wentylatora. Operujemy na 8-bitowym timerze w ramach naszego PWM, zatem maksymalną prędkość określimy na 255, minimalną na 80 - wartość dobrana eksperymentalnie - możnaby się też pokusić o wyliczenia... 80 jest spoko.

	uint8_t maxFanSpeed = 255;
	uint8_t minFanSpeed = 80;
	uint8_t fanSpeed = minFanSpeed;

view raw fanParameters.c hosted with ❤ by GitHub

Teraz konfiguracja PWM i termometru (podłączamy go jak ostatnio). Włączamy przerwania.

	// Fast PWM mode
	TCCR0 |= (1 << WGM01) | (1 << WGM00);
	// OC0 enabled, clear on match
	TCCR0 |= (1 << COM01) | (1 << COM00);
	// timer0 clock source prescaler
	TCCR0 |= (1 << CS00);
	// pin OC0 as output
	DDRB |= (1 << PB0);
	STRONG_PULL_UP_DDR |= (1 << STRONG_PULL_UP_PIN);
	// initialize interrupts
	sei();

view raw pwm-ds-config.c hosted with ❤ by GitHub

W nieskończonej pętli będziemy odczytywać temperaturę, modyfikować prędkość wentylatora, a następnie odpowiadającą jej wartość wpisywać do rejestru OCR0. Skomplikowane działanie odejmowania wymuszone jest konfiguracją PWM (clear on match). Odwracając logikę konfiguracji możemy pozbyć się odejmowania. Zostawiam tak, jako przykład akademicki ;)

	while(1)
	{
	PORTC &= ~(1 << 1);
	ReadTemperature();
	if (temperature < minTemperature && fanSpeed > minFanSpeed)
	{
	fanSpeed -= 1;
	}
	else if (temperature > maxTemperature && fanSpeed < maxFanSpeed - 20)
	{
	fanSpeed += 1;
	}
	OCR0 = 255 - fanSpeed;
	_delay_ms(500);
	}

view raw main.c hosted with ❤ by GitHub

I tyle - teraz tylko testować, dobierać parametry i na produkcję!

PS kodzik jak zwykle na githubie.

Fun with Fan

Kodzik jest jak klocki LEGO

PWM - temat tak wdzięczny, że postanowiłem poświęcić mu jeszcze kilka postów. Wprowadzając pojęcie PWM do moich rzeczybezinternetu wspomniałem, jak można go wykorzystać do niecnych celów. Teraz, gdy już mamy wiedzę na temat podpinania termometru do naszej Atmegi, możemy zacząć składać klocki w większe... budowle.

Masz problem?!

Zatem znajdźmy sobie problem. Potrzebne będą: temperatura, sterowanie napięciem zasilania, urządzenie mogące być sterowane zasilaniem. Przykładowy problem - przegrzewający się mikrokontroler. Możemy mierzyć jego temperaturę, a w momencie, gdy ta przekroczy założoną granicę - możemy ochłodzić nieco atmosferę. Zatem do dzieła!

Analiza

Do chłodzenia całego układu posłuży nam wiatraczek wymontowany ze starego komputera - zasilany stałym napięciem 12V - można go nabyć w każdym sklepie z wiatraczkami (czy wentylatorami) - w tym przypadki wiatraczek jest odpowiednim słowem. I tu pojawia się pierwszy problem - jak wysterować urządzenie zasilane 12V z naszej Atmegi, gdzie możemu liczyć na 5V max, przy ograniczonym prądzie. Rozwiązań jest wiele. Zaprezentuję 2. Oba będą zawierać pewien rodzaj izolacji galwanicznej - o tej też już na pewno wiesz!

Część wspólna

Zacznijmy od skonfigurowania PWM. Posłużmy się posiadaną wiedzą:

	// Fast PWM mode
	TCCR0 |= (1 << WGM01) | (1 << WGM00);
	// OC0 enabled, clear on match
	TCCR0 |= (1 << COM01) | (1 << COM00);
	// timer0 clock source prescaler
	TCCR0 |= (1 << CS00);
	// pin OC0 as output
	DDRB |= (1 << PB0);

view raw FunWithFan.c hosted with ❤ by GitHub

Termometr

Potrzebny nam będzie element sterujący PWM. Nie będziemy przecież stać z termometrem nad mikrokontrolerem i zmieniać prędkości wentylatora. Podepnijmy nasz pasożytniczy DS1820PAR i wykorzystajmy wcześniejszy kodzik do odczytu temperatury

Podłączenie LED do wyjścia PB0 (OC0) i zmiana wartości wpisywanej do rejestru OCR0 powodowała jej przygaszanie lub rozjaśnianie. Możemy wnioskować, że w czasie zmieniało się napięcie. Zamieńmy teraz diodę na wentylatorek. Brakuje nam dobrych 7V, żeby kręcić nim na pełnych obrotach, a 12V nasza Atmega nie wytrzyma - czas na izolację

Transoptor

Zadziała? Zadziała. Ale bez szaleństw. Transoptor stanie się częścią obwodu. Napięcie, które powinno odłożyć się na wentylatorze (wpływając na jego prędkość), odłoży nam się również na tranzystorze transoptora, a prąd płynący przez układ sprawi, że wspomniany tranzystor zacznie się grzać. Nie rozwiążemy pierwszego problemu, a na domiar złego stworzymy sobie nowy.

Tranzystor MOSFET

I to nie byle jaki - a tranzystor Mocy! 4 maja już niebawem, a wszyscy wiemy, że Mocy nie należy lekceważyć... W odróżnieniu od opisywanych wcześniej tranzystorów bipolarnych - nóżki tego tranzystora posiadają inne nazwy: gate, drain i source. Wiedza potrzebna na teraz: do bramy możemy doprowadzić wyjście PWM, source połączmy z masą, a między drain i napięcie zasilania wepnijmy wentylatorek.

Dlaczego możemy połączyć Atmegę w ten sposób? Ze względu na budowę tranzystora. I dane zamieszczone w nocie katalogowej. Z niej dowiemy się również, że nasze 5V może nie wystarczyć, by rozkręcić wentylatorek na maxa - aczkolwiek prędkość, jaką osiągnie powinna w zupełności wystarczyć.

Pozostaje tylko dodać trochę logiki biznesowej...

Daj się poznać lvl fotografia

Nie działa i nie wiadomo dlaczego

Projekty elektroniczne mają to do siebie, że nie wszystko działa tak, jakbyśmy tego oczekiwali... A na koniec okazuje się, że cały czas krążyliśmy wokół rozwiązania. Na takie krążenie natknąłem się i ja... Obecnie walczę z uruchomieniem silnika krokowego. Jako że rezultaty nie są najciekawsze pod względem ekhm działania, dziś mniej techniczny post!

Daj się poznać lvl fotografia

Czymże jest wspominane tyle razy moje środowisko deweloperskie - ano mniej więcej czymś takim.

Na zdjęciu od góry:

• część dolna ściągi z datasheetu (wyprowadzenia Atmegi)
• płytka stykowa
• moduł zasilający (mam dostępne 3.3V i 5V DC dzięki niemu!)
• złącze programatora (JTAG ofc!)
• żółta i czerwona LED
• Atmega162, 
• Przycisk (wpięty do przerwania)
• Po lewej moduł bluetooth na płytce z mojego projektu inżynierskiego
• Moduł Fibocom G510
• Termometr (między modułami GSM i Bluetooth)
• Programator AVR Dragon

Wyślij SMS o treści...

Wyrównujemy szanse

Dodajmy kolejną możliwość do naszej komunikacyjnej piaskownicy. Za pośrednictwem modułu jesteśmy w stanie przekazać wiadomość SMS do Atmegi. Wyrównajmy szanse - niech teraz Atmega będzie w stanie wysłać SMSa do nas.

W tym celu musimy skonfigurować połączenie z modułem GSM jak poprzednio. Uruchomić moduł, odczekać 15 sekund potrzebne na zalogowanie się do sieci i wysłać - niespodzianka - sekwencję komend AT, które sprawią, że przez sieć GSM poleci SMS od Atmegi wprost do telefonu o wskazanym przez nas numerze telefonu - najlepiej, żeby był to nasz telefon - przynajmniej będziemy wiedzieć, że działa, a karta SIM włożona do modułu GSM nie posłuży nam do wysyłania niechcianych wiadomości do losowych ludzi...

Procedura wysyłania SMSa

Ustalamy tryb tekstowy

AT+CMGF=1

Po otrzymaniu informacji

OK

Podajemy numer telefonu odbiorcy

AT+CMGS=000000000 lub AT+CMGS=+48000000000

Następnie oczekujemy na znak zachęty:

>

Zachęceni podajemy treść SMSa:

Daj sie poznac!

Koniec treści SMSa komunikujemy kombinacją Ctrl+Z... czyli za pomocą kombinacji:

\x1A

Możemy jeszcze zaczekać na potwierdzenie nadania wiadomości

+CMGS: ...

Po otrzymaniu tak rozpoczynającego się ciągu znaków, możemy uznać, że SMS został wysłany - nasz trud skończony.

W optymistycznym przypadku...

...nie będziemy musieli się martwić o nieprzewidziane sytuacje. Jednak warto być świadomym, że każda nasza komenda może zostać niezrozumiana przez moduł GSM, o czym w najlepszym przypadku poinformuje nas pięknym komunikatem ERROR, który przyjdzie do nas zamiast oczekiwanej wiadomości pozytywnej. Dlatego komunikując się z modułem GSM za pomocą komend AT warto określać stan aplikacji - będzie o wiele łatwiej zarządzać kodzikiem i decydować, co w danym momencie powinniśmy zrobić - będziemy mieć informację na temat stanu, w jakim się aktualnie znajdujemy i wiadomości, jaka aktualnie przyszła - sporo wiedzy - warto ją spożytkować w należyty sposób - nie zawsze mamy aż tyle informacji o stanie systemu...

Kodzik
Aby wysłać SMS o treści podanej w kodzie programu powinniśmy wprowadzić aplikację w stan "GSM_Init". W celu odebrania SMSa od modułu GSM, wprowadzamy aplikację w stan "SMS_ReadInit". Zmiana stanu aplikacji może nastąpić na przykład pod wpływem odczytu określonej temperatury (jeżeli podepniemy do układu termometr) lub pod wpływem przerwania wywołanego przez zwarcie lub rozwarcie zewnętrznego układu - kiedy dokładnie - zostawiam Tobie!

- SMS Przyszedł! - Czego chce?

Połączenie

Uruchomienie modułu to dopiero początek. Teraz musimy się z nim dogadać. Na chwilę obecną Fibocom G510 jest połączony z mikrokontrolerem jedynie linią POWER_ON. Do pełni szczęścia potrzebne nam jest jeszcze połączenie USART - 2 kolejne linie. Zatem standardowo - łączymy linię RxD modułu z linią TxD mikrokontrolera, a linię TxD modułu z linią RxD mikrokontrolera. Jak pamiętamy z posta o USART, potrzebna jest też znajomość parametrów transmisji. Domyślnie port UART1 modułu G510 skonfigurowany jest następująco:

• 8 data bits
• 1 stop bit
• no parity
• none flow control
• auto baud rate detect 

Ta ostatnia opcja jest o tyle ciekawa, że to my możemy zdecydować, z jaką prędkością odbywać się będzie nasza komunikacja. Osobiście wybrałem 115200 bps. Radośnie zakładam, że karta SIM jest już na swoim miejscu, a moduł znajduje się tam, gdzie jest zasięg sieci, do której będzie próbował się logować.

Wait a minute...

Połączenie utworzone, czas włączyć moduł i wyciągnąć z niego interesujące nas informacje. Na dzień dobry musimy uzbroić się w ok. 15 sekund cierpliwości - w tym czasie moduł powinien zalogować się do sieci. Sukces tego procesu zostanie oznajmiony poprzez zmianę częstotliwości migania diody podpiętej do linii LPG. To opóźnienie nie jest wymagane w momencie odczytu SMSów obecnych na karcie SIM, aczkolwiek myślę, że warto o nim wspomnieć - choćby po to, by zapamiętać na przyszłość - kiedy to zasięg sieci będzie krokiem wymaganym (choćby po to, by odebrać tego pierwszego SMSa :))

Porozmawiajmy!

G510 komunikuje się z nami za pośrednictwem komend AT. W celu sprawdzenia komunikacji, powinniśmy wysłać do modułu proste "AT" i oczekiwać czegoś w rodzaju "OK" lub "AT OK" - w zależności, czy moduł ma włączone echo, czy nie. Echo może się przydać do kontroli wysyłanych wiadomości - tj. przetwarzając odpowiedź, najpierw sprawdzamy, czy zapytanie, na które odpowiada to to samo, na które oczekujemy. Oprócz tego w ten sposób można sprawdzić poprawność konfiguracji połączenia. Przy pomocy komend AT opisanych w odrębnym dokumencie możemy dowiedzieć się wielu ciekawych rzeczy o stanie modułu. Skupmy się jednak na tych, które pozwolą nam "odebrać SMSa".

Odczyt SMSa z karty SIM

Na początek ustawmy format wiadomości - interesuje nas tekst. zatem:

AT+CMGF=1

oczekujemy odpowiedzi

OK

Następnie wskazujemy, skąd chcemy odczytać SMSa

AT+CPMS="SM"

w odpowiedzi uzyskamy informację zaczynającą się od

+CPMS ...

Teraz właściwe żądanie odczytu SMSa. Do tego celu potrzebujemy id interesującej nas wiadomości. Załóżmy, że przed nadejściem naszego SMSa karta była pusta, zatem chcąc odczytać pierwszą wiadomość:

AT+CMGR=1 lub AT+MMGR=1

Różnica między tymi komendami jest taka, że ta pierwsza zmienia status wiadomości na karcie - tj. ze statusu "REC UNREAD" (otrzymana nieprzeczytana) na status "REC READ" (otrzymana przeczytana). W odpowiedzi otrzymamy strukturę zawierającą informację na temat otrzymanego SMSa (w zależności od parametru ustawionego komendą AT+CSDH) - m. in. numer, z jakiego został wysłany, czas otrzymania i w końcu - treść SMSa.

+CMGR ...

Do nas należy decyzja, co zrobimy z otrzymanymi danymi. Wypadałoby wyłuskać treść SMSa. Co może nieść ze sobą ta treść? Na przykład informację o tym, że powinniśmy włączyć którąś diodę podpiętą do mikrokontrolera albo załączyć przekaźnik, który załączy nam ogrzewanie w domu albo... co tylko sobie wymyślisz :)

Chcąc wykorzystać bardziej informacje zawarte w komendzie zwrotnej +CMGR - powinniśmy pokusić się o utworzenie struktury danych, która przechowa nam to, co dla nas ważne.

Po odczytaniu SMSa możemy go usunąć z karty SIM komendą:

AT+CMGD=1

Która usunie nam wiadomość o identyfikatorze 1 (czyli tą, którą przed chwilą odczytaliśmy). Spodziewamy się odpowiedzi:

OK

Usuwanie SMSów zaraz po ich przetworzeniu odejmuje nam jeden problem - karta SIM nie zapełni się zbyt szybko i nasz układ będzie "responsywny". Od konkretnego problemu zależy, czy będziemy chcieli trzymać SMSy na karcie SIM i jak długo... Jednakowoż uważam, że istnieją lepsze sposoby archiwizacji danych, niż trzymanie ich na karcie SIM.

SMS Init

Żenujący żart prowadzącego

Znamy już podstawy teoretyczne współpracy z modułem GSM Fibocom G510, pora na odrobinę praktyki. Btw. znacie różnicę między teorią a praktyką? Teoria jest wtedy, gdy wszystko wiemy, ale nic nie działa. Praktyka - wszystko działa, ale nikt nie wie dlaczego. Jest jeszcze ciąg dalszy dotyczący politechniki - tam łączy się teoria z praktyką - nic nie działa i nikt nie wie dlaczego...

Wróćmy do tematu

Nasz moduł GSM nie jest typowym urządzeniem typu "daj mi zasilanie, a pozwolę Ci ze mną rozmawiać". Żeby moduł pozostał włączony po dostarczeniu zasilania, musimy mu to jednoznacznie określić. W tym celu na pin POWER_ON modułu musimy podać stan niski przez okres co najmniej 800 milisekund - jak niski sygnał pozostanie tam ciut dłużej - nic złego się nie stanie - dla pewności, wystawię 0 na czas 1 sekundy.

Co się stanie, gdy czas trwania sygnału niskiego będzie za krótki? To zadziała trochę jak odpalanie zimnego silnika motocykla bez ssania - trochę popracuje i zgaśnie... Zatem na moment zobaczymy, że nasz moduł żyje, by potem znów obserwować smutne zgaszone diody

Jak możemy zrealizować włączanie? Na przykład podpinając tę nóżkę na stałe do masy - w momencie pojawienia się napięcia zasilania w układzie, po upływie niecałej sekundy nasz moduł zacznie się budzić do życia (logować do sieci GSM). Nuda. Skoro dostajemy możliwość sterowania stanem modułu, dlaczego tego nie wykorzystać? Wystarczy poświęcić jedną linię sygnałową mikrokontrolera (pin) i podpiąć bezpośrednio do modułu (jeżeli zapewnimy kompatybilność napięć) lub wykorzystać tranzystor albo pójść drogą super bezpiecznej izolacji galwanicznej - transoptor. W swoim mikrokontrolerze poświęciłem linię PC7 - to ona będzie odpowiedzialna za włączanie i wyłączanie modułu GSM.

Kodzik

	void TurnFibocomOn(void)
	{
	PORTC |= (1<<PC7);
	_delay_ms(200);
	PORTC &= ~(1<<PC7);
	_delay_ms(1000);
	PORTC |= (1<<PC7);
	}
	int main(void)
	{
	TurnFibocomOn();
	while (1)
	{
	}
	}

view raw GSMInit.c hosted with ❤ by GitHub

GSM Fibocom G510

What's next?

Ograniczenia wynikające z utrzymaniem połączenia z mikrokontrolerem za pośrednictwem modułu Bluetooth zmuszą nas prędzej czy później do rozważenia rozwiązania o większym zasięgu. Skoro producenci telefonów komórkowych potrafią jakoś podpiąć kartę SIM do obecnego w telefonie mikrokontrolera, dlaczego my nie moglibyśmy zrobić tego samego? Bezpośrednie łączenie pól karty SIM z Atmegą nie jest najlepszym pomysłem - zastosujmy do tego interfejs!

GSM

Moduł GSM Fibocom G510 jest takim właśnie interfejsem. Z jednej strony podpinamy go do Atmegi (USART - a jakże!), z drugiej strony - montujemy antenę i wkładamy kartę SIM (przed włożeniem karty do slotu warto wyłączyć blokadę SIM - korzystając z telefonu komórkowego). Po podłączeniu do prądu nasza karta powinna się zalogować w sieci - tym samym umożliwić nam komunikację z naszym układem wszędzie tam, gdzie jest zasięg.

Możliwości są ograniczone tylko naszą wyobraźnią. 

Moduł możemy wykorzystać do nawiązywania połączeń, wysyłania SMSów, korzystania z transmisji danych - nasze Rzeczy mogą uzyskać dostęp do Internetu - a Internet... do nich. Zanim jednak przejdziemy do rozmowy z modułem - zobaczmy, w jaki sposób możemy się z nim porozumieć...

Zasilanie

Sięgnijmy po raz kolejny do datasheetu. I tu niestety porażka (przynajmniej w moim przypadku). Producent podaje przedział napięcia od 3.3V do ok. 4V. Podpowiem - na 3.3 nie ma szans - moduł owszem - uruchomi się, ale nie zaloguje się do sieci. Musimy dostarczyć mu rekomendowane przez producenta 4.0-4.1V, co może skutkować pewną akrobatyką, jeżeli chodzi o sposób, w jaki takie zasilanie dostarczymy do układu. Możemy bawić się w konwertery napięcia - by Atmega zasilana napięciem 3.3V była w stanie "dogadać się" z modułem, ale to tylko zwiększa koszt rozwiązania. Warto pomyśleć nad układem, który pracuje na wspólnym napięciu. W tym celu powinniśmy wykorzystać "konfigurowalny" stabilizator napięcia, albo posłużyć się prawami fizyki i wymusić spadek napięcia przed wejściem do układu.
Warto też zwrócić uwagę, że w celu uruchomienia modułu musimy podać stan niski na wejście POWER_ON. Więc zanim zaczniecie panikować, że układ nie działa, upewnijcie się, że takowy stan występuje. Ma to swoje zalety - możemy wyłączać moduł, by oszczędzać energię.

LPG

LED - najprostszy "Hello World" w elektronicznym świecie.

Sugerowany przez producenta sposób podpięcia diody do sygnału LPG (źródło: dokumentacja)

Moduł posiada wyprowadzenie LPG - warto podpiąć do niego diodę, gdyż jest to pierwsza linia sygnałowa, która podpowie nam, w jakim stanie znajduje się obecnie moduł. Sygnał ten możemy poprowadzić też bezpośrednio do naszego mikrokontrolera, by już na poziomie kodu móc śledzić stan modułu. O czym nam opowie sygnał LPG? Sięgnijmy do noty katalogowej.

Stan modułu sygnalizowany przez diodę podpiętą do sygnału LPG (źródło: dokumentacja)

USART

Na pokładzie modułu znajdują się 3 układy USART. Ciekawostką jest fakt, że jeden z nich można wykorzystać do programowania samego modułu. Producent na egzemplarzach oznaczonych OPEN CPU zaimplementował możliwość wgrania swojego małego programu. Na potrzeby niewielkich projektów - mega feature! Skupmy się jednak na komunikacji... A ta przebiega standardowo - musimy skrzyżować linie RxD i TxD modułu z odpowiadającymi liniami mikrokontrolera.

Język

Jak większość modułów tego typu i w tym przypadku do komunikacji wykorzystamy modemowe komendy tekstowe AT. Lista obsługiwanych komend i przykładowe "procedury" - tj. określona kolejność ich wysyłania, w celu uzyskania konkretnego skutku - znajdziemy w dokumentacji. W kolejnych postach opiszę sposób obsługi SMSów (wysyłanie i odbieranie).

Im łatwiej tym lepiej

Moduł możemy zakupić "nagi" - tj. gotowy do lutowania powierzchniowego - jednak na potrzeby prototypowania i niejako zabawy :) warto dorzucić kilka złotych i zakupić układ z wlutowanymi niezbędnymi do prawidłowego działania elementami (gniazdem antenowym, stabilizatorem napięcia, slotem na kartę SIM) z wyprowadzeniami USART na goldpinach. Jak już przyjdzie "co do czego" - zaprojektujemy własny układ i poprowadzimy wszystkie wymagane sygnały.

W oczekiwaniu na podłączenie do zasialnia...

Ważna linia cd.(DS1822-PAR)

Po co mi ta wiedza?

Swego czasu stałem się szczęśliwym posiadaczem czujnika temperatury DS1822-PAR. Czujnik ten jest o tyle ciekawy, że wg noty katalogowej posiada tylko 2 nóżki, do których możemy cokolwiek podpiąć: nóżkę danych (1-Wire) i nóżkę masy (GND). A zasilanie?! No właśnie - i tu jest moc, siła i potęga tego czujnika. Końcówka PAR pochodzi od angielskiego parasite (pasożyt) i nie jest to wcale przesadzone - czujnik czerpie zasilanie z linii danych - wiedzie na niej pasożytnicze życie - jak jemioła na drzewach na przykład...

Co to oznacza dla konstruktora-programisty?

Nie mniej - nie więcej tyle, że trzeba to zasilanie czujnikowi dostarczyć - w przeciwnym wypadku, niczego ciekawego się od niego nie dowiemy - a zwłaszcza, jaka temperatura panuje w naszym otoczeniu. To od czego zacząć? Jak zwykle - od czytania dokumentacji.

Sposób podpięcia czujnika do mikrokontrolera (źródło: datasheet)

Jak widać - w tym przypadku określenie 1-Wire jest pewnym niedomówieniem :) warto jednak pamiętać, że 1-Wire określa tylko ilość linii, jaka jest wykorzystywana do przesyłania danych. Korzystając z pasożytniczego czujnika będziemy potrzebować jeszcze jednego pinu mikrokontrolera, który będzie sterował tranzystorem dostarczającym zasilanie na linię danych.

Najlepszą dokumentacją jest kodzik!

Podłączyliśmy termometr do linii danych, czas te dane z niego wyciągnąć! Bit po bicie... Nasz mikrokontroler będzie działał jako master w tym tandemie, w związku z tym potrzebna mu będzie wiedza, jak wysłać sygnał reset na magistralę:

	void OneWireReset(void)
	{
	CLR_DQ; // stan niski na linii 1wire
	_delay_us(480); // opoznienie ok 480us
	SET_DQ;// stan wysoki na linii 1wire
	_delay_us(480); // opoznienie ok 480 us
	}

view raw OneWireReset.c hosted with ❤ by GitHub

Kolejnym krokiem - odebranie pojedynczego bitu z magistrali:

	uint8_t OneWireReadBit(void)
	{
	CLR_DQ; // stan niski na linii 1Wire
	_delay_us(3); // opoznienie 3us
	SET_DQ; // stan wysoki na linii 1Wire
	_delay_us(15); // opoznienie 15us
	if(IN_DQ)
	{
	return 1;
	}
	else
	{
	return 0; // testowanie linii, funkcja zwraca stan
	}
	}

view raw OneWireReadBit.c hosted with ❤ by GitHub

Zatem chcąc odebrać bajt:

	uint8_t OneWireReadByte(void)
	{
	uint8_t i; // iterator petli
	uint8_t value = 0; // odczytany bajt
	for (i=0;i<8;i++)
	{
	// odczyt 8 bitów z magistrali DQ
	if(OneWireReadBit())
	{
	value|=0x01<<i;
	}
	_delay_us(9); // opoznienie 9us
	}
	return(value);
	}

view raw OneWireReadByte.c hosted with ❤ by GitHub

Jak już potrafimy odczytać, nauczmy się wysyłać:

	void OneWireWriteBit(uint8_t bit)
	{
	CLR_DQ; // stan niski na linii 1wire
	_delay_us(10); // opoznienie 10us
	if(bit)
	{
	SET_DQ; // jezeli parametr jest niezerowy to ustaw stan wysoki na linii
	}
	_delay_us(100); // opoznienie 100us
	SET_DQ; // stan wysoki na linii 1wire
	}

view raw OneWireWriteBit.c hosted with ❤ by GitHub

I znowu - bajt:

	void OneWireWriteByte(uint8_t val)
	{
	uint8_t i; // iterator petli
	uint8_t temp;
	for (i=0; i<8; i++)
	{
	// wyslanie 8 bitów na magistrale 1-Wire
	temp = val >> i;
	temp &= 0x01;
	OneWireWriteBit(temp);
	}
	_delay_us(9);
	}

view raw OneWireWriteByte.c hosted with ❤ by GitHub

To jaka jest temperatura otoczenia?

Teraz wystarczy tylko poprosić termometr o podanie temperatury. W tym celu będziemy musieli wysłać mu kilka komend - 0xCC (skip ROM), 0x44 (convert T) oraz 0xBE (read Scratchpad). Szczegółowy opis znajdziecie w dokumentacji. Tam też znajdziecie tabelki z tajemną wiedzą na temat kolejności wysyłania poszczególnych komend. A jak to będzie wyglądać w naszym przypadku?

	void ReadTemperature(){
	uint8_t i;
	double temperature=0.0;
	uint8_t str[17]=" ";
	uint8_t scratchpad[9];
	/*
	stratchpad[]:
	0 - lsb
	1 - msb
	2 - T_{h} register
	3 - T_{l} register
	4 - configuartion register
	5 - reserved
	6 - reserved
	7 - reserved
	8 - crc
	*/
	STRONG_PULL_UP_OFF;
	OneWireReset(); // reset 1-Wire
	OneWireWriteByte(0xCC); // komenda skip ROM
	OneWireWriteByte(0x44); // komenda convertT
	STRONG_PULL_UP_ON;
	_delay_ms(750); // delay 750ms
	STRONG_PULL_UP_OFF;
	OneWireReset(); // reset 1Wire
	OneWireWriteByte(0xCC); // komenda skip ROM
	OneWireWriteByte(0xBE); // komenda read Scratchpad
	for(i=0; i<9; i++)
	{
	scratchpad[i] = OneWireReadByte();
	}
	uint16_t buffer = scratchpad[0];
	buffer |= (scratchpad[1] << 8);
	temperature = (double)(buffer / 16.0);
	dtostrf(temperature, 0,4, str); // konwersja do napisu
	str[15] = '\r';
	str[16] = '\n';
	UsartWrite(str); // wyslanie temperatury
	}

view raw ReadTemperature.c hosted with ❤ by GitHub

Dane pochodzące z termometru pochodzą z 'brudnopisu' (scratchpad) czujnika. Temperatura zapisana jest na 2 bajtach. W celu wyliczenia prawidłowej wartości, musimy dokonać małej arytmetyki na tych wartościach - ponownie posługując się wiedzą z dokumentacji.

Sposób przechowywania temperatury przez czujnik. Źródło: datasheet.

Zatem co musimy zrobić? Wziąć MS Byte, przesunąć go bitowo o 8 miejsc w prawo, zapisać do 16 bitowej zmiennej, do tego dopisać LS Byte i podzielić całość przez 16 (ujemne potęgi 2 na najmłodszych bitach LS Byte -> 2^4 = 16).

I po co to wszystko?

A z otrzymaną wartością temperatury możemy zrobić, co tylko chcemy - na przykład wysłać ją za pośrednictwem USART do innego urządzenia, a uzyskane dane przedstawić na wykresie:

Na wykresie zaznaczone są pomiary temperatury odnotowane podczas "złapania" czujnika DS1822-PAR w 2 palce (między kciuk a wskazujący). Czujnik złapałem w 21 sekundzie eksperymentu, puściłem w 49. Z wykresu wynika, że czujnik szybciej reaguje na wzrost temperatury niż na jej spadek - posiada pewną bezwładność. Całość dostępna oczywiście na githubie.

Ważna Linia

USART to potężne narzędzie i daje nam naprawdę duże możliwości komunikacji. Jak łatwo się domyślić, nie wszystkie urządzenia implementują ten standard - głównie dlatego, że wymaga zbyt wiele miejsca na elektronikę, która byłaby odpowiedzialna za komunikację. Na szczęście istnieją prostsze i mniej wymagające sposoby 'dogadania się' z elementami z zewnątrz mikrokontrolera.

Tniemy koszty

USART do prawidłowego działania wymagał co najmniej 3 linii - 2 sygnałowych i jednej linii odniesienia. Jak uprościć ten schemat? Wyrzućmy jedną linię! Proste. Zostawmy linię odniesienia - nadal musi istnieć wspólne 'źródło prawdy' (kiedy jest 0), a 2 linie sygnałowe zastąpmy 1. Czyli zamiast używania uszu i ust do komunikacji, używamy aparatu, który będzie jednym i drugim... na zmianę. Pamiętacie z dzieciństwa zabawę z kubkami i sznurkiem? Nawet nie wiedzieliście, że korzystacie z rozwiązania 1-Wire - opisanego np. w nocie katalogowej jednego z najbardziej popularnych termometrów wśród miłośników domowej automatyzacji.

Jakoś się dogadamy...

Podobnie jak w przypadku USART, potrzebny jest protokół. Mamy do dyspozycji 1 linię, która w danym momencie może być:
wyjściem w stanie wysokim
wyjściem w stanie niskim
wejściem
i jeszcze ten 'dany moment' - czyli urządzenia połączone ze sobą mają pojęcie o czasie! To już coś.

Jak rozmawiamy? Wiadomo - zera i jedynki układające się w bajty, a bajt to już liczba albo znak - a to już potrafimy wysłać przez USART do innego urządzenia...  Ale po kolei.

Cała komunikacja polega na nasłuchiwaniu, w jakim stanie znajduje się magistrala lub naduszaniu na nią 'swojej woli'. I tak chcąc wysłać bit, urządzenie powinno wystawić stan niski na linii, następnie po czasie 10 us wystawić stan wysoki, jeśli chce wysłać 1, a następnie - w obu przypadkach - odczekać 100us, następnie znów wystawić stan wysoki na linii.

Chcąc odczytać bit, urządzenie powinno na 2us zmienić kierunek swojego portu komunikacyjnego, następnie po 15us sprawdzić stan linii.

8 bitów to bajt!

Skoro wiemy jak odczytać i nadać bit - odczytajmy i nadajmy bajt! - ośmiokrotnie wywołując funkcje dotyczące bitów, dbając o to, żeby dostarczać kolejne bity w przypadku nadawania i zapisywać w przypadku odbierania.

1 mówi, reszta słucha

Wiemy jak korzystać z linii, ale skąd możemy mieć pewność, że nikt inny akurat z tej linii nie korzysta? Standard przewiduje także procedurę resetu. Polega ona na wprowadzeniu magistrali w stan niski na 480us, następnie 480us w stanie wysokim. Magistrali? Tak magistrali! 1-Wire to magistrala! Możemy do niej wpiąć wiele urządzeń - każde z nich będzie miało swój własny adres i możliwa będzie komunikacja - przeważnie typu master-slave. Np. mikrokontroler jako master odpytywać będzie czujniki temperatury DS1822 działające w trybie slave - w ten sposób zbierze dane z całego domu, przetworzy je i wyśle do centralnego serwera, który w niecny sposób wykorzysta tę tajemną wiedzę (i na przykład podkręci ogrzewanie...).

A gdzie kodzik!?

Czeka na porządne przetestowanie na moim dev-środowisku na biurku :)