A feladat hogy 3 vagy annál több AVR-t kellene kommunikációra bírni nagy (esetlegesen 40-50-100m) távolságon.

Mit javasoltok?

Azért nyitottam új témát mert bárhol is olvastam nem találtam hasonló megoldást. Nem kell vezeték nélküli meg rádió meg miegymás csak a kommunikáció a mikrovezérlők között.

I2C lenne a legjobb PIC-el meg is oldottam 4 Vezérlő közt a kommunikációt biztos menne AVR-el is de tudtommal eléggé be van szabva a vezeték hossz.

SPI-t nem nagyon ismerem de az sem lehet akadály biztos megoldanám csak ott is a távolság befolyásoló tényező.

Esetleg RS-485 de az csak 2 vezérlő közt megy vagy nem?

Az adat amit küldeni kellene minden slave AVR mérne egy értéket(hőmérséklet, fény bármi...) és azt küldené el a központi Master-nek ami különböző műveleteket végezne parancsokat futtatna a megkapott értékek alapján. Azért fontos az Slave-nél is a mikrovezérlő használata, mert így több lehetőség lenne bármilyen mérési eredmény feldolgozására és megnőne a felhasználható szondák száma is mert a slave-avr dolgozná fel, a bármilyen szondából érkező adatot és csak az eredmény küldené tovább a masternek(hőmérséklet C, fény LUX, stb...)

Lehet akár minden vezérlő Mega16 vagy bármi.

Várom segítségeteket véleményeteket.

RS485 32 eszközig biztosan jó, bizonyos vezérlőkkel több is lehet. Vagy CAN.

Szóval RS485 most olvastam utána és tényleg több eszközt lehet rá kötni csak azt nem tudom hogyan mert én az UART-ot mindíg a szgép kapcsolatához használtam. :-S

Az RS-485 csak a csatolófelületet jelenti, a rajta használt kommunikáció már a te dolgod. Pl. a master kiad egy azonosítót, aztán x ideig vár, hogy az adott azonosítón levő slave választ adjon, aztán kiadja a következőt, stb. A slave-ek így csak akkor dumálnak, ha engedik nekik, nem lesz összeakadás.
Persze ezt is kitalálták már, pl. használhatod ezt is akár.

Akkor ha uart-on kiküldök egy kódot amit azonositonak nevezek mondjuk akkor amelyik slavenek az azonositojaval megegyezik visszaküldi egy jelet. Ha jól gondolom.

Igen, de persze ha megfelelő a programod hozzá. Magától nem fog küldeni semmit, meg kell írni a programot. Mondjuk egy DIP kapcsolóval beállítod a slave-k címeit, programból ezt beolvasod, és ha a DIP kapcsolónak megfelelő című csomag jött, akkor válaszolsz, egyébként nem. A Benbus mellett a másik lehetséges ,egyszerű megoldás a Modbus (lásd csatolt pdf).

Értem és világos most dolgozom de du. este ki fogom próbálni hogy hogy működik.
Még egy kérdés ha az RX TX szálra több U is fel van fűzve és a masterről küldök egy adatot azt mind megkapja igaz?

Ebből következik hogy csak az válaszol amelyiket én akarom. Ha jó amit leírtam akkor értem és menni fog.

Beszámolok a fejleményekről amint jutok valamire.

Azt ne feledd, hogy az RS-485 alapból half duplex, szóval váltani kell adáshoz, vételhez, vagy két busz kell. Egy érpáron egy irányba tud egyszerre kommunikálni, szóval a full duplexhez 2 (csavart) érpár kell.
Vagyis, ha kétvezetékesre csinálod, akkor az rs485 illesztőnek meg kell mondani, hogy most ad, vagy vesz, egy külön lábon, általában van rajtuk driver, receiver enable láb, azokat egy külön mikrokontroller portra kell kötni.
A half duplex megoldásnál pl. a slave-ek alapból vételen vannak, és csak akkor váltanak adásra, ha a master igényt küld nekik, és arra válaszolnak. (illetve csak az amelyiket megcímezte a master..)

Nem tudom az AVR-ek tudják-e kezelni a 9. bitet, mert ha igen, akkor könnyű azonosítania a Slaveknek a címet. Ha a 9. bit 1 akkor cím, ha nem akkor megszakítást sem okoz. Ezzel egy csomó időt lehet nyerni a Slavekben és egyértelművé válik a címzésre reagálás, azaz az adatok nem okoznak megszakítást a Slavekben.
A protokol is épülhet erre, miután a modbusnál időzítéssel oldják meg a cím figyelést, itt erre nem lenne szükség. A többi lehetne ugyanaz, vagy olyan, amilyet akarsz! Nekem is egyedi az egész (PIC-ekkel).

