Witam. Od dłuższego czasu zastanawiam się nad systemem automatyki domowej, składającej się z licznych modułów, sterowanych centralnie, lub o hierarchii równorzędnej.
Zastanawiałem się nad takimi magistralami jak RS485, 1WIRE lub CAN. I doszedłem do przekonania, że chyba musiałbym w okablowaniu wykorzystać przynajmniej dwie równorzędne magistrale, ze względu na łatwość adaptacyjną i potencjalne koszta. Argumenty?
Do prostego sterowania załącz wyłącz - wystarczy mi magistrala 1WIRE + zasilanie. Pakowanie do każdego modułu załącz wyłącz układu MAX485 i mikrokontrolera w celu realizacji tak prostej funkcji jak załącz wyłącz wiązałoby się z niepotrzebnymi kosztami i zbędną komplikacją układową.
Tymczasem do komunikacji bardziej skomplikowanych modułów niezbędne byłoby wg mnie zastosowanie magistrali np. RS485.
Tak sobie myślę, co by tu zrobić, żeby było dobrze. Być może nie jest złym pomysłem zastosowanie w wiązce okablowania kilku przewodów więcej i rozprowadzenie kilku magistral wykorzystywanych w zależności od potrzeb danego modułu. Tylko, że tutaj tracimy na równorzędności - należałoby w tej sytuacji przyjąć centralne sterowanie, lub ewentualnie na krańcach każdej z magistral zastosować odpowiednie układy tłumaczące.
Z dużym zainteresowaniem wysłucham jednak wszystkich Waszych pomysłów i uwag.
Pozdrawiam
Mariusz
Magistrala dla domowej automatyki RS485, 1Wire, CAN ?
-
mariusz_edw
- Użytkownik
- Posty: 307
- Rejestracja: 22 lip 2005, 13:02
- Lokalizacja: Polanica Zdrój
- Kontakt:
-
Skrzydlaty
- Użytkownik
- Posty: 126
- Rejestracja: 23 wrz 2007, 21:08
- Lokalizacja: Krak
Widzę że problem "domowych" magistral nagle zaczął być popularny. Pytałem w innym temacie o magistrale, było kilka odpowiedzi a i sam mam własne przemyślenia na ten temat.
Domowy system automatyki zapewne nie będzie posiadał aż tak wielu urządzeń a i prędkość transmisji nie będzie krytyczna. Cały system będzie zapewne zróżnicowany i będą do niego podłączone rożne układy a i oparty na mikrokontrolerach, zapewne AVR'ach. Musi mieć możliwość wyboru trybu pracy (master/slave).
A więc pozwolę sobie porównać RS485 i 1wire pod kątem współpracy z AVR'ami.
1wire: plusy: tylko 2 przewody połączeniowe, w przypadku pełnego zasilania 3 (można zasilać cały system z jednego źródła: 2 przewody zasilające i jeden na dane na magistrali)
połączenie zarówno skomplikowanych modułów na np. Mega128 jak i prostych układów typu włącz/wyłącz np. za pomocą mikrokontrolera Tiny2313 - magistrala może być podłączona bezpośrednio do procka i on jest "tunelem" w komunikacji z modułem (program w nim zawarty) więc nie ma żadnych ograniczeń sprzętowych typu podpinanie dodatkowych konwerterów RS485 - wystarczy tylko jeden pin procka, CENA połączenia, praktycznie nieograniczona liczba modułów,
minusy: brak izolacji galwanicznej między modułem a magistralą, BRAK BIBLIOTEKI 1WIRE-SLAVE.LIB w pakiecie Bascom AVR co jest dość dużym utrudniniem dla małych i nie wymagających projektantów domowych sieci.
RS248:plusy: izolacja galwaniczna między modułem a magistralą, jest ona zapewne bardziej profesjonalna i dopracowana niż 1wire,
minusy: konieczność stosowania konwerterów RS485, max 32 moduły, więcej przewodów komunikacyjnych w stosunku do 1wire
A więc podsumowując bardziej interesującą magistralą dla domowych systemów automatyki wydaje sie 1wire ze względu na koszt. Jednak prawdopodobnie nikt z mniej zaawansowanych programistów jej nie stosuje ze względu na niemożliwość ustawienia procesorów w tryb slave pod Bascomem. A więc jeśli ktoś uważa że dobrym pomysłem będzie napisanie biblioteki 1wire-slave.lib to apel do programistów mających "chwilkę" wolnego czasu: napiszcie proszę takową bibliotekę:)))
Domowy system automatyki zapewne nie będzie posiadał aż tak wielu urządzeń a i prędkość transmisji nie będzie krytyczna. Cały system będzie zapewne zróżnicowany i będą do niego podłączone rożne układy a i oparty na mikrokontrolerach, zapewne AVR'ach. Musi mieć możliwość wyboru trybu pracy (master/slave).
A więc pozwolę sobie porównać RS485 i 1wire pod kątem współpracy z AVR'ami.
1wire: plusy: tylko 2 przewody połączeniowe, w przypadku pełnego zasilania 3 (można zasilać cały system z jednego źródła: 2 przewody zasilające i jeden na dane na magistrali)
połączenie zarówno skomplikowanych modułów na np. Mega128 jak i prostych układów typu włącz/wyłącz np. za pomocą mikrokontrolera Tiny2313 - magistrala może być podłączona bezpośrednio do procka i on jest "tunelem" w komunikacji z modułem (program w nim zawarty) więc nie ma żadnych ograniczeń sprzętowych typu podpinanie dodatkowych konwerterów RS485 - wystarczy tylko jeden pin procka, CENA połączenia, praktycznie nieograniczona liczba modułów,
minusy: brak izolacji galwanicznej między modułem a magistralą, BRAK BIBLIOTEKI 1WIRE-SLAVE.LIB w pakiecie Bascom AVR co jest dość dużym utrudniniem dla małych i nie wymagających projektantów domowych sieci.
RS248:plusy: izolacja galwaniczna między modułem a magistralą, jest ona zapewne bardziej profesjonalna i dopracowana niż 1wire,
minusy: konieczność stosowania konwerterów RS485, max 32 moduły, więcej przewodów komunikacyjnych w stosunku do 1wire
A więc podsumowując bardziej interesującą magistralą dla domowych systemów automatyki wydaje sie 1wire ze względu na koszt. Jednak prawdopodobnie nikt z mniej zaawansowanych programistów jej nie stosuje ze względu na niemożliwość ustawienia procesorów w tryb slave pod Bascomem. A więc jeśli ktoś uważa że dobrym pomysłem będzie napisanie biblioteki 1wire-slave.lib to apel do programistów mających "chwilkę" wolnego czasu: napiszcie proszę takową bibliotekę:)))
-
mariusz_edw
- Użytkownik
- Posty: 307
- Rejestracja: 22 lip 2005, 13:02
- Lokalizacja: Polanica Zdrój
- Kontakt:
Być może lepszą od obu porównanych magistral byłaby CAN. Tylko, że o magistrali CAN cicho-sza w popularnej prasie. Ciekawe dlaczego.
Odsyłam do ciekawego projektu na magistrali CAN: http://siwilo.com/hapcan/index_pl.htm
Odsyłam do ciekawego projektu na magistrali CAN: http://siwilo.com/hapcan/index_pl.htm
-
Skrzydlaty
- Użytkownik
- Posty: 126
- Rejestracja: 23 wrz 2007, 21:08
- Lokalizacja: Krak
-
mariusz_edw
- Użytkownik
- Posty: 307
- Rejestracja: 22 lip 2005, 13:02
- Lokalizacja: Polanica Zdrój
- Kontakt:
Plusy CANSkrzydlaty pisze:Będę sie wczytywał. Puki co czekam na Twoje zdanie dlaczego wg. Ciebie ta magistrala jest lepsza.
- praca w trybie multi-master (nie potrzebuje urządzenia nadrzędnego sterującego ruchem)
- duża liczba urządzeń na magistrali
- sprzętowa obsługa błędów i dostępu do medium
- niezawodność
- odpowiednia możliwa długość magistrali
http://pl.wikipedia.org/wiki/Controller_Area_Network
-
ZbeeGin
A jakbyś Mariusz zainteresował się protokołem X10 i całą jego specyfiką sprzętową. Do transmisji wykorzystuje ona... instalację elektryczną.
http://www.x10.pl/ http://www.smarthomeusa.com/info/x10theory/#theory
p.s. Nawet BASCOM posiada drobne wsparcie dla tego standardu.
http://www.x10.pl/ http://www.smarthomeusa.com/info/x10theory/#theoryp.s. Nawet BASCOM posiada drobne wsparcie dla tego standardu.
-
Jurek Szczesiul
- -
- Posty: 13
- Rejestracja: 08 paź 2005, 18:20
Re: Magistrala dla domowej automatyki RS485, 1Wire, CAN ?
Cześć !mariusz_edw pisze: Z dużym zainteresowaniem wysłucham jednak wszystkich Waszych pomysłów i uwag.
Oglądałeś może już
http://idom.wizzard.one.pl/
Pozdrowienia Jurek S.
-
mariusz_edw
- Użytkownik
- Posty: 307
- Rejestracja: 22 lip 2005, 13:02
- Lokalizacja: Polanica Zdrój
- Kontakt:
Re: Magistrala dla domowej automatyki RS485, 1Wire, CAN ?
Dziękuję za stronę.Jurek Szczesiul pisze:Cześć !mariusz_edw pisze: Z dużym zainteresowaniem wysłucham jednak wszystkich Waszych pomysłów i uwag.
Oglądałeś może już
http://idom.wizzard.one.pl/
Pozdrowienia Jurek S.
Wszystko rozbija się o bibliotekę w rodzaju 1WIRE-SLAVE.LIB - jeśli oczywiście mamy ochotę pobawić się Bascomem.
-
Sagittarius
- Użytkownik
- Posty: 130
- Rejestracja: 29 maja 2007, 9:29
- Lokalizacja: Kujawsko-pomorskie
- Kontakt:
Przejrzałem link o x10... Sieć energetyczna jest ciekawym pomysłem, ale niestety nie zawsze się sprawdzi. Jeśli trafimy na bardzo zaśmiecone środowisko, mogą być problemy.
RS485- potrzebna jest skrętka, czyli dwa przewody. Zasilanie może być doprowadzone drugą parą lub lokalnie, jeśli odległość między urządzeniami jest duża. Myślę, że jest to jedno z najbardziej odpornych na zakłócenia rozwiązań.
1 Wire- rozwiązanie ciekawe, ale nie nadaje się do wszystkiego. Myślę, że zasilanie niskim napięciem dla większych długości przewodów jest złym pomysłem ze względu na spadki napięć, a to jest bardzo istotne i daje się we znaki w większych instalacjach. Ważna jest jeszcze jedna rzecz- uniwersalność. Sieć musi posiadać możliwość podłączenia urządzeń wykonanych przy użyciu różnych CPU i różnych języków programowania. Nie można ograniczać się do bibliotek w środowisku Bascom, bo to bardzo zawęzi użyteczość sieci. W razie potrzeby można zastosować konwertery między sieciami, a da się to zrobić. Ja osobiście również zainteresowałem się jakiś czas temu tym problemem.
CAN- Bardzo ciekawa magistrala, ale bardzo skomplikowana w oprogramowaniu. Wiem od dobrego programisty, że jest sporym problemem wykonanie protokołu zgodnego pod każdym względem z normami i możliwościami. Wymaga to też sporych nakładów sprzętowych. CAN stosowany jest więc głównie w stosunkowo małych systemach, czego dobrym przykładem jest automatyka samochodowa.
Ważne jest, by sieć była tania, łatwa w implementacji, niezależna od środowiska programowania oraz od użytego CPU, odporna na zakłócenia, łatwa w diagnostyce i nie generowała zbyt wielkiego ruchu. Wiem dobrze, jak wielkie kłopoty może sprawić awaria medium transmisyjnego lub któregoś z urządzeń sieciowych. Dlatego trzeba wybrać kompromis i każdą z gałęzi sieci łączyć najodpowiedniejszym dla niej sposobem. A! Jeszcze jedna sprawa, sprawa protokołu. Nie można stosować komercyjnego, który wymaga odpowiednich licencji. Dobrze jest zastanowić się nad otwartym protokołem.
RS485- potrzebna jest skrętka, czyli dwa przewody. Zasilanie może być doprowadzone drugą parą lub lokalnie, jeśli odległość między urządzeniami jest duża. Myślę, że jest to jedno z najbardziej odpornych na zakłócenia rozwiązań.
1 Wire- rozwiązanie ciekawe, ale nie nadaje się do wszystkiego. Myślę, że zasilanie niskim napięciem dla większych długości przewodów jest złym pomysłem ze względu na spadki napięć, a to jest bardzo istotne i daje się we znaki w większych instalacjach. Ważna jest jeszcze jedna rzecz- uniwersalność. Sieć musi posiadać możliwość podłączenia urządzeń wykonanych przy użyciu różnych CPU i różnych języków programowania. Nie można ograniczać się do bibliotek w środowisku Bascom, bo to bardzo zawęzi użyteczość sieci. W razie potrzeby można zastosować konwertery między sieciami, a da się to zrobić. Ja osobiście również zainteresowałem się jakiś czas temu tym problemem.
CAN- Bardzo ciekawa magistrala, ale bardzo skomplikowana w oprogramowaniu. Wiem od dobrego programisty, że jest sporym problemem wykonanie protokołu zgodnego pod każdym względem z normami i możliwościami. Wymaga to też sporych nakładów sprzętowych. CAN stosowany jest więc głównie w stosunkowo małych systemach, czego dobrym przykładem jest automatyka samochodowa.
Ważne jest, by sieć była tania, łatwa w implementacji, niezależna od środowiska programowania oraz od użytego CPU, odporna na zakłócenia, łatwa w diagnostyce i nie generowała zbyt wielkiego ruchu. Wiem dobrze, jak wielkie kłopoty może sprawić awaria medium transmisyjnego lub któregoś z urządzeń sieciowych. Dlatego trzeba wybrać kompromis i każdą z gałęzi sieci łączyć najodpowiedniejszym dla niej sposobem. A! Jeszcze jedna sprawa, sprawa protokołu. Nie można stosować komercyjnego, który wymaga odpowiednich licencji. Dobrze jest zastanowić się nad otwartym protokołem.
-
Jurek Szczesiul
- -
- Posty: 13
- Rejestracja: 08 paź 2005, 18:20
Cześć.Sagittarius pisze:Przejrzałem link o x10... Sieć energetyczna jest ciekawym pomysłem, ale niestety nie zawsze się sprawdzi. Jeśli trafimy na bardzo zaśmiecone środowisko, mogą być problemy.
[..]
Ważne jest, by sieć była tania, łatwa w implementacji, niezależna od środowiska programowania oraz od użytego CPU, odporna na zakłócenia, łatwa w diagnostyce i nie generowała zbyt wielkiego ruchu. Wiem dobrze, jak wielkie kłopoty może sprawić awaria medium transmisyjnego lub któregoś z urządzeń sieciowych. Dlatego trzeba wybrać kompromis i każdą z gałęzi sieci łączyć najodpowiedniejszym dla niej sposobem. A! Jeszcze jedna sprawa, sprawa protokołu. Nie można stosować komercyjnego, który wymaga odpowiednich licencji. Dobrze jest zastanowić się nad otwartym protokołem.
W warunkach domowych zakłócenia w sieci będą w większości przypadków do opanowania. Przy okazji wyeliminujemy albo odfiltrujemy nieco śmiecącego osprzętu
Co do protokołów - w pewnością coś by się znalazło ale jedna rzecz do rozważenia.
Oferta różnych gadgetów sieciowych ciągle rośnie a ceny spadają. Więc może po prostu oprzeć wszystko na ethernecie + TCP/IP. Gotowe modułki np. Tibbo ( projekt we wrześniowej EP ) jako interfejsy pomiędzy uK układów automatyki a siecią. Tam gdzie będzie kłopot z okablowaniem - modemy PLC np. takie jak TU
Do tego w miarę potrzeb lokalne podsieci oparte na innych magistralach ( np. typowe rozwiązanie 1-wire stacyjki meteo itd. )
Pozdrowienia Jurek S.
-
Skrzydlaty
- Użytkownik
- Posty: 126
- Rejestracja: 23 wrz 2007, 21:08
- Lokalizacja: Krak
Koledzy! Może sie zastanówmy czy idziemy w dobrą stronę?! Szukać kompromisu miedzy taka gamą zarówno sprzętową jak i cenowa...
Nie, nie, nie! Sprecyzujmy .... albo podzielmy temat na kilka kierunków. W założeniu miała to być automatyka domowa... czyli dla każdego "domu";] moduł CAN przedstawiany w linkach w postach powyżej to ponad 70zł! Modemy i Ethernet w powyższych linkach to ok. 200zł. Nie ma sie co dalej rozpisywać - to ma być komunikacja między domowymi urządzeniami czy mamy tworzyć to co już jest stosowane w wielkich firmach i za wielką kasę. Zastanówmy sie też do czego to wszystko ma służyć. Może popatrzmy do pierwszego posta - założenia: prostota, niska cena, do zastosowania w każdym domu. A więc nie muszą to być wyszukane protokoły za kosmiczną cenę jak na zwykłego amatora. Także środowisko programowania powinno być dostępne dla każdego...a że chyba najprostszym środowiskiem i najbardziej dostępnym dla każdego będą procesory AVR i Bascom to może zastanówmy sie nad tym konkretniej....
chyba że chcemy robić drogi system zbliżony do klasy systemów w małych firmach/ fabrykach...tylko po co? I tak praktycznie nikt go nie wykorzysta do sterowania bramą czy żaluzjami..bo kto wpakuje choćby 50zł za samą możliwość podłączenia sterownika żaluzji do centralki? na pewno nie ja, wole to zrobić ręcznie
Sam muszę zrobić sterowanie kilkoma komorami grzewczymi w pewnym budynku oraz kontrolować temperaturę w kilku pomieszczeniach, do tego dochodzi extra sterowanie drzwiami i oświetleniem, plus mały systemik alarmowy. Mimo to nie zaprojektuje niczego z modułów przedstawionych w postach powyżej, co najwyżej moduły RS485. Chyba że znajdę jakaś magistrale typu 1wire.
Myślę że teraz sprecyzujemy w którą stronę chcemy iść - tani ale działający system dostępny dla każdego, czy drogi niezawodny system... z niezawodnością "na wyrost"?
A może od razu zadzwońmy do jakiejś firmy zajmującej sie profesjonalnymi systemami? przynajmniej będziemy wiedzieć że to będzie niezawodne.
Nie, nie, nie! Sprecyzujmy .... albo podzielmy temat na kilka kierunków. W założeniu miała to być automatyka domowa... czyli dla każdego "domu";] moduł CAN przedstawiany w linkach w postach powyżej to ponad 70zł! Modemy i Ethernet w powyższych linkach to ok. 200zł. Nie ma sie co dalej rozpisywać - to ma być komunikacja między domowymi urządzeniami czy mamy tworzyć to co już jest stosowane w wielkich firmach i za wielką kasę. Zastanówmy sie też do czego to wszystko ma służyć. Może popatrzmy do pierwszego posta - założenia: prostota, niska cena, do zastosowania w każdym domu. A więc nie muszą to być wyszukane protokoły za kosmiczną cenę jak na zwykłego amatora. Także środowisko programowania powinno być dostępne dla każdego...a że chyba najprostszym środowiskiem i najbardziej dostępnym dla każdego będą procesory AVR i Bascom to może zastanówmy sie nad tym konkretniej....
chyba że chcemy robić drogi system zbliżony do klasy systemów w małych firmach/ fabrykach...tylko po co? I tak praktycznie nikt go nie wykorzysta do sterowania bramą czy żaluzjami..bo kto wpakuje choćby 50zł za samą możliwość podłączenia sterownika żaluzji do centralki? na pewno nie ja, wole to zrobić ręcznie
Sam muszę zrobić sterowanie kilkoma komorami grzewczymi w pewnym budynku oraz kontrolować temperaturę w kilku pomieszczeniach, do tego dochodzi extra sterowanie drzwiami i oświetleniem, plus mały systemik alarmowy. Mimo to nie zaprojektuje niczego z modułów przedstawionych w postach powyżej, co najwyżej moduły RS485. Chyba że znajdę jakaś magistrale typu 1wire.
Myślę że teraz sprecyzujemy w którą stronę chcemy iść - tani ale działający system dostępny dla każdego, czy drogi niezawodny system... z niezawodnością "na wyrost"?
A może od razu zadzwońmy do jakiejś firmy zajmującej sie profesjonalnymi systemami?
przynajmniej będziemy wiedzieć że to będzie niezawodne.-
Sagittarius
- Użytkownik
- Posty: 130
- Rejestracja: 29 maja 2007, 9:29
- Lokalizacja: Kujawsko-pomorskie
- Kontakt:
Masz dużo racji
Moim zdaniem.... Może jestem uparty, ale chyba RS485 jest jednym z lepszych rozwiązań. Pozwala wykorzystać sprzętowego UARTa. Ja osobiście pracuję w asemblerze, ale to nie jest problem. Dajmy na to, że warstwa sprzętowa jest zdefiniowana (np. 485). Wtedy trzeba zdefiniować ramki. Wbrew pozorom jest to zadanie i łatwe i trudne. Łatwe, bo transmisja nie musi być zbyt skomplikowana, a trudne, bo w miare wzrostu liczby urządzeń, nasza ramka może się okoazać zbyt ograniczona. Jeśli tak, wystarczy ją rozwinąć i stworzyć nową wersję. Ważne jest, by taka "standaryzacja" wymiany danych między urządzeniami została zdefiniowana i udostępniona do ogólnej wiadomości. Pozwoli to innym budować urządzenia zdolne do pracy w takiej sieci. Co więcej, nie jest ważne, czy napiszemy program w pakiecie Bascom, w asemblerze, C, Pascalu, czy może w innym języku, nie jest wazne, czy podłączymy układ z AVRkiem, 8051, PIC, itd. Jeśli będzie wiadomo, jak przebiega wymiana danych, co trzeba wysłać, a co odebrać, jak duzy bufor ma być, to jest to już sukces. Zabezpieczenie transmisji nie musi być rozbudowane. Wystarczy sprawdzanie CRC. To w znacznym stopniu zminimalizuje błędy. Jeśli zaś będzie używana suma CRC, trzeba podać sposób jej obliczania. I to tyle. Do tego właśnie moim zdaniem sprowadza się projektowanie. Reszta należy do projektanta urządzenia.
Moim zdaniem.... Może jestem uparty, ale chyba RS485 jest jednym z lepszych rozwiązań. Pozwala wykorzystać sprzętowego UARTa. Ja osobiście pracuję w asemblerze, ale to nie jest problem. Dajmy na to, że warstwa sprzętowa jest zdefiniowana (np. 485). Wtedy trzeba zdefiniować ramki. Wbrew pozorom jest to zadanie i łatwe i trudne. Łatwe, bo transmisja nie musi być zbyt skomplikowana, a trudne, bo w miare wzrostu liczby urządzeń, nasza ramka może się okoazać zbyt ograniczona. Jeśli tak, wystarczy ją rozwinąć i stworzyć nową wersję. Ważne jest, by taka "standaryzacja" wymiany danych między urządzeniami została zdefiniowana i udostępniona do ogólnej wiadomości. Pozwoli to innym budować urządzenia zdolne do pracy w takiej sieci. Co więcej, nie jest ważne, czy napiszemy program w pakiecie Bascom, w asemblerze, C, Pascalu, czy może w innym języku, nie jest wazne, czy podłączymy układ z AVRkiem, 8051, PIC, itd. Jeśli będzie wiadomo, jak przebiega wymiana danych, co trzeba wysłać, a co odebrać, jak duzy bufor ma być, to jest to już sukces. Zabezpieczenie transmisji nie musi być rozbudowane. Wystarczy sprawdzanie CRC. To w znacznym stopniu zminimalizuje błędy. Jeśli zaś będzie używana suma CRC, trzeba podać sposób jej obliczania. I to tyle. Do tego właśnie moim zdaniem sprowadza się projektowanie. Reszta należy do projektanta urządzenia.
-
Skrzydlaty
- Użytkownik
- Posty: 126
- Rejestracja: 23 wrz 2007, 21:08
- Lokalizacja: Krak
A więc skoro iż przynajmniej jedna osoba poparła pomysł sformułuję wstępne założenia:
1. Protokół transmisji: 1 wire lub RS485 lub...oba naraz, zależnie od tego jakie wymagania urządzenie postawi przed protokołem transmisji. Ze względu iż najczęściej stosowanym przewodem będzie kabl wielożyłowy mogą być to oba protokoły naraz lub każdy wybierze który woli. Rzesza elektroników jest na tyle duża że każdy tworząc coś w którymś z obu protokołów da dwa protokoły a nie jeden
2.Liczba urządzeń: nie powinna być ograniczona liczbą kilkunastu lub kilkudziesięciu- 1wire daje ogromne możliwości zaś RS485 mniejsze i wymaga rozbudowania ramki adresowania....więc ramka adresowania powinna być od razu szersza.
3. Język programowania i procesor: w każdym przypadku jeśli ktoś doświadczony opisze sposób działania "po ludzku" (no i po polsku
) to reszta będzie wiedziała jak napisać do tego program w "swoim" języku , chwalebne by było gdyby ktoś napisał uniwersalny protokół, to tyczy sie zwłaszcza 1wire bo ten sposób jest nieco skomplikowany.
4. Sprawdzenie poprawności transmisji: suma kontrolna całkowicie wystarczy. W przypadku błędnej transmisji urządzenie jest pomijane i sprawdzane w następnej kolejce lub sprawdzane kilka razy co pozwala także na poinformowaniu reszty że "coś jest nie tak", lub też wysyłanie danych "do skutku".
Podsumowując wszystko sprowadza sie do opisu transmisji i rozwiązania tego programowo.
Proponuje żeby ktoś, kto orientuje sie w tych protokołach napisał uniwersalny program.... zapewne wielu jest elektroników piszących w rożnych programach zatem przy odrobinie chęci powinno coś powstać. Sugeruje, aby jakieś ewentualne programy gdyby zostały napisane to nie tylko w zaawansowanych programach ale i w prostszych dostępnych dla każdego np. Bascom, ew. C (w końcu to ma być "dla każdego" domu a więc i elektronika).
[ Dodano: 2007-10-07, 18:45 ]
Cisza w temacie???
1. Protokół transmisji: 1 wire lub RS485 lub...oba naraz, zależnie od tego jakie wymagania urządzenie postawi przed protokołem transmisji. Ze względu iż najczęściej stosowanym przewodem będzie kabl wielożyłowy mogą być to oba protokoły naraz lub każdy wybierze który woli. Rzesza elektroników jest na tyle duża że każdy tworząc coś w którymś z obu protokołów da dwa protokoły a nie jeden
2.Liczba urządzeń: nie powinna być ograniczona liczbą kilkunastu lub kilkudziesięciu- 1wire daje ogromne możliwości zaś RS485 mniejsze i wymaga rozbudowania ramki adresowania....więc ramka adresowania powinna być od razu szersza.
3. Język programowania i procesor: w każdym przypadku jeśli ktoś doświadczony opisze sposób działania "po ludzku" (no i po polsku
) to reszta będzie wiedziała jak napisać do tego program w "swoim" języku , chwalebne by było gdyby ktoś napisał uniwersalny protokół, to tyczy sie zwłaszcza 1wire bo ten sposób jest nieco skomplikowany.4. Sprawdzenie poprawności transmisji: suma kontrolna całkowicie wystarczy. W przypadku błędnej transmisji urządzenie jest pomijane i sprawdzane w następnej kolejce lub sprawdzane kilka razy co pozwala także na poinformowaniu reszty że "coś jest nie tak", lub też wysyłanie danych "do skutku".
Podsumowując wszystko sprowadza sie do opisu transmisji i rozwiązania tego programowo.
Proponuje żeby ktoś, kto orientuje sie w tych protokołach napisał uniwersalny program.... zapewne wielu jest elektroników piszących w rożnych programach zatem przy odrobinie chęci powinno coś powstać. Sugeruje, aby jakieś ewentualne programy gdyby zostały napisane to nie tylko w zaawansowanych programach ale i w prostszych dostępnych dla każdego np. Bascom, ew. C (w końcu to ma być "dla każdego" domu a więc i elektronika).
[ Dodano: 2007-10-07, 18:45 ]
Cisza w temacie???