Elektroda.pl
Elektroda.pl
X
Computer ControlsComputer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Jaka magistrala danych w akwarium?

05 Maj 2006 23:51 1832 11
  • Poziom 18  
    Mam kilka mikrokontrolerowych urządzeń w swoim akwarium. Każde z nich ma swój wyświetlacz, przyciski itd. Chciałem przeprojektować to wszystko w ten sposób, żeby było kontrolowane z jednej "centralki". Generalnie używam mikrokontrolerów atmela. Jaka magistrala danych, dała by się łatwo zaimplementować do tego celu? Założenia, które wymyśliłem do tej pory, choć pewnie w praaniu coś wyjdzie:

    1. kable łączące około 2-3 metry o jak najmniejszej liczbie żył
    2. w zasadzie centralka to master, ale urządzenia slave też moga "niezapowiedziane" wysyłać alarmy o sytuacjach krytycznych
    3. transfer około 200-300 bajtów/s
    4. jakieś wsparcie sprzętowe (myśle że wszystkie rzeczy przerzucę na atmegę przy okazji)
    5. programowanie przez botloadera z użyciem tej magistrali (możliwiść wygodnego updatu sowtu w każdym "klocku" jednym kablem bez rozłączania całej cieci)
    6. sporo urządzeń (np oświetlenie), będzie pracowało w blokach tzn, mam obecnie 4, ale powiedzmy, żeby centralka sama wykryła, gdy podłącze piąte, lub usunę czwarte (problem dynamiczniej identyfikacji i jednocześnie nie gubienia urządzeń przy przypadkowym odpięciu i podpięciu).

    Nie mam jeszcze ostatecznej koncepcji całego API, ale wstępnie jednostka centralna miała by w sobie zegar, sekcję odpowiedzialną za wykrywanie urządzeń i wyświetlacz z przyciskami i głośnikiem.
    Każde z podurządzeń dostawało by w określonej kolejności (MENU) kontrolę nad tymi peryferiami w celu nastawy swoich wartości. Magistrala regularnie co sekunde nadawała by aktualny czas.
    Mam jeszcze problemy z pewnymi rzeczami typu brzęczyk który włącza się zarówno przy wzroście temperatury (chłodzenie) czy spadku pH (usuwanie CO2), albo sterowania wybranych opcji pilotem, ale to już w sumie kwestia API choć daje pogląd na to co ma udźwignąć magistrala.

    Będe wdzięczny za wszystkie sugestie.
  • Computer ControlsComputer Controls
  • Tłumacz Redaktor
    A może jako centralke postaw komputer PC? Wtedy całość mogła by odbyć sie o wiele prościej - np. poszczególne bloczki byłyby sterowane poprzez LPT, albo RS232 (adres nadawcy + adres odbiorcy + dane, lub jakies podobne pakiety byś przesyłał). Wtedy magistrala miałaby naprawde spory transfer. Ew. możesz zastanowić sie nad RS485 - to chyba klasyka czegoś takiego, gotowe, standardowe, rozwiązanie, duży zasieg, stabilność no i masa gotowych materiałów.
  • Poziom 18  
    Pomysł włączonego na stałe komputera nie bardzo mi odpowiada. Oczywiście planuję napisać program który "podszyje się" pod centralkę i będe mogł z komputera ustawić wszystkie parametry. Jeśli użył bym któregoś ze wspomnianych standardów w swojej sieci to implementując je w atmelach urządzeń odbiorczhych i tak musiał bym popisać procedury komunikacji na tą platformę którą mógłbym wykorzystać przecież w centralce. Jedyną różnicą był by więc layaut w jednym przypadku na monitorze komputera, w drugim na mojej centralce, więc procedury komunikacji musiał bym na starcie pisać na dwuch platwormach, a nie jednej. Nigdy oprócz wysyłania pojedynczych bajtów I2c nie pisałem własnej sieci, a standartów jest dość sporo, dlatego chodzi mi głównie który z jest łatwiejszy do ogarnięcia i nie jest za duży do moich potrzeb. Jeszcze uświadomiłem sobie, że przydałby się jakiś łatwy sposób monitorowania sieci przez mikrokontrolery. Ciężko mi pisać kod którego główna pętla tym się zajmuje. Wolał bym zeby któreś przerwanie to robiło, albo wręcz było wywoływane określonym stanem na wejściu mikrokontrolera.
  • Computer ControlsComputer Controls
  • Poziom 36  
    Ja w takim układzie zastosowałbym RS485 albo LIN w wersji opisanej w nocie ATMELa. W LIN-ie cała transmisja idzie po jednym drucie, do tego masa i + czyli w sumie 3 przewody łączące moduły. Jeśli chodzi o organizację logiki, to optymalnym pod względem realizacji (pracochłonności) jest wariant z pojedynczym masterem odsłuchującym sekwencyjnie końcówki.
  • Tłumacz Redaktor
    Komputer komputerowi nie równy - może to być p200 włączony na stałe (conajmniej 2 wentylatory, dysk, sporo hałasu), albo jakis SBC (single board computer) na 386 lub 486 - zdażają sie takie czasami na allegro, cena około 50..100zł (żadnych ruchomych części - zasilanie 12V i 5V tylko (zazwyczaj) karta video, czasami LAN, czasami RS485 itp na płycie, zintegrowane, a jako dysk Flash zwykły (MMC bodajże, albo inne cos takiego dało sie bezpośrednio pod IDE podpiąć) wiec hałasu zero, prądu tez nie dużo żre).

    A co do standardu sieci to napewno najlepszy bedzie RS485 - to klasyka w takich zastosowaniach IMHO, a nie trudno go opanowac, kiedys nawet w Elektronice Praktycznej opublikowano pare artykółów na ten temat, a AVT ma kilka odpowiednich KITów w swojej ofercie.
  • Poziom 36  
    Mad Bekon napisał:
    A może by tak na I2c? Przecież większość atmeli jest wyposażona w nią sprzętowo i tylko 2-3 kable.
    Ze względu na "przemysłowe" zakłócenia w akwarium, lepiej chyba zastosować wariant odporniejszy.
  • Tłumacz Redaktor
    i2c mam ponadto niewielki zasieg w porównaniu do RS485, któremu to ponadto nie są straszne _żadne_ zakłócenia bo jest transmisją różnicową. No ale wtedy konieczny jest dodatkowy scalak-konwerter...
  • VIP Zasłużony dla elektroda
    Transmisję po I²C można przecież programowo korygować np. przy pomocy CRC-8
    Code:
    .cseg
    
    ;   lds TempC, CRC8Sum
    ;   clr TempC ; Clear TempC (CRC8Sum) at first byte
    GetByteCRC8: ; (DataAcc; ->CRC8Sum@TempC))
       push cL
       ldi cL, 0x08   ; bits counter
       ldi TempB, 0x18   ; bits CRC-8 change XOR value (from AN27 Maxim-Dallas)
       mov TempA, DataAcc
    GetByteCRC8Loop:
       mov TempD, TempA ; Only 7s bits means
       eor TempD, TempC ; about conditon
       sbrc TempD, 7    ; of xor 0x18
       eor TempC, TempB ; 0x18
       lsl TempD       ; return bit to 2^0 in CRCSum
       rol TempC
       lsl TempA
       dec cL
       brne GetByteCRC8Loop
       pop cL
       ret
    ; Note :
    ;   - eor does not change carry flag.
    ;   - sbrc does not change any flag.
    Jak dodatkowo przesłana suma kontrolna się nie zgadza z obliczoną sumą przesłanych danych, to ponawiamy reqesta o transmisję...
  • Poziom 36  
    ghost666 napisał:
    No ale wtedy konieczny jest dodatkowy scalak-konwerter...
    Dlatego jako alternatywę proponowałem soft-wersję sieci LIN, gdzie nadajnikiem i odbiornikiem linii jest pojedynczy tranzystor a transmisja z/do UARTa realizowana jest po jednym drucie. Nie jest to co prawda układ różnicowy, ale istnieje możliwość zwiększenia marginesu zakłóceń przez podbicie napięcia podciągającego linię np. do 24V czy nawet wyżej, a w skrajnym przypadku bardzo łatwo w poszczególnych modułach założyć optoizolację na liniach transmisyjnych.
  • Poziom 18  
    Z tym odsłuchiwaniem slave sekwencyjnym to rzeczywiście najłatwiej będzie. Przejrze noty katalogowe i jeszcze się pewnie potytam. Co do zakłuceń przemysłowych to brzęczyk + kilka elektrozaworów i elektroniczne startery do świetlówek dają trochę rzeczywiście. Wolałbym nie podnosic napięcia na linii transmisyjnej i zostać przy 5V, ale jak trzeba będzie to nie przeskocze. Tak jak pisałem pzrydało by się żeby można było przeprogramowywac poszczególne "klocki" przy użyciu tej linii. Może macie jeszcze jakieś sugestie odnośnie dynamicznego wykrywania elementów i nie gubienia ich przy czasowym odłączeniu? Myślałem o nadawaniu im unikatowych numerów (rodzaj klocka+jego numer) i trzymaniu tego gdzieś w centralce. Powoli będe pewnie projektował centralkę i pierwszy najprostrzy układ współpracujący. Tak sobie pomyślałem, że z czasem może dodam opcję obsługi akwarium+terrarium z jednej centralki i jakąś drogę radiową lub podczerwoną dorzuce, ale na razie to jeszcze daleko. Co sądzicie o języku?? Myślę że nad asm będzie ciężko zapanować przy tak dużym projekcie. Chyba C??
  • VIP Zasłużony dla elektroda
    pawelvod napisał:
    Może macie jeszcze jakieś sugestie odnośnie dynamicznego wykrywania elementów i nie gubienia ich przy czasowym odłączeniu?
    1. Centrala wydaje komendę "przedstawiamy się".
    2. Reszta przygotowuje swoje adresy.
    3. Centrala pyta "Kto pierwszy ?"
    4. Każdy pozostały sprawdza, czy linia ma stan niski, jak nie to ustawia stan niski, w pozostałym wypadku czeka na ponowne "Kto pierwszy". Oczywiście trzeba przemyśleć sytuację, gdy wiecej niż jedno urządzenia wykryje stan wysoki, oraz wprowadzić zmniejszenie prawdopodobieństwa takich sytuacji np. pseudolosowe opóźnienia z reakcją na komendę, wyliczane w funkcji adresu...
    5. Ten, który był pierwszy, wysyła swój adres i czeka na "koniec przestawiania",
    6. Jeśli nic już się dalej nie zgłasza przez określony czas, centrala robi "koniec przestawienia" :P.
    7. Każda próba "przywołania do tablicy" powinna mieć swój timeout z usunięciem z listy aktywnych urządzeń.
    8. Można oprócz adresu wprowadzić dodatkowo "Function String", po którym centrala wykrywałaby, do czego dane urządzenia jest zdolne.
    9. Każde urządzenie po włączeniu blokuje linię pullup przez określony czas, po czym wysyła swój adres + "Function String".
    Szczegóły można zrobić w/g własnej fantazji.
    pawelvod napisał:
    Co sądzicie o języku?? Myślę że nad asm będzie ciężko zapanować przy tak dużym projekcie. Chyba C??
    Nie pytaj nas, nad czym zapanujesz, bo to ty wiesz najlepiej... ;) Dla mnie programowanie proceduralne w asm to żaden problem, a raz napisana procedurkę można używać wiele razy - w asemblerze AVRasm2 też jest polecenie preprocesora #include, więc projekt można sobie rozbić na małe, czytelniejsze pliki... ;)