Rozwiązania oparte na układach cyfrowych małej skali integracji :: Mikrokontrolery AVR :: Komunikacja poprzez RS485

Ewolucja koncepcji projektów inteligentnego domu

Artykuł ma na celu prezentację rozwoju prezentowanych w serwisie projektów związanych z tzw. inteligentnym domem, czyli różnego rodzaju układów sterowania i automatyki domowej, a także przybliżyć interesujące z jakiś względów rozwiązania, które nie znalazły miejsca w aktualnych projektach.

Rozwiązania oparte na układach cyfrowych małej skali integracji

Pierwszym z projektów automatyki domowej był impulsowy sterownik oświetlenia w oparciu o układy cyfrowe serii 74 (TTL) oraz przekaźniki bistabilne. Umożliwiał on także zastosowanie zwykłych przekaźników (po wyeliminowaniu części układu odpowiedzialnego za impulsowość sterowania. Głównym problemem takiej realizacji było to iż układ wymagałaby użycia wielu elementów (dla sterownika 6-cio kanałowego: 6x NE555, 3x 4747, 3x 4708 oraz wiele elementów biernych) a co za tym idzie rozbudowanego i zajmującego sporo miejsca PCB. Zamieszczam tutaj powstały wtedy projekt takiego sterownika, jednak należy pamiętać że projekt nigdy nie doczekał się realizacji czy nawet testów, więc ma prawo nie działać.

POWIĘKSZ

Mikrokontrolery AVR

Celem zmniejszenia rozmiarów oraz uproszczenia budowy zdecydowałem się na zastosowanie mikrokontrolera ATmega8. Układ taki miał też większe możliwości (w szczególności prostsze zarządzanie zdalne z wykorzystaniem RS-485 lub RS-422A). Równocześnie w miejsce przekaźników zdecydowałam się także na zastosowanie zestawu optotriak + triak. Pierwotna wersja sterownika posiadała na swoim PCB autonomiczne zasilacze sieciowe (niezależne dla każdego sterownika). Podyktowane zostało to rozwiązaniem zasilania instalacji oświetleniowej (układ zabezpieczeń nad i różnicowoprądowych) nie bardzo pozwalającym na centralne zasilenie (wyłączenie jego zabezpieczenia rozwalałoby cały system, który obecnie podzielony jest na strefy z niezależnymi zabezpieczeniami). Został zrealizowany jeden prototypowy sterownik (działający p;o dziś dzień) wg tego projektu.

POWIĘKSZ

Porównanie z koncepcją realizacji na elementach dyskretnych pokazuje przewagę rozwiązań opartych na mikrokontrolerze (gdzie elektronika na układach dyskretnych pełni tylko pomocniczą funkcję). Jest ona spowodowana ogromnymi możliwościami mikrokontrolerów oraz drastycznym uproszczeniem budowy układu, zmniejszeniem rozmiarów, a często także kosztów w stosunku co do realizacji analogicznych układów cyfrowych w oparciu o bramki, przerzutniki itp..

W drugiej wersjach sterownika scentralizowane zostało ich zasilanie, pojawiła się funkcja regulacji jasności wykonana w technologii Pulse Width Modulation dla jednej linii, a także (obok typowej "płaskiej" wersji) została zaprojektowana wersja dwupoziomowa do umieszczenia w typowej obudowie na szynę DIN.

W trzeciej wersji sterowanie PWM zostało rozszerzone na wszystkie linie, a dzięki przeniesieniu obsługi linii sterujących z przełączników do innego modułu (pozostało tylko sterowanie po RS-485) zwiększono liczbę linii do 15tu. W (nie zrealizowanej) erracie tej wersji wprowadzone zostały także opcjonalne układy gasikowe (umożliwiające poprawną pracę z obciążeniem indukcyjnym - świetlówki) i dławiki. Z wersją trzecią zmieniona została także sama metoda projektowania - wykorzystana została powtarzalność układu do hierarchizacji projektu - patrz hierarchiczne schematy w gEDA.

Sterownik w trzeciej wersji zaprojektowany został do wykorzystania w 19" systemie rozdzielnic elektrycznych opisywanym w elektroniczny dom. Sterownik przystosowany był do montażu (max po dwa moduły sterownika) w obudowach rack 19" 3U/250mm mających od frontu szyna DIN do montażu zabezpieczeń (opcjonalnie można też umieścić szynę DIN do montażu dodatkowej aparatury prostopadle do frontowej wewnątrz obudowy panelu). Sterownik montowany powinien być na przestrzeni środkowego 1U. Sterownik może być montowany w pod-obudowie posiadającej otwarte wyprowadzenie kabli podłączeniowych od tyłu (do złączek szynowych montowanych na tylnej ścianie szafy) i zdejmowalną górną pokrywę. Na przedniej maskownicy aparatury modułowej można zamontować dodatkowo diody kontrolne (zasilanie sterownika + napięcie kontrolne sterownika + stan każdej linii) oraz gniazdo RJ-11 dla RS485 i gniazdo zasilania DC. Moduł sterownika odpowiedzialny za obsługę sygnałów wejściowych jest montowany w osobnej obudowie 1U, może być także zintegrowany z centralką alarmową itp urządzeniami. Zobacz także zdjęcia prototypu

Centralka

Jak wspomniałem funkcje obsługi wejść (przełaczników) w wrsji trrzeciej zostały przekazane do innego modułu - była nim centralka alarmowa, oparta na mikrokontrolerze Atmega16. Projekt oparty był na modułach podłączanych do mikrokontrolera poprzez magistralę równoległą utworzoną z portu B mikrokontrolera (8 bitów danych) i części portu A (6 bitów adresowych). Detekcja adresu w modułach realizowana była w oparciu 3 najmłodsze bity (i sygnał zezwolenia) adresu na układzie 74hc183. 3 najstarsze bity adresu mogłyby·ć wykorzystane przez switch magistrali oparty także na układzie 74hc183 do generowania sygnału zezwolenia.:

Moduł wejścia-wyjścia (oparty na buforze dwukierunkowym) i bazujący na nim moduł wejść optoizolowanych (4 zwykłe, 4 z filtrem rc):

POWIĘKSZ POWIĘKSZ

Moduł wyjścia (oparty na rejestrze 8 bitowym) i bazujący na nim moduł kluczy NPN oraz NPN (sterowanie układem od strony masy) + P-MOSFET (sterowanie układem od strony bieguna dodatniego):

POWIĘKSZ POWIĘKSZ

Centralka - wnioski po-wdrożeniowe

Aktualna wersje projektów (w szczególności dostosowane do wymogów projektowych opisanych w mikrokontrolery) znajdują się w dziale z projektami związanymi z inteligentnym domem: sterownik oświetlenia, centralka alarmowa. W pierwotnych założeniach przewijało się stosowanie magistral równoległych w niektórych modułach (np. sterownikach tranzystorowych) do zwiększania ilości wejść/wyjść. Pomysł ten nie został jednak zrealizowany ze względu na powyżej opisane trudności, zamiast tego zostały zastosowane moduły i2c podłączone do głównego sterowniki (w szczególności moduł oparty na mikrokontrolerze pełniącym funkcję slave'a i2c). W ogólności takie moduły można stosować jako (zaawansowane) rozszerzenia wejść wyjść mikrokontrolera (zaletą standaryzacja, niższy koszt na pin niż dedykowane układy i2c, oszczędność 3 pinów w stosunku co do wersji modbusowej).

Komunikacja poprzez RS485

Wraz z użyciem mikrokontrolerów pojawiła się idea zdalnego sterowania poprzez RS485 z wykorzystaniem wbudowanych układów UART. Wiązało się to z koniecznością przyjęcia/stworzenia jakiegoś protokołu do przekazywania komend. W pierwszych rozwiązaniach stosowany był prosty binarny format komunikatów - komunikaty były 4 bajtowe, a dwa pierwsze bity oznaczały typ bajtu w komunikacie (identyfikator urządzenia, identyfikator linii, komenda, odpowiedz). Implementacja tego protokołu zawarta jest w my_rs485_binary.c, a przykład użycia w sterownik_oswietlenia_v2.0.c. Rozwiązanie to ograniczało przestrzeń dostępnych adresów pod-adresów i komunikatów do 6 bitów, a także uniemożliwiało w prosty sposób przekazywania argumentu do komendy (co stało się potrzebne przy sterowaniu jasnością większej ilości linii). Niedogodnością była też niemożność prostego używania terminala (/dev/ttySx) do sterowania urządzeniami.

Kolejnym rozwiązaniem była komunikacja tekstowa ASCII w postaci: @adres#subadres#komenda#parametr; lub @adres#subadres#komenda;, gdzie adres, subadres, komenda, parametr są liczbami z zakresu 0-255 zapisanymi dziesiętne. Implementacja tego protokołu zawarta jest w my_rs485_ascii.c, a przykład użycia w sterownik_oswietlenia_v3.1.c.

W obu wypadkach całość dekodowania i (typowo) wykonywania komendy odbywała się w ramach przerwań związanych z otrzymaniem znaku z portu szeregowego. Niestety ze względu na konieczność stosowania znacznych opóźnień między-znakowych w komunikacji RS485, wynikłą z potrzeby dostosowania się do najwolniejszych modułów, które muszą mieć czas na analizę otrzymanego komunikatu system ulega stosunkowo łatwo zamulaniu. W związku z tym rozważana była zmiana koncepcji odbioru komunikatów z stosowanej analizy w trakcie odbioru na szybki odbiór analizę po jego zakończeniu i potwierdzenie wykonania po odebraniu komendy, ale wymagałoby to stosowania dodatkowego timeoutu na oczekiwaniu na potwierdzenie wykonania.

Kolejnym problemem była chęć umożliwienia nadawania komend (a nie tylko odpowiadania na nie) wielu urządzeniom. Wymusiła ona konieczność stosowania jakiejś formy arbitrażu. Zastosowane w pierwotnej wersji centralki alarmowej indywidualne linie zezwolenia na nadawanie nie zdały niestety egzaminu. Rozważane były m.in.:

Komunikacja binarna i switche - koncepcje niezrealizowane

W efekcie opisanych powyżej problemów z opóźnieniami w transmisji zrodził się pomysł wykorzystania echa (odsyłania odebranego bajtu) do weryfikacji odbioru komunikatu, jej wykonania oraz odbioru odpowiedzi, a przede wszystkim do sterowania prędkością nadawania (czekamy na potwierdzenie odbioru i przetworzenia poprzedniego bajtu). Równocześnie nastąpił powrót do komunikatów binarnych (mniejszy narzut na transmisję oraz prostsza analiza komendy). Komunikat miał składać się z 6 bajtów:

Kodowanie typu bajtu w każdym z bajtów poprawia czytelność protokołu, ułatwia interpretację komunikatu (a także umożliwia detekcję zagubionego bajtu), a także restart transmisji (znacznik pierwszego bajtu).

Algorytm odbioru komunikatu zapisany w pseudo-c:

uint8_t rd, cmd, d1, d2;
uint8_t mask = MY_ADDRESS;
#ifdef USE_INTERPUT
procedura_obslugi przerwania() {
	rd = UDR;
	// zakladamy ze nadawca czeka na potwierdzenie wiec nie bedzie nadawl gdy przetwarzamy
	odblokuj_przerwania();
#else
while (1) {
	rd = wait_for_data();
#endif
	if ((rd & mask) == rd) {
		switch (mask) {
			/// adres
			case MY_ADDRESS:
				mask = 0x20 | 0x1f;
				cmd = 0x00;
				break;
			/// komenda
			case 0x20 | 0x1f:
				mask = 0x40 | 0x0f;
				cmd = rd &0x1f;
				break;
			/// dana 1
			case 0x40 | 0x0f:
				mask = 0x40 | 0x10 | 0x0f;
				d1 = rd &0x0f;
				break;
			case 0x40 | 0x10 | 0x0f:
				mask = 0x60 | 0x0f;
				d1 = d1 | ( ( rd << 4 ) & 0x0f);
				break;
				cmd = execute_cmd1(cmd, d1, &d2); // funkcja wykonuje komendę która ma odpowiedź i zapisuje ją w d2, jeżeli się udało (była taka komenda zwraz 0xff, w przeciwnym razie cmd)
			/// dana 2
			case 0x60 | 0x0f:
				mask = 0x60 | 0x10 | 0x0f;
				if (cmd == 0xff) {
					send( 0x60 | (d2 &0xf) );
				} else {
					d2 = rd &0x0f;
				}
				break;
			case 0x60 | 0x10 | 0x0f:
				mask = MY_ADDRESS;
				if (cmd == 0xff) {
					send( 0x60 | ((d2<<4) &0xf) );
				} else {
					d2 = d2 | ( ( rd << 4 ) & 0x0f);
					execute_cmd2(cmd, d1, d2); // funkcja wykonuje komendę która nie ma odpowiedzi
				}
				break;
		}
		if (cmd != 0xff)
			send(rd);
	} else {
		mask = MY_ADDRESS;
	}
}

Algorytm nadawania komunikatu zapisany w pseudo-c:

send_msg(uint8_t addr, uint8_t cmd, uint8_t d1, uint8_t d2) {
	uint8_t buf[6], i, ret, reply = 0;
	buf[0]=addr;
	buf[1]=0x20 | cmd;
	buf[2]=0x40 | (d1 & 0x0f);
	buf[3]=0x40 | 0x10 | ((d1<<4) & 0x0f);
	buf[4]=0x60 | (d2 & 0x0f);
	buf[5]=0x60 | 0x10 | ((d2<<4) & 0x0f);
	for (i=0; i<6; i++);
		send(buf[i]);
		ret = wait_for_data_with_timeout();
		if (i == 4 && d2 == 0xff) {
			if (ret & 0xf0 ! = 0x60) {
				// błąd transmisji
				return i - 20;
			}
			reply = ret & 0xf;
		} else if (i == 5 && d2 == 0xff) {
			if (ret & 0xf0 ! = 0x70) {
				// błąd transmisji
				return i - 20;
			}
			reply = reply | ( (ret<<4) & 0xf );
		} else if (ret != d[i]) {
			// błąd transmisji
			return i - 10;
		}
	}
	return reply;
}

Niestety nie rozwiązywało to problemu rywalizacji o dostęp do medium transmisyjnego, rozważano w tej kwestii:

Standard

Aktualnym rozwiązaniem jest zastosowanie szybkiego mastera (podłączanego do innych systemów przy pomocy Ethernetu i sieci TCP/IP) mającego do dyspozycji kilka magistral RS485 i aktywnie odpytującego slave'y z wykorzystaniem standardowego protokołu Modbus RTU. W wyjątkowych przypadkach możliwe jest także zastosowanie linii przerwaniowej od slave do mastera. Więcej informacji w inteligentny dom.



Copyright (c) 1999-2015, Robert Paciorek (http://www.opcode.eu.org/), BSD/MIT-type license


Redystrybucja wersji źródłowych i wynikowych, po lub bez dokonywania modyfikacji JEST DOZWOLONA, pod warunkiem zachowania niniejszej informacji o prawach autorskich. Autor NIE ponosi JAKIEJKOLWIEK odpowiedzialności za skutki użytkowania tego dokumentu/programu oraz za wykorzystanie zawartych tu informacji.

This text/program is free document/software. Redistribution and use in source and binary forms, with or without modification, ARE PERMITTED provided save this copyright notice. This document/program is distributed WITHOUT any warranty, use at YOUR own risk.

Valid XHTML 1.1 Dokument ten (URL: http://www.opcode.eu.org/usage_and_config/smart_home/smart_home_story) należy do serwisu OpCode. Autorem tej strony jest Robert Paciorek, wszelkie uwagi proszę kierować na adres e-mail serwisu: webmaster@opcode.eu.org.
Data ostatniej modyfikacji artykulu: '2015-10-10 11:34:31 (UTC)' (data ta może być zafałszowana niemerytorycznymi modyfikacjami artykułu).