A másik lehetséges megoldás, hogy az I2C-re drivert tenni. Ilyet még nem próbáltam, de meggyőztek, hogy elvileg lehetséges. pl. egy FET kapcsolgatná a vonalakat, amin 10...100ohm felhúzó lenne... Egy próbát megér, mert elég gyors(1...10Mbps), és egy szál vezetéken megy a dolog. A többi ugyanaz, mint ha USART lenne...

Szerintem az nem gond, ha nincs 9. bit támogatás, legfeljebb eggyel kevesebb a hasznos adatbit. Viszont ami kötelező: valamilyen checksum. Egy szimpla paritásbit is több, mint a semmi, de az egy csomó hibát nem tud megfogni. Rendes checksum esetén meg amúgy sem a bitek száma lesz az izgalmas, hiszen alapból több byte-osak lesznek az üzenetek.
Az időzítést nem tudod kiküszöbölni, mivel a masternek valamennyi időt kell adnia a slave számára, hogy megszólaljon, és addig úgy sem kérdezhet mást. Azt, hogy a megszólítást jelezze a master, meg megteheti pl. BREAK útján is, ami egyúttal mindenki mást is hatékonyan letakarít a buszról.
Csavart érpár nélkül nincs hatékony zavarvédelem, tehát dobozon, készülékházon kívül csak kis sebességet tudsz elérni, akár I2C, akár nem az (szimmetrikus vagy csavart érpáras I2C-t mondjuk még nem láttam). 10 méterekre amúgy semmilyen protokoll nem fog Mbps-eket nyomni egy szál vezetéken (na jó, de, egy xDSL-modem talán, de az itt nemigen játszik).

Az I2C értelmetlen lenne csavart érpáron, ugye akkor a clock meg data vezetékeket külön kéne vinni, így 2 érpáron lenne egy half-duplex átvitel. Nem is erre van kitalálva, akkor kell, ha az ember alapból I2C perifériákat használ. Ha úgyis mikrokontroller van mindkét végén, akkor minek. Az UART viszont normálisan le van kezelve az AVR-ekben, saját pufferrel, megszakításkezeléssel, stb. és a fent leírt feladathoz half duplex, így 1 érpár bőven elég, gondolom nem kell másodpercenként több ezer mérést csinálni.

Remélem eddig jól értettél mindent az általad olvasottakból, és természetesen a 485-ös vezetékpárra felfűzött, s vételre állított slave-ek mind megkapják az adatot az adásra állított master-től. A master az adás után vételre áll, illetve az a slave, amelyik felismerte a saját címét, adásra kapcsol. Az az információ, amelyiket a slave ad, persze eljut nem csak a masterhez, hanem a többi slave-hez is, mivel ők továbbra is vételen állnak.

Kissé rendezettebben: mind HW, mind SW oldalról számos buktatókon át kell vergődnöd!

HW oldalról - ahol a 485-re illesztéshez valószínűleg a 75176-ot használod:
- Ügyelni kell a helyes polaritásra a vezetékpárnál, azaz mindig az A-t az a-bal, a B-t a B-vel kötjük össze.
- A legszerencsésebb a lác-szerű összekötés, ahol a lánc két végét zárjuk le 120 ohmmal, és a köztes pontokon a lehető legrövidebb vezetékkel kapcsolódunk a 75156 a és B pontjára (max. kb 1m).
- Ilyen nagy távolságokon fontos a zajvédelem is. Szerencsére a közismert CAT5-ös UTP kábel egy csavart érpárja megfelel az átvitelre. Ha erős elektromos zavar van az útvonalon, akkor UTP helyett használhatunk STP-t (árnyékolt). Kerüljük az erős mágneses jelforrásokat (erősáramú trafók, relék, stb.).
- Adott esetben, ha az egymástól távoleső helyszínek között nagy potenciálkülönbség, vagy ingadozás várható, OPTO leválasztást kell alkalmazni a 75176 vezérlő jeleinél (RX, TX, adatirány). Itt javasolt a 6N137-s OPTO-csatoló (3 db), amely gyors is, és a kimenetén rögtön TTL szintet ad.
- Probléma szokott lenni, ha a vonalra egyik pontra sem tesszük fel az A és B vezetékekre a "széthúzó" ellenállásokat, mert ha netán minden egység vételre állna, akkor hamis jeleket érzékel a zajból a 75176.
- Átviteli sebességként minél nagyobbat választunk, annál többször lesz vele problémánk. A 9600 b/s (esetleg a 19200) még jó szokott lenni, de erős környezeti zavaroknál lehet, hogy akár 1200-ra le kell menni.

