Witam, chciałbym Wam zaprezentować prostą konstrukcję, która znacznie ułatwia tworzenie i debuggowanie sieci opartych o moduły RFMxx (RFM22/23/63). Są to popularne moduły radiowe, dostępne w bardzo przyzwoitej cenie, oferujące sporo możliwości. Ktoś w czasie, gdy dostępne są tanie moduły WiFi mógłby zapytać, po co używać droższych modułów RFM? Odpowiedź jest prosta – moduły RFM w czasie nadawania pobierają max 28 mA (lub mniej, zależy od wybranej mocy nadajnika), a w czasie odbioru ok. 18 mA. Moduły WiFi potrafią pobierać nawet kilkaset mA (typowo 200 mA). Ta różnica ma olbrzymie znaczenie, jeśli budujemy urządzenia pracujące z ograniczonym dostępem do energii. Dodatkowo w przypadku modułów RFM możemy, co zresztą też jest wadą, stworzyć własny protokół wymiany danych, najlepiej dostosowany do potrzeb. Ale dość o wadach I zaletach obu rozwiązań, nie jest to artykuł porównujący oba rozwiązania.
Założenia
Kilka lat temu postanowiłem wzbogacić swoją instalację inteligentnego domu o komunikację radiową i po wielu przemyśleniach wybór padł na układy RFM22/23. Problem w tym, że układy tego typu oferują pewne wspomaganie sprzętowe dla wymiany danych, lecz nie implementują żadnych wyższych warstw OSI. W efekcie programista musi stworzyć własny protokół wymiany danych. A to z kolei jest trudne i wymaga godzin debuggowania. Aby ułatwić sobie życie, a jednocześnie zapewnić możliwość prostej komunikacji z urządzeniami wykorzystującymi te moduły z poziomu PCta, stworzyłem sobie prostą przejściówkę PC-USB-RFM. Ponieważ układ był projektowany kilka lat temu, a na rynku wtedy nie było za dużo procesorów z wbudowanym interfejsem USB, dlatego do komunikacji z PC użyłem popularnego układu FT232R. Jego zaletą jest prostota, wbudowany EEPROM (nie wymaga zewnętrznego jak FT232BL), dobra dokumentacja i bezproblemowość przetestowana przez dziesiątki tysięcy hobbystów, którzy go wykorzystali w swoich projektach.
Oczywiście, gdybym dzisiaj projektował ten układ, wykorzystałbym najpewniej procesor z wbudowanym USB, np. którąś z XMEGA. Niemniej nawet dzisiaj wykorzystanie FT232 ma pewne zalety.
Drugą strategiczną decyzją, jaką musiałem podjąć była decyzja o sposobie połączenia FT232 z RFM. RFM wykorzystuje interfejs SPI, czyli teoretycznie można spiąć oba układy bezpośrednio i komunikować się z wykorzystaniem trybu bit-bang układu FT. Takie rozwiązanie ma praktycznie tylko jedną zaletę – prostotę. Ma niestety kilka wad – przede wszystkim możemy zapomnieć o prostej komunikacji z RFM. Każde polecenie lub pakiet będzie musiał być rozkładany na ciąg sygnałów sterujących, przesyłanych przez FT232. Moim celem jednak było stworzenie układu dającego możliwość prostego odbioru i nadawania pakietów np. przy pomocy dowolnego terminala, najlepiej w postaci zbliżonej do poleceń AT. Drugi problem wynikający z bezpośredniego spięcia obu układów jest bardziej subtelny. Wszelkie odbierane dane wędrują do bufora układu FT i stamtąd do PC, skąd muszą być odebrane przez dedykowaną aplikację. Daje to spore opóźnienia i uniemożliwia szybką reakcję na zdarzenia w sieci, oraz reakcję autonomiczną. Musimy pamiętać, że systemy na PC to nie RTOSy i nie mamy żadnej gwarancji obsługi zdarzeń w określonym czasie… Do końca też nie wiedziałem jak wykorzystam tą płytkę, więc pewna uniwersalność też była dla mnie priorytetem. Stąd decyzja była jedna – pomiędzy FT232 a RFM muszę wpiąć jakiś MCU. Ponieważ wiele rzeczy związanych z transmisją sprzętowo robi układ RFM, moc obliczeniowa użytego procesora nie była krytyczna. Stąd też wybrałem dobrze sobie znane układy AVR, konkretniej ATMega162. Wybór o tyle dobry, że bez problemu, jeśli zajdzie potrzeba można dobrać procesor z 32 kB FLASH i wlutować go w miejsce ATMega162. Przy okazji użycia MCU, pojawiła się dodatkowa możliwość. Ponieważ użyty MCU posiada dwa porty USART, stąd jeden wykorzystałem do komunikacji z FT232, a drugi do realizacji opcjonalnego interfejsu RS485. Prezentowana płytka posiada miejsce do przylutowania transceivera MAX485 oraz opcjonalnych terminatorów oraz złącza magistrali RS485. Ponieważ tej opcji w praktyce nie wykorzystałem w zrealizowanym układzie pola te pozostały nie obsadzone.
Użycie MCU wiąże się jednak z pewnym problemem – jakoś trzeba go zaprogramować. Tu jest kilka możliwości – można wyprowadzić złącze ISP, lecz nie jest to wygodne w małym układzie. Złącze zajmuje miejsce, trzeba zapewnić wygodny dostęp do niego, no i trzeba mieć programator. Druga opcja to bootloader. Jednak w warunkach amatorskich bootloader tylko pozornie rozwiązuje problem braku złącza ISP. Użyty procesor ma obudowę TQFP, a więc programowanie poza układem (w podstawce) jest problematyczne. Należałoby, więc bootloader wgrać w już przylutowany procesor, czyli i tak trzebaby jakoś wyprowadzić złącze ISP. Wykorzystałem więc trzecie rozwiązanie – układ FT232 posiada wystarczająco pinów IO, aby piny niewykorzystane do realizacji transmisji RS232-TTL wykorzystać do stworzenia programatora ISP. W dodatku rozwiązanie to jest wspierane np. przez popularny układ AVRDude i wiele innych programów. Dzięki temu po zbudowaniu układu nie musimy posiadać programatora – procesor możemy zaprogramować bezpośrednio przez USB przy pomocy praktycznie dowolnego programu. W swoim systemie wykorzystałem co prawda oprogramowanie napisane własnoręcznie w tym celu (zintegrowane z resztą systemu), ale oczywiście nie jest to wymagane.
W efekcie uzyskałem prostą płytkę, o dużych możliwościach, z łatwo zmienialnym firmware.
MCU zajmuje się translacją poleceń odbieranych z PC na postać zrozumiałą dla RFM23/RS485 i odwrotnie. Doskonale się to sprawdza przy debugowaniu sieci, a różne polecenia, typu włącz/wyłącz jakiś moduł, odczytaj temperaturę i inne realizowane przez sterowniki inteligentnego domu mogę wysyłać wprost z terminala używając zrozumiałych dla człowieka komend.
Opis układu
Przejdźmy do schematu elektrycznego. Całość zasilana jest z magistrali USB, co wymusiło sposób realizacji części elektrycznej (schemat poniżej).
Przede wszystkim napięcie na magistrali USB wynosi ok. 5V, natomiast moduły RFM23 wymagają napięcia 3,3V. Aby uniknąć konieczności zastosowania translatora poziomów pomiędzy MCU a RFM, postanowiłem zasilić MCU także napięciem 3,3V (użyty procesor przy tym napięciu osiąga wystarczającą maksymalną częstotliwość taktowania). Z kolei połączenie pomiędzy FT232 a MCU łatwo zrobić w domenie 3,3V, gdyż układ FT232 ma wyprowadzone napięcie VCCIO, służące do zasilania buforów IO tego układu. W efekcie może on pracować z różnymi napięciami zasilającymi bez konieczności stosowania konwerterów napięć (są one wbudowane w układ). Tu pojawia się mały problem – skąd brać napięcie 3,3V? FT232 ma wbudowany regulator napięcia, lecz jego wydajność (o ile pamiętam max 50 mA) jest niewystarczająca do zasilania MCU, modułu RFM23 i potencjalnie transceivera RS485. Stąd zdecydowałem się na dodatkowy stabilizator LDO (IC2). To prosta kostka, niewymagająca wielu elementów zewnętrznych (tylko dwa kondensatory ceramiczne), więc nie ma problemu. Aby być hiperzgodnym ze specyfikacją USB (w zakresie maksymalnego pobieranego prądu w stanie uśpienia) dodałem tranzystor P-MOSFET (Q1), sterowany z FT232. W przypadku uśpienia układu odcina on zasilanie układów w domenie 3,3V i LDO, w efekcie prąd pobierany przez układ jest zgodny ze standardem USB w tym trybie.
Warto jeszcze przemyśleć taktowanie procesora. Ponieważ generatory wbudowane w procesor wg producenta nie gwarantują stabilności wystarczającej dla poprawnej pracy UART, procesor musi być taktowany z zewnątrz. Należałoby zastosować rezonator kwarcowy – to jednak komplikuje układ. No może nie komplikuje, ale wymaga dodania kwarcu i dwóch kondensatorów. Na szczęście projektanci układu FT232R przewidzieli możliwość wyprowadzenia zegara na jeden z pinów IO. Stąd na wejście XTAL1 procesora podałem zegar generowany przez FT232R (jego częstotliwość można programowo zmieniać). Zaoszczędziłem dzięki temu paru elementów, a procesor taktowany jest stabilnym zegarem, gwarantującym nie tylko poprawną transmisję pomiędzy FT232 i MCU, ale także pomiędzy MCU a magistralą RS485 (połączenie z RFM23 realizowane jest za pomocą synchronicznej magistrali SPI i nie wymaga ono stabilnego taktowania MCU).
Transceiver RFM23 połączony jest z MCU przez interfejs SPI. Dodatkowo dodałem diody LED2 i LED3 sygnalizujące różne stany pracy układu. Są one sterowane przez MCU, wykorzystałem je do sygnalizacji nadawania i odbioru pakietu danych. Wbrew pozorom jest to bardzo pomocne przy debugowaniu sieci. Widać odbierane pakiety, a jeśli przełączę RFM23 w tryb promiscuous to widzę wszystkie pakiety w mojej sieci. LED1 sygnalizuje zasilanie układu (też bywa przydatne), dodatkowo na module RFM23 jest niebieska dioda sygnalizująca poprawność jego pracy i aktywność – również jest przydatna. Rezystory zostały dobrane tak, aby diody nie raziły, a ich świecenie dało się łatwo obserwować nawet po założeniu obudowy.
PCB
Jako, że nie lubię bawić się w domowy wyrób PCB, zleciłem jej wykonanie w firmie MERKAR – mam do nich niedaleko, robią przyzwoite płytki prototypowe, za przyzwoitą cenę. Ze względu na rozmiary (płytka musiała się zmieścić w określonej obudowie) zdecydowałem się na laminat dwustronny, z metalizacją otworów i soldermaską. Pierwotnie płytka jako narzędzie do debugowania miała nie mieć obudowy, więc pomyślałem, że zabezpieczenie wszystkiego soldermaską to dobry pomysł. Powiem szczerze, że czerwona soldermaska + złocenie (tu mnie poniosło, ale w sumie czemu nie zaszaleć, jeśli można) wygląda też optycznie fajnie. A jak powszechnie wiadomo estetyczne układy lepiej działają.
Zastanawiałem się, czy antenę nie umieścić w postaci nadruku na PCB. Nie byłem jednak pewien uzyskanego zasięgu i moich potrzeb w tym zakresie, pomyślałem więc, że umieszczę tylko pole lutownicze i w finalnym układzie rolę anteny spełnia po prostu odpowiednio dobrany odcinek przewodu, umieszczonego w obudowie. W praktyce to rozwiązanie okazało się wystarczające.
Pewną kwestią jest zastosowane gniazdo USB. Wcześniej stosowałem gniazda USB typu B (duże, kwadratowe gniazdo), lecz ich jakość i pewność połączenia jest marna. Wtyczka musi pewnie siedzieć w gnieździe, po jakimś czasie się wyrabia, a całość jest duża i toporna. Gniazda mikro-USB w czasie, kiedy projektowałem ten układ nie były jeszcze popularne, więc wybór padł na gniazdo mini-USB. Sprawdza się ono nieźle, jest małe (niskie), dzięki czemu całość mieści się w niewielkiej obudowie.
Poniżej przedstawiam rysunek PCB i projekt w formacie brd (Eagle).
Uruchomienie
Układ nie wymaga żadnego specjalnego uruchamiania. Ze względu na mały raster układu FT232 warto przez podpięciem całości pod USB sprawdzić czy nie ma zwarć pomiędzy pinami. Po wpięciu układu pod USB OS powinien wykryć układ FT232 i jeśli to Windows poprosić o sterowniki (Linuks ma je zazwyczaj wbudowane). Od tego momentu układ jest gotowy i oczekuje na zaprogramowanie.
Należy jeszcze oczywiście wlutować antenę. Tak jak pisałem, wystarczający jest kawałek przewodu o długości zależnej od częstotliwości pracy modułu RFM23 (są dostępne na 433 i 868 MHz). Zasięg na takiej antenie spokojnie przekracza 100m (więcej nie testowałem). Jeśli zajdzie taka potrzeba antenę można stuningować – po prostu odcinamy kawałek anteny (po jeden do kilku milimetrów jednorazowo) obserwując moc odbieranego sygnału w drugim odbiorniku (rejestr RSSI). W ten sposób możemy dopasować antenę – nie jest to idealne rozwiązanie, ale proste i dostępne dla hobbysty.
Należy tez pamiętać o przestawieniu fusebitów MCU (jeśli korzystamy z taktowania przez FT232) i konfiguracji samego układu FT232 programem MProg udostępnianym przez FTDI.
Efekt
Całość mieści się w małej, plastikowej, półprzezroczystej obudowie. Dzięki temu, że obudowa jest półprzezroczysta ładnie widać diody sygnalizujące pracę układu.
Ku mojemu zaskoczeniu, układ ruszył od razu, okazało się, że wszystko jest ok i nie wymaga przeróbek. Całość w 100% spełniła moje oczekiwania, ułatwiając (a właściwie umożliwiając) mi napisanie własnego protokołu komunikacji i stworzenie własnej sieci opartej na modułach RFM22/23/63.
Poniżej kilka zdjęć zmontowanego układu:
Fajne!
]
