Sieć mikrokontrolerów i wyszukiwanie

Zerkę, być może to lepsza droga, choć w moim przypadku ramki komunikacyjne powinny być znacznie powyżej 256 bajtów ... ale pomyśle o pakietowaniu w mniejszych ilościach.

Reply to
Sebastian Bialy
Loading thread data ...

Jeszcze raz powtorze-czysty RS485 tego nie przewiduje. Mozesz jednak nietypowo polaczyc typowe drivery do 485, by iloczyn na drucie uzyskac. Robi sie tak dla CAN-a.

peters

P.S. zakłÓcać :) bardzo prosze !

Reply to
peters

Z tym akurat nie ma problemu. Ja przesylam po CAN-ie takze pliki. CAN zalatwia Ci jedna bardzo wazna sprawe -nie obciazasz tak bardzo procesorow.

A tak w ogole, to chyba nie napisales jakie predkosci transmisji Cie interesuja. Ile tych danych w ogole bedzie do przeslania. peters

Reply to
peters

Mam jeden pomysl, wydaje mi sie ze dosc prosty w realizacji. Budujesz sobie siec w ktorej do Mastera podlaczasz Slave-y. Slave moze byc urzadzeniem koncowym, lub koncentratorem. Koncentrator musi miec dwa RS485. Jeden do lacznosci z masterem, drugi do komunikacji z grupa urzadzen, dla ktorych sam jest masterem. Czyli powstaje rodzaj drzewa.

  1. wprowadzasz ograniczenie na liczbe urzadzen w jednym segmencie (powiedzmy
32 lub 256). MAster niech ma numer 0
  1. wszystkie urzadzenia numerujesz nieco inaczej: numer urzadzenia bedzie sie skladal z numeru w danym segmencie i numerow wszystkich koncentratorow po drodze do glownego mastera
  2. Master odpytuje tylko urzadzenia w swoim segmencie. Te ktore nie odpowiadaja pyta rzadko.
  3. Master nie komunikuje sie nigdy bezposrednio z urzadzeniami podlaczonymi przez koncentratory. Koncentratory odpowiednio obudowuja ramki od urzadzen, moze sklejaja komunikaty od slave-ow w jeden.
  4. Podobnie jak master zachowuja sie wszystkie koncentratory.

W ten sposob mozesz podlaczyc nawet ogromna ilosc urzadzen. W latwy sposob wykrywane sa nawe urzadzenia. Awaria w pojedynczej podsieci nie psuje calosci.

peters

Reply to
peters

Tu jest mały problem. Otórz nie wiem, jakie będą mikrokontrolery i jakimi zegarami taktowane, wpięte w tą magistralę. Co prawda można założyć jakieś parametry, które można łatwo spełnić, ale nie wiem czy choćby budowa sprzętowa uC nie spowoduje problemów typu opóźnienia paru taktów. To jescze do przemyslenia.

Raczej nie chciałbym iloczynu na drucie - zazwyczaj wtedy do plusa podciąga rezystor - na długich kablach musi przeładować takie pojemności, że dużych szybkości nie dam rady uzyskać.

A z jaką predkością ? 9600 to _minimum_. Aż się prosi o 2x-4x więcej ...

Reply to
Sebastian Bialy

Od lat stosuje CAN po RS485 (iloczyn na druce). Szybkosci 125kbps do kilkuset metrow, 25kbps nawet do kilku kilometrow.

peters

Reply to
peters

Powiedzmy 20-30 urządzeń. Każde po ramce w granicach 50 bajtów (średnio), sporadycznie znacznie więcej - >300.

Całośc ma działać w taki sposób, aby użytkownik wciskając przycisk odczuwał "natychmiastową" reakcję czujnika/serwo itd. Innymi słowy max

50ms na reakcje slave, znacznie lepiej, jeśli da się szybko.

Jest jeszcze głupia sprawa - magistrala przez 99.9% czasu jest cicha. I nagle musze rozesłać do 30 slaveów masę informacji praktycznie "natychmiastowo" (w sensie subiektywnego odczucia usera). Tu by się przydało jak najszybciej.

Reply to
Sebastian Bialy

OK :)

Reply to
Sebastian Bialy

Jest jedna sprawa: chciałbym, aby numery były podczas produkcji zaszywane w urządzeniach. A takim przypadku (w jednym segmencie mała pula adresowa) nie mogę ich tam wszyć, bo musiałbym produkować urządzenia w grupach (nie powtarzajace się numerki lub konfigurowalne). Wygląda to tak, jak w protokole IP gdzie nadaje się dodatkowe numerki IP poza MAC żeby grupować stacje.

Oczywiście im mniejszy segment tym większe szanse na znalezienie slave za pomocą protokołu kolizyjnego z sumami kontrolnymi. Ponadto slave może z prawdopodobieństwem 1/32 losować, czy w ogóle się odezwać, zakłądając że zapytania są dość częste czas wykrycia slave będzie sensownie krótki.

Dokładnie tak to sobie wymyśliłem.

PS. Nie napisałem, że nie zalezy mi w ogóle na szybkości znalezienia slave (mogą być sekundy). Istotne jest żeby je znaleźć.

Reply to
Sebastian Bialy

Przepraszam, ze tak na raty odpisuje. Dla CANa nie ma to za bardzo znaczenia. Do CAN-a i tak stosujesz specjalizowane kontrolery (podpiete pod magistrale albo po SPI -chyba takie widzialem) albo uC z CAN. Kontroler zalatwia Ci tyle, ze procesor jest znacznie mniej obciazony niz w przypadku RS485 -moze wiec byc slaby.

peters

Reply to
peters

robisz tak jak w ethernecie - podsluch na magistrali. Jak inne urzadzenie zaczelo nadawac przed twoim - rezygnujesz, zglosisz sie przy nastepnym odpytaniu.

J.

Reply to
J.F.

Cel szczytny, ala po dluzszym zastanowieniu...przeciez urzadzenia musisz jakos identyfikowac, czyli gdzies wprowadzic ich numery. Chyba, ze Ci obojetne czym zasterujesz lub skad pobierzesz pomiary :)

peters

Reply to
peters

Az sie prosi o zastosowanie CAN-a. Najwazniejszy argument to wlasnie czas przekazywania komunikatow od Slave-a. Jesli masz siec z jednym masterem i stosujesz metode odpytywania

- musisz pytac bardzo czesto. im wiecej urzadzen tym czesciej. I dowiadujesz sie przewaznie, ze nie ma nic do przeslania. CAN te sprawy zalatwia, bo urzadzenie samo zaczyna nadawaie.

Zostaje jeszcze problem z wieksza iloscia urzadzen. Mozesz zaprojektowac proste repeatery, uklady z dwoma CAN-ami. Co zostanie odebrane na jednym CAN-ie za chwile nadawane jest na drugiego.

Numerujac urzadzenia musialbys sie ograniczyc do 29 (lepiej 28) bitow. Ale to i tak ponad 250 milionow urzadzen. Jesli nie musisz rezerwowac puli numerow dla roznych producentow-to spokojnie wystarczy.

peters

Reply to
peters

Małe ramki w CAN są po to, aby to co ma dojść szybko (alarmy) mogło się wciąć (ma wyższy priorytet) w dowolną inną transmisję danych. P.G.

Reply to
invalid unparseable

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.