SW oldalról a nagy távolság miatti zavarvédelem biztosítása okán a feladat nem túl egyszerű, és kezdőknek sokat kell vele kínlódniuk.
- Mindenképpen valamilyen egyszerű átviteli protokollt kell kidolgozni, hibavédelemmel és a hozzászólásokban említett címekkel. A hibavédelem egy egyszerű ellenőrző összegnek az átvitele pl. a kommunikációs csomag végén. Ha a vevő úgy érzékeli, hogy ez nem stimmel, a csomagot el kell dobnia!
- Javasolt a csomagot indítani olyan 2-3 szinkronizáló bájt értékekel, melyek egy csomagon belül nagy valószínűséggel nem fordulnak elő ilyen sorrenben. A vevőknek ezek e bájtok jelzik a csomag elejét.
- Minden csomagban ott kell lenni a címnek, hogy az kinek szól, azaz a válaszcsomagban is (tehát a masternek is van címe!).
- Az átjött csomagot vissza kell igazolni. Ez lehet maga a válaszcsomag is. Mivel átviteli hiba miatt csomagok veszhetnek el - amennyiben ez a vesztés problámát szülne - a csomagokon belül legalább 1 bájtos sorszámot (azonosítót) is küldenünk kell, és a visszaigazolásnak ezt vissza kell küldenie.
- A visszaigazolásra egy időtúllépést (TIMEOUT) kell meghatároznunk. A válasznak ezen belül kötelezően kezdődnie kell, és ez alatt a master nem állhat adásra. Ha nem jön válasz, akkor vagy a küldött csomag, vagy a válasz elveszettnek minősül, és a master ujra jogot kap arra hogy csomagot küldjön.

- A legkacifántosabb probléma a mikrovezérlők USART-jában rejlik. Ezek, ha átadtuk a csomag utolsó bájtját, akkor jelzik annak átvételét de legtöbbször (pl. a PIC-eknél) arra nincs jelzés, hogy ennek a bájtnak az utolsó bitje is kikerült a vonalra. Tehát, ha az utolsó bájt átadása után rögtön vételre állnánk, akkor hibázunk, mert a bájt még nem került ki. Az egyik megoldás a várakozás 1 bájtátviteli ideig, majd ezután átváltás. Ez pl. a PC-ken nem jó ötlet, mert ott - az oprendszerek multiprogramozott volta miatt - a várakozás nem kézbentartható, s ha késünk az átkapcsolással, akkor pedig a válaszcsomag elejét tesszük tönkre. A másik megoldás a csomag után egy fiktív bájt kivitele. Ezt csak akkor veszi át az USART, ha az utolsó hasznos bájtot már kiküldte. Ha ezt követően kapcsolunk vételre, akkor persze ez a fiktív bájt sérül, és a vevő kerethibás karakternek véli. Csakhogy ez már a lezárt csomag után érkezik neki, és - felkészülvén rá - eldobhatja.

(u.i.: az utóbbi hozzászólások, amikor ezt fogalmaztam, még nem voltak számomra ismertek. Azokhoz most csak annyit: I2C-t én sem javaslok! Van akinek vele kapcsolatban még egy panelon belül is voltak problémái kb. 20 cm távolságon!).

Gondnak nem az, de sokkal egyszerűbb, ha van. Nyílván a Master várakozik, de csak a válaszra, vagy ha nem jön, időtúllépéssel vált a következőre. Sajnos ezek a vonalak nagyon belassulnak, ha valamelyik, vagy több Slave nem válaszol, de akkor egyszerűen meg kell javítani azt!

A CRC nem gond, szinte magától értetődik. A legegyszerűbb a CCITT, mert kicsi táblázata könnyen befér a MC-be és gyors.

Az I2C-vel én is szkeptikus vagyok, de egyre többen bizonygatják, hogy működik. Élő példa erre az 1 Wire protokol. Az is csak egy szálon megy. Igaz nem túl gyors, de ez a vonal lezárásán és meghajtásán is múlik. De szerintem is RS485 a nyerő és a nyugis megoldás.

Hello!

