Jak zbudować elegancki terminal LCD do sterownika kotłowni z uC i komunikacją?

Mon Mar 17, 2014 5:53 pm   

Robie sobie sterownik kotlowni, i zapragnalem miec jakas konsolke w salonie polaczona kabelkiem. Jakies LCD, podswietlenie, przyciski, moze beeperek. Do sterowania i do informacji zwrotnej.

Jak to zrobic?

1.) Przedluzyc kabelki
Obslugiwac bezposrednio ze sterownika, tylko nie na 5V (spadki napiecia) tylko chociaz 12V (jak manipulator centralki alarmowej)

2.) Terminalek z uC
Troche elegantsze rozwiazanie, oddzielny uC do gadania z uzytkownikiem i zajmowania sie pierdolami. Tylko jaka bedzie najlepsza komunikacja ze "serwerem"?

a) RS232? Wolalem sobie go wykorzystac do innych celow
b) i2c - chyba nie da rady na metrowe odleglosci.
c) dostawka i2c-rs232 po stronie sterownika, z kolejnym uC
d) 1wire - upierdliwe do programowania
e) cos innego?

Czekam na odpowiedzi, szczegolnie na te w stylu "chlopie, od lat robi sie to w jedyny sluszny sposob, czyli ..."

bajcik

Mon Mar 17, 2014 5:53 pm   

W dniu 2014-03-17 16:53, garus.krzysztof@gmail.com pisze:

RS-485

Mario

Mon Mar 17, 2014 6:24 pm   

Uzytkownik <garus.krzysztof@gmail.com> napisal w wiadomosci
news:3ba350f0-6b4f-473f-a790-e4705d64f276@googlegroups.com...

sterownik oprzec na czyms co ma wszystko w w sobie czyli np raspberry pi.
Nadawac informacje do netu po wifi. Napisac aplikacje na smartfona. Powiesic
starego smartfona/tableta na sciane jako LCD.



b.

Mon Mar 17, 2014 7:20 pm   

W dniu 2014-03-17 18:24, Budyn pisze:

Miałem napisać to samo, tylko po co aplikacja? Niech toto będzie
widoczne jako zwykła strona webowa, prezentująca wszelkie dane i guziki
do klikania, dostępna z każdego smatforma i domowego kompa
--
Pozdrawiam
Andrzej
www.symbiostock.info

Tue Mar 18, 2014 8:47 am   

W dniu 2014-03-17 16:53, garus.krzysztof@gmail.com pisze:


Masz w domu jakąś sieć LAN?
Najfajniejszym rozwiązaniem na chwilę obecną jest zastosowanie
Ethernetu. ENC28J60 kosztuje grosze, do tego będziesz musiał jeszcze
doliczyć gniazdko RJ45 z wbudowanym trafkiem (lub gniazdko + zewnętrzny
transformator). Mogę powiedzieć, że rozwiązanie jest stabilne. Skleciłem
sobie kilka płytek testowych z Megą329 i tym układem. Jedną z nich
trzymałem włączoną przez ponad miesiąc. Wgrany przykład z prostym
serwerkiem WWW, bez watchdoga. Nie zauważyłem żadnego zawieszenia, układ
przez cały czas działał stabilnie, odpowiadając na pingi i obsługując
zapytania HTTP.

Będziesz potrzebował jeszcze stosu TCP/IP. Ten najprostszy,
minimalistyczny z tuxgraphics.org powinien wystarczyć do twoich
zastosowań (wadą jest ograniczona ilość danych, jakie można przesłać za
jednym razem, równa pojemności jednej ramki ethernetowej). Łatwo się to
obsługuje od strony programistycznej. Gdybyś potrzebował czegoś więcej
(np. telentu) to można użyć któregoś z bardziej rozbudowanych stosów,
np. uIP albo tego od Microchipa (jeśli korzystasz z PIC-ów).

Jeśli nie masz w pobliżu kotłowni żadnego switcha, od którego mógłbyś
pociągnąć kabel ethernetowy, to też nie problem:

http://tuxgraphics.org/electronics/201006/avr-wifi.shtml

Nie sądzę, żeby konieczne było stosowanie osobnego MCU do obsługi stosu
i parsowania nadchodzących danych. Jeśli jednak zależy ci na odciążeniu
głównego sterownika, to możesz użyć układu z wbudowanym stosem (np.
W5100 - obudowa LQFP, trochę trudniej się lutuje).

Inne rozwiązania? RS485, CAN, można próbować modułów do transmisji radiowej.

