Chciałbym zrealizować sieć małych urządzeń opartych o mikrokontrolery AVR. Sieć powinna mieć możliwość podłączenia co najmniej kilkudziesięciu węzłów (tych urządzeń), przepustowość wystarczyłaby 115kbit/s, multi-master, na odległości do 100m, połączenie na przewodzie dwużyłowym. Zastanawiałem się nad CAN, ale do tego musiałbym użyć np. SJA1000 i
82C250, a koszt obu to już ok 30 zł - co przy przewidywanej dużej ilości urządzeń bardzo zwiększyłoby koszty projektu. Od biedy można by zrobić, żeby kontroler CAN był programowy w AVR, ale to dość roboty, to raz, a dwa, żeby było legalnie, to trzeba chyba płacić za licencję Bosch'owi. Poza tym musiałbym w takim przypadku solidnie przeczytać dokumentację do CAN, a na to nie mam za dużo czasu/ochoty ;) Macie może jakieś wskazówki, jak powinienem to zrealizować? Jaki protokół, co od strony sprzętowej?
Użytkownik "ioj" snipped-for-privacy@wp.pl napisał w wiadomości news:cnl65t$khh$ snipped-for-privacy@bandai.magma-net.pl
A czemu nie RS485? Bez problemu i to za niewielkie pieniądze znajdziesz drivery wnoszące połówkowe (1/2 U.L.) a nawet mniejsze obciążenie magistrali co daje Ci 64 węzły lub więcej. Od strony AVR-a wykorzystujesz UART-a + dodatkową linię do sterowania nadajnika. Tyle, że na własną rękę musisz wyczarować wiarygodny protokół multi-master. Aha... dzisiaj w nocy pisaliśmy na temat celowości stosowania trzeciego przewodu do łączenia mas interfejsowych - możesz do tego zajrzeć.
Użytkownik "ioj" snipped-for-privacy@wp.pl napisał w wiadomości news:cnl87e$31i$ snipped-for-privacy@bandai.magma-net.pl
SNAP jest fajny, skalowalny a przy tym bajecznie prosty. Jednak nie da się go prosto wykorzystać, z dwóch wzgledów:
- został opracowany pod kątem uzycia w sieci modemów PLC i korzysta z wystawianego przez nie sygnału CarrierDetect. W gołym RS485 nie masz sygnału CarrDet (nie skracam jako CD, żeby się nie myliło z Collision Detection). Zresztą w ogóle pojęcie _nośnej_ nie mieści się w standardzie a określenie co oznacza stan carrier_detected należy do użytkownika. Np. stosując transmisję asynchroniczną start/stopową, możesz uznać, że CarrDet jest aktywne przez okres równy czasowi transmisji 1.5 _bajtu_ od ostatniego wykrytego zbocza. Albo wpuszczać w magistralę pakiety kodowane Manchesterem a wtedy do zdjęcia CarrDet wystarczy odczekanie trochę więcej niż czasu trwania jednego _bitu_. Jednak za każdym razem musiałbyś dołożyć coś jeszcze w sprzęcie i/lub oprogramowaniu. Np. podać Rx również na we INT i wykrywać _każde_ zbocze wystepujące na magistrali podtrzymując flagę CarrDet. Co nie brzmi zbyt zachęcająco. Z drugiej strony... mam wrażenie że widziałem jakieś nowsze TRx-y 485 z funkcją CD, choć diabli wiedzą jak zrealizowaną.
Ponieważ odbiornik RS485 w halfduplex-ie może słuchać tego co się dzieje na linii w czasie pracy własnego nadajnika, myślałem też kiedyś o wykrywaniu kolizji (zrobieniu czegoś w rodzaju CSMA/CD na RS-ie). Kwestię CarrierSense wyjaśniłem powyżej. Natomiast CollisionDetect ma prawo nie zadziałać. Przy długiej magistrali, choć mieszczącej się jeszcze w granicach normy, kolizja z odległym nadajnikiem nie zostanie wykryta.
- AFAIR w SNAPie nie określono żadnych tiemout-ów, postępowania w razie kolizji itp.. W realnej sieci to wszystko wymagałoby doprecyzowania.
Już miałem pisać nowy wątek, ale skoro tutaj własnie jest rozmowa o protokołach to się podepne ;)
Mam pewne urządzneie pomiarowe pracujace po RS485 i chodzace w MODBUSie niestety w trybie RTU (co mi troche utrudnia synchronizacje, trzeba jakies timeouty liczyć :/, ASCII byłby łatwiejszy). Poza tym jednym fabrycznym na modbusie nie ma innych fabrycznych, reszte szyje sam.
Czy ktoś mógłby zasugerować czy mam opracowywać własny protokół (modbus mi się nie podoba, choć od biedy by wystarczył) czy pchać wszystko w MODBUS.
Konkretnie moje pytanie jest raczej takie: czy robiąc resztę urządzeń na modbusie nie zobie jakoś mało zgodnych z resztą świata, w końcu zapewne w przemyśle używa się jakiegoś (jakiś) protokołu komunikacyjnego. Czy modbus to dobry wybór zakładając że nie chciałbym się ograniczać do tego jednego projektu ? Czy popularny ?
Nie. 1-Wire nadaje się tylko do małych odległości i małych przepływności, jest dość podatny na zakłócenia (w porównaniu z różnicowym RS485), poza tym najczęściej spotyka się konfigurację z jednym masterem. Czy 1-Wire jest dobrze przystosowany do multimaster - nie przypominam sobie.
Adam Dybkowski snipped-for-privacy@amwaw.edu.pl> napisał(a):
Autor postu pisał o 100 m i 115 kbit/S , więc wydaje mi się że 1-Wire spełnia ten warunek,a jeśli chodzi o multimaster,to już inna bajka - do napisania ;-)
Czesc. Jesli chodzi o CAN-a to mozesz zastosowac drivery od RS-485. Podlacza sie go w ten sposob, ze sygnal nadawania podlaczasz na DE. Z punktu widzenia kontrolera CAN masz cos w rodzaju iloczynu po drucie. Zdecydowanie najwygodniej zastosowac procesor z wbudowanym CAN.
Podobny mechanizm mozesz oczywiscie zrealizowac programowo. Musisz sie jednak liczyc z faktem, ze znacznie obciazy to wszystkie procesory. Jakakolwiek transmisja bedzie przerywala ich normalna prace.
Jesli chodzi o inne pomysly na multi-master, mozna sprobowac protokolu opartego na szczelinach czasowych. Ma to sens chyba tylko wtedy, gdy wszystkie procesory ciagle maja cos do nadawania, a muliti-master jest potrzebny tylko po to, by awaria glownego sterownika nie powodowala, ze calosc systemu wysiada. Pozostaje do rozwiazania problem synchronizacji. Musi ja przejmowac jeden z procesorow, jesli go zabraknie-musi przejac jego role inny.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.