Nagy távolságoknál én először a reflexióval számolnék(lásd: távvezetékek).
Hogy laikusok is megértsék: ha a vezeték másik végén lévő cucc bemeneti ellenállása "nagy",
akkor a jel, amint eléri a végét, vissza fog pattanni, méghozzá az adó által gerjesztett jellel
MEGEGYEZŐ POLARITÁSSAL.
Azaz T idő múlva az adó kimenetén akár 2-szeres feszültség is megjelenhet,
vagy negatív feszültség is! Ha pedig zárlat van, az adó csak a visszapattanó jelből fogja
érzékelni(ami már ELLENTÉTES POLARITÁSÚ, tehát kioltja az adó jelét).
A T időt pedig úgy számoljuk hogy a vezetékben a jel egy métert ~5ns alatt tesz meg(5ns/m).
Egy 100 méteres vezetéknél így 500ns, de mivel 2-szer teszi meg az utat, 1us.

Ezért:
1: Az adó kimenetére - hacsak nem erre a célra készült illesztő - védődiódák kellenek,
hogy a visszapattanó jel feszültséglöketeit levezessék. Schottky a legjobb ide.
2: A bitidő mindig nagyobb legyen, mint T. 100 méternél ez 1us - 1MHz.
De stabil kommunikációt 100 méter vezetéken 5V jelszintekkel 10kHz fölött ne várjál!

Egyebek:
Egy hosszabb vezetéken más adók(pl. mobiltelefon, mikró) jelei is megjelenhetnek, és ezek
olyan feszültséget is gerjeszthetnek ami a kommunikációt, és az eszközöket is károsíthatja.
Ezért a vezetékek végére 100Ohm-os lezáró ellenállásokat szoktam tenni. Ez a reflexiót is legyengíti!
De vigyázz: a vezetéknek is van ellenállása! A lezáró ellenállásnak maximum a tizede lehet!

Amennyiben mérések központi gyűjtéséről van szó, akkor van egy másfajta szervezési mód, az előzőekben elhangzottaktól eltérően.

Itt bizonyos időközönként - pl. percenként - minden adatgyűjtő készüléknek van egy időszelete, amikor leadja az adatcsomagját. Pl. az I. készülék az 5. másodperctől, a II. a 10. másodperctől, és így tovább. Minden készülékben realizálva van a szinkronizáláshoz egy óra, ami jelzi, hogy a percen belül melyik időtartományban vagyunk.

Mivel az órák egymástól elcsúszhatnak, az állandó szinkronitást a központi adás biztosítja. Neki nem feladata az adatok lekérdezéséhez címzett csomagot küldeni, csupán a perc kezdetét jelzi (pl. a 0. másodperc időpontban), és legfeljebb egyéb vezérlő információkat küld a készülékek felé, mondjuk a mérési módok megváltoztatására. Az összes adatgyűjtő figyel erre az adásra, és a kezdet észlelésével korrigálja a saját órájának az elcsúszását. A többi időpontban ezek az egységek nem törődnek a vonalon megjelent információkkal.

Ha egy egység az óráját figyelvén érzékeli a saját időszeletének a kezdetét, akkor megkezdi az adását, és elküldi a mérési adatokat. Bár nem lenne szükséges az egység sorszámát ilyenkor elküldeni, hiszen az időszelet azonosít, mégis - ellenőrzés céljából - érdemes ezt az adatot is továbbítani.

A központi egység egymás után veszi az adatcsomagokat, és mindig tudja (az időpont alapján), hogy melyik egységről van szó.

Természetesen az adatokat itt is érdemes ellenőrző összeggel ellátni (s lehetnek szinkron bájtok is). Egy hibajavító módszer lehet, ha a mérési adatokat egymás után többször (pl. 3-szor) elküldjük az időszeletben. A hibák ugyanis legtöbbször csomókban jelentkeznek, s egy hibás blokk eldobásával, egy megismételt hibátlan blokkból kinyerhető az adat.

Az egyes időszeletek között - az elcsúszhatóság mértékétől függően - meghatározott idejű rövid szüneteket (GAP-ek) szokás tartani az átfedés elkerülésére.

Azért a TRMT bit szerintem jelzi. (bár azt nem tudom minden PIC-ben van-e.)

Igazad van (nem jól emlékeztem): lekérdezhető, de megszakítást nem tud rá adni, még a 18F4620-ban sem, sőt a legújabb fejlesztésű Enhanced sorozatban (pl. 16F1939) sem.