BTW w książce Mirosława Kardasie "Język C, pasja programowania
mikrokontrolerów 8-bitowych" w fajny sposób omówione zostało zagadnienie
parsowania danych, na przykładzie komend AT. Na dołączonej płytce gotowa
biblioteka.

Tue Mar 18, 2014 9:22 am   

On Tue, 18 Mar 2014 08:47:50 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

A mógłbyś podać jeden przykład? Ostatnio sporo żółci wylałem na
jakość ogólnie dostępnych bibliotek do parsowania at, albo nagminne
blokowanie procesora przez delay () (skandal) oczekując na bufor,
brak użycia urc, brak pdu, brak obsługi długich smsow (udh), brak
obsługi krótkich kodów itd, itp. u w końcu napisałem własną :/

--
Marek

Tue Mar 18, 2014 9:26 am   

W dniu 2014-03-18 09:22, Marek pisze:



Nie chodzi o obsługę kodów AT w modemach i modułach GSM. Tutaj chodzi o
drugą stronę kabla - biblioteka umożliwia zaimplementowanie we własnym
urządzeniu zestawu własnych komend.

Moim zdaniem napisana jest bardzo dobrze. Nie ma żadnego blokowania
procesora, wszystko opiera się na mechanizmie zdarzeń.

Tue Mar 18, 2014 11:06 am   

W dniu poniedziałek, 17 marca 2014 16:53:42 UTC+1 użytkownik garus.k...@gmail.com napisał:

Ooo, nocoty?
Dokładnie do tego samego dojrzewam (tyle, że u mnie nie o kotłownię chodzi). Raspberry - fajny pomysł, muszę przemyśleć, bo taka opcja z góry rozwiązywałaby inny problem: dostęp do urządzenia z poziomu wpiętego do domowej sieci peceta, ale póki co zamierzałem to robić normalnie, na moich ulubionych Atmelach, z wykorzystaniem RS485, w necie na ten temat jest sporo materiałów, również dla początkujących.

Tue Mar 18, 2014 11:41 am   

W dniu 2014-03-18 10:06, Jarek P. pisze:


Zastanawiam się na ile to faktycznie ma sens. Podpięcie AVR-a do sieci
lokalnej w dzisiejszych czasach nie jest wielkim problemem. Było kilka
lat temu, gdy jedynym rozwiązaniem było skorzystanie z RTL8019 i
programowa emulacja magistrali równoległej. Teraz wystarczy podpiąć
ENC28J60 przez SPI, ściągnąć jedną z kilku bibliotek do obsługi stosu i
napisać kilka własnych funkcji pośredniczących w komunikacji. Jak ktoś
chce, to może użyć nawet scalaka (lub nawet modułu WiFi) ze stosem
obsługiwanym sprzętowo.

Linuksowa płytka moim zdaniem jest fajna, gdy trzeba parsować większą
ilość danych, które niekoniecznie przychodzą do nas w z góry
przewidzianym porządku. Jednak główną zaletą AVR-a jest dla mnie to, że
obsłuży tylko to, co mu się napisze. O wiele mniej miejsca na
potencjalnego buga lub backdoora, niż w "dużym" systemie operacyjnym.

Tue Mar 18, 2014 12:47 pm   

On Tue, 18 Mar 2014 11:41:48 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


W pełni się z tym zgadzam, z tym że może dla inicjatora wątku łatwiej
użyć RPi (zna się na tym) niż encj... co jakby nie patrzeć jest
rzeźbieniem...

--
Marek

Wed Mar 19, 2014 11:15 am   

W dniu wtorek, 18 marca 2014 08:47:50 UTC+1 użytkownik Atlantis napisał:

Lan jest, kabelek nawet dedykowany do tego sterownika pod tynkiem czeka.
To tez planuje kiedystam, ale raczej do komunikacji sterownika ze serwerkiem. Dopiero tam moze jakis interfejs webowy.


Doczytam.


Parsery jadam na sniadanie, powinienem sobie poradzic :)

/bajcik

Wed Mar 19, 2014 6:02 pm   

W dniu 2014-03-19 10:15, garus.krzysztof@gmail.com pisze:


To powinno rozwiązywać problem. Nie widzę potrzeby, żeby mnożyć kable.
Jak już będziesz miał w sterowniku interfejs Ethernet, to możesz
skomunikować go z tą konsolką za pomocą sieci lokalnej. Pakiety UDP
powinny wystarczyć. Na lepszym stosie niż tuxgraphics (albo na W5100)
można też odpalić telnet.

Nie wiem dlaczego ludzie upierają się na stawianie interfejsów webowych
na ośmiobitowych AVR-ach, jakby to było jedyne rozwiązanie.

Thu Mar 20, 2014 9:01 am   

On Wed, 19 Mar 2014 18:02:29 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Web - uniwetsalne gui, avr - prosta implementacja...?

--
Marek

Thu Mar 20, 2014 1:08 pm   

W dniu środa, 19 marca 2014 18:02:29 UTC+1 użytkownik Atlantis napisał:

Nie mam na razie ani interfejsu ETH ani know-how to jego obslugi ani nawet routera
Podstawowa funkcja mini-terminala to ma byc mierzenie temperatury wewnatrz salonu, a interfejs uzytkownika to dodatkowy bajer. Wole zeby to dzialalo bez zaleznosci od LANu. Jak juz postawie sieci dobuduje interfejs ETH, to wtedy mini-terminala nie bede potrzebowal bo obsluze wszystko ze smartfona/tableta.

Swoja droga, systemy alarmowe jak lacza maniupulatory z centrala? Czegos takiego bym potrzebowal. Ciekawe czy to rs485 czy jakies autorskie rozwiazania.

bajcik

Fri Mar 21, 2014 11:40 am   

W dniu 2014-03-20 12:08, garus.krzysztof@gmail.com pisze:


Obsługa tak naprawdę nie jest skomplikowana, chociaż trzeba się wczytać
w kody przykładów dołączonych do biblioteki. W przypadku tuxgraphics
wygląda to następująco (w skrócie):
1) Dodajemy pliki nagłówkowe, w niektórych z nich konfigurujemy
bibliotekę do naszego konkretnego zastosowania (obsługiwane funkcje) i
procesora.
2) Na początku programu definiujemy kilka tablic (numer MAC, własny
numer IP, numery IP zdalnych hostów jeśli korzystamy z funkcjonalności
klienta) oraz stałych (numery portów z których będziemy korzystać).
Potem wywołujemy funkcje inicjujące, podając im powyższe argumenty.
3) W głównej pętli programu cyklicznie sprawdzamy czy przyszła nowa
ramka Ethernet. Jeśli się pojawiła, odczytujemy ją do przygotowanego
wcześniej bufora.
4) W przypadku odebrania pakietu, w następnej kolejności przekazujemy go
funkcji, która sprawdzi co w nim siedzi (obsługa ICMP, ARP, TCP). Jeśli
przyjdzie pakiet TCP, dostaniemy wskaźnik do początku danych, które
można parsować. W zależności od zawartości pakietu można przygotować
odpowiedź.
5) Jeśli funkcja powie nam, że nie było pakietu TCP, trzeba jeszcze
sprawdzić czy nie było pakietu UDP (ta kwestia została potraktowana
przez autora trochę po macoszemu) - dosłownie kilka dodatkowych linijek
kodu, wszystko przystępnie wyjaśnione w niebieskiej książce pana
Kardasia. ;)

W cięższych stosach (albo w sp0rzętowym stosie układów Wiznetu) pewnie
jest jeszcze łatwiej, ale tego akurat jeszcze nie przerabiałem, może za
wyjątkiem paru przykładów Arduino z Ethernet Shieldem. ;)



Jeśli tak, to tak naprawdę wystarczy pociągnąć RS485. Tylko dwa
urządzenia, brak konieczności implementacji rozwiązania multimaster itp.
Tylko czy faktycznie chcesz ciągnąć dodatkowy kabel, skoro i tak ma to
być rozwiązanie tymczasowe, docelowo zastąpione przez LAN?
Bo jak sądzę nie można raczej liczyć na tak dogodny zbieg okoliczności,
żeby już teraz centralne urządzenie i mini-terminal były umieszczone w
pobliżu końcówek jednego, już istniejącego kabla ethernetowego. Wtedy
parę skrętki mógłbyś tymczasowo wykorzystać na RS-a.



Nie wiem jak instalacje alarmowe, jak jak na razie widziałem tylko kilka
fabrycznych urządzeń do zdalnego włączania odbiorników energii
elektrycznej albo odczytywania takich danych jak temperatura, wilgotność
czy ciśnienie. Było to zrealizowane w ten sposób, że jedno urządzenie
master udostępniało interfejs webowy po Ethernecie a ze slave'ami
łączyło się przez RS4855 lub radiowo.

W przypadku AVR-ów odpuściłbym sobie nterfejs webowy, przerzucając go na
inne urządzenie, ale to tylko moje zdanie.