Viszont van olyan PIC (pl. a PIC32MX család), ami képes az RS485 számára szükséges driver enable vezérlőjel előállítására hardverből (tippem szerint a 16-bites PIC-ekben is hasonló tudású periféria van, de azokat nem ismerem).

Sziasztok

Azt nem tudom mennyire aktuális a dolog, de én is a kommunikációs formával küzdök.

RS232 szabvány... kötöttek és kis távolságú kevéssé zavarvédett...

RS422/458 egész jó lenne de a vonalat zárogatni kell 120 k ellenállással....

UART..I2C ahhhh...

Na meg a csavart érpárok árnyékolások és a többi vesződés.....

Mindezek helyett kellene valami ami tényleg működik is !!!!!!

Van egy megoldás: 2 vezeték amin a táp megy és a kommunikáció is ezen zajlik, nem kell csavart érpár és nem kell lezáró ellenállás... 100 m is átvisz és felfűzhető rá 255 eszköz és szuperül megy a kommumikáció, még sosem hibázott !!!

Na ez az ami kell !!! Mivel ez egy kaputelefon rendszer és nem tudom a programot ezért teszem fel a kérdést, hogy hogyan lehet megcsinálni?

Amit tudunk a központ (MESTER) kiad a táp vonalra X számú negatív tüskét, ekkor a megfelelően felcímzett SLAVE válaszol és csenget majd figyelve a kézibeszélőt, átáll beszéd módra.

Ezt a kommunikációt kellene megfejteni... ez jelenleg PIC ek között zajlik és az egyik egy nagyon pici tudású 12f508 tehát nem kell hozzá mindenféle RX/TX UART stb tudás sem !!!!!

Azt gondolom hogy a táp vonal a készüléket ellátja energiával, puffer kondi stb.
és a pozitív be van kötve a PIC egyik bemenetére is védő ellenállással vagy fesz osztón keresztül és így figyeli az adatokat a vonalon.

A program meg figyeli ezt a lábat és gyűjti az inpulzust, amit összehasonlít egy JUMPER soron beállított címmel ami az ő címe és ha egyezik akkor elkezdi az aktív működését : válaszol csenget és beszédre kapcsol......stb

Ha egy ilyet össze tudnék hozni akkor azt már lehetne tovább bővíteni is.
Pl: 2 irányú kapcsolat. Tovább lehetne fejleszteni hogy legyen a mester kérésére egy nyugta válasz meg vissza adat és ismét nyugta, amiből a master el tudja dönteni hogy az válaszolt e akit kérdezett és hogy az adat is rendben megjött e. Így a zavarvédettség is meg lenne oldva,mert ha nem ok a kapott adat akkor eldobja és ismét kérdezi az adott slave eszközt, ha meg minden rendben akkor kérdezi a következőt.

Valakinek van tapasztalata ebben ?

Használj Pl 18F46K22- t vagy 18F67K22t ezekben van 2db soros port. (Vagy kisebb ---22 végű) Így egyszerre adni és venni is tudsz. Az RS-485 megduplázva RS422, saját rendszered azt programozol rá amit akarsz. A szimpla RS485-höz van egy illesztő IC, ami lekezeli az átvitel vezérlést a mikrokontrollel. Nincs ütközés a vonalon elvileg 1000-1200m-ig jó lehet. Az egész rendszert sodrott érpárú árnyékolt UTP kábellel össze lehet kötni. 2x2 párhuzamosan a táp a többi az adatkommunikáció, (RS422) vagy 3x2 a táp és 1x2 sodrat az RS485. ez 26db készülékkel biztosan megy. 2-3 ilyen rendszert csináltam, vegyesen PLC és mikrokontroller, stb...100-200m távolságban.
akeebaby-nak: Amit leírtál az lehet soros kommunikáció, az adat a tápról le van csatolva, vagy hasonló módon,... ha Intelligens eszköz van mindkét végén, rengeteg variáció lehet. Egyébként, az UTP kábel elég olcsó, nem kell spórolni az erekkel.

A környezettől függően szóba jöhetnek még a rádiós modulok.
PL.: Link

BlackNet

Szia,

ez nagyon érdekes !!! és amit így átfutva a dolgot, megegyezik azzal amit keresek !!!

Idő és eszköz hiányában még nem tudok vele kísérletezni, de hamarosan megjönnek a próbapaneljaim és akkor neki is állok

Köszönöm !!!


Esetleg van gyakorlati tapasztalatod is benne ?