To sigurno i sam znaš, ali da odgovorim onima koji se interesuju za temu:
To se tako ne radi, po pravilu bi trebalo da kabel koji služi za komunikaciju bude:

1) Odvojen od energetskih kablova, barem time što bi se kablovski kanal podelio na dva dela,
jedan deo za energetske kablove, drugi za komunikaciju(CAN, RS485, LIN, Ethernet..)

2) Kabel bi trebao da bude širmovan(masa samo na jednom kraju širma!), i da ima definisanu impedansu
i da je na početku i kraju terminiran otpornicima vrednosti te impedanse.

3) Topologija mora biti linearna, sa eventualnim izvodima sa strane koji ne bi trebali biti veći od 0,5-1metar.


Moraš da ga ubediš da se to tako radi i da je to industrijski standard, sve ostalo je fuš.

Uostalom ne verujem da je varijanta transivera za 24V otpornija na smetnje od one za 5V-3,3V.
Tipični transiver kao PCA82C250 ili MCP2551 ili TJA1050 mogu na strani busa da podnesu napone i preko 30V,
bitno je koliko je potiskivanje zajedničkih smetnji i u kom opsegu ulaznog napona. Pogledaj neki Datasheet

MCP2551 može da radi na 24V, ali mislim da ćeš sa povećanjem napona
malo šta dobiti. Pokušaj da staviš što manji terminator - otpornik.
Za pomenuti driver on može da bude minimum 45 oma, znači po 90 oma
na jednu i drugu stranu, to bi trebalo da pokupi dosta smetnji.
Inače i ja moram da uradim nešto slično, pa me baš zanima kako ćeš
sve to završiti.

Da pojasnim prethodnu poruku.
Treba uzeti u obzir princip rada CAN magistrale.
Ako na TXD imamo 0, CANH se drajvuje prema
Vdd, a CANL prema Vss ili ti GND.
U tom trenutku razlika napona je približno Vdd,
pa na RXD imamo 0, jel.

U suprotnom slučaju, ako nam je TXD=1, i CANH
i CANL su otkačeni, te je razlika napona 0V.
U ovom momentu na smetnje utiču jedino otpornici
za terminaciju, odnosno napon napajanja nema uticaja.
Što su otpornici manji, to su smetnje manje.

Ako sam negde pogrešio slobodno me ispravite,
trenutno sam i ja u procesu proučavanja CAN-a.

Evo i sličica da bi bilo jasnije:

Ceo dan sam gledao razne Datasheet-ove. Ali imam posla sa masincima koji prodaju komandni orman, motore i ostalu mehaniku, a kupac (koji je jos i manje obrazovan) sve to sa nekim majstorom povezuje. Sumnjam da mnogi od njih i neznaju za sirmovan kabl. Ranije verzije tog uredjaja nisu imale nikakvu komunikaciju i kupci su navikli na obicne zice, znaju gde da ih kupe i sada je sirmovan kabl za njih potpuna nepoznanica, zbog cega imaju otpor da kupuju ovu verziju sa serijskom komunikacijom. Do sada sam radio sa RS485 i sirmovanim kablom i prodato je oko 30-tak uredjaja, ali kada ne bi bilo otpora od musterija prema sirmovanom kablu mislim da bi prodaja isla lakse.

Nasao sam LT1796 za koji stoji da je maksimalni napon napajanja 44V, ali sve karakteristike su date za 5V, osim za struju kratkog spoja. Danas sam malo blje pogledao njegov opis, i stoji da moze da radi sa 44V ali samo ako nije zatvoren karakteristicnom impedansom jer bi struja bila toliko velika da bi se iskljucio. Ako se zatvori karakteristicnom impedansom, radni napon ne moze biti mnogo veci od 5V jer bi kolo mnogo disipiralo i opet bi se zbog pregravanja iskljucilo. U opisu stoji: "High output current drive allows the use of inexpensive PVC cable with impedance as low as 72Ω". Imunost na sumove zavisi od histerezisa na prijemu. U opisu nije data zavisnost histerezisa od napona napajanja vec stoji da je 70mV na 5V.

E sad, razmisljam da odustanem od CAN formata podataka, vec da zamenim RS485 drajver CAN drajverom. Bodova brzina je mala 9600 pa je za jedan bit stabilan nivo oko 100us. Ako bi koristio CAN, cak i na frekvenciji od 10KHz, on za svaki bit ima 10 perioda, jer se svaki bit sinhronise a vrednost bita je validana posle 7-e periode. Iz ovoga zakljucujem (mozda i gresim) da ce SCI na 9600 boda biti pouzdanija od CAN formata podataka. Osim toga za ovako malu brzinu oblik signala ne zavisi od toga kojom je impedansom zatvoren kabl. Vrsio sam merenja na duzini od 60m i nisam video nikakve promene u obliku signala kada sam menjao zavrsnu impedansu od 50 oma do 1koma.

Inace CAN protokal mi nije neophodan jer se komunikacija odvija po sistemu master - slave.

Sta mislite?

Pozdrav.

Koliko sam ja shvatio tebi treba "CAN Transceiver", pa probaj pod tim nazivom da ga trazis na google.

Npr.
http://ww1.microchip.com/downloads/en/DeviceDoc/21667d.pdf
• Suitable for 12V and 24V systems

Da neće se menjati oblik signala, ali uticaj smetnji će biti daleko manji sa 50 oma.

CAN interface je namjenjen za automobile(provobitno) i industrijsko okruzenje, sto znaci za okolinu sa smetnjama. Bez obzira na trajanje bitova i njihov fizicki oblik na prenosnim linijama, kod CAN-a postoji i posebno kodiranje poruka koje omogucuje detekciju i korekciju gresaka (to su tzv. error detection i error correction layeri), To je ugradjeno u CAN controler tako da korisnik to ne vidi "direktno". Odnosno, podaci se ne prenose u sirovom obliku nego u kodiranom. Zbog toga je statisticki gledano broj gresaka koje CAN ne detektuje/popravi izuzetno mali (otprilike, prije ti automobil ode na otpad od starotsti nego sto se desi 1 pogresna poruka na CAN-u u njemu, mozes sigurno da nadjes na internetu "error rate" ako te zanima).
Nisam siguran da li SCI ima error correction ili bar error detection layer, ali mislim da nema. Tako da sto se tice ovog industrijskog okruzenja, ja bih se svakako odlucio za CAN.



... jer CAN ima ne samo CRC, vec 5 mehanizama detekcije gresaka, 3 na nivou poruka i 2 na nivou bitova.

_{[Ovu poruku je menjao Odin D. dana 21.01.2009. u 21:15 GMT+1]}

@korak
Pa pazi, na fizickom nivou ni CAN ni RS485 se ne razlikuju. I jedan i drugi imaju diferencijalni ulaz, i upravo to je ono sto ih cini imunijim na smetnje. Ali CAN na visim nivoima ima dodatnu vrednost - korekciju gresaka.

Pretpostavljam da mikrokontroleri sa kojima radis vec imaju integrisan CAN protokol. Za RS485 morao bi sam pisati algoritam za detekciju i korekciju gresaka. Nije da je tesko, ali sa CAN je sve prepusteno hardveru.


@Odin D
Postoji i novija verzija datasheeta 21667e
The MCP2551 provides differential transmit and receive capability for the CAN protocol controller and is fully compatible with the ISO-11898 standard, including 24V requirements.

Nazalost, iako je kompatibilan sa 24V, Vdd za MCP2551 ne sme preci 7V (preporuceno 4,5 do 5,5V), pa to nije ono sto bi korak zeleo.

Ja mislim da napon napajanja cipa (elektronike) nema veze sa onim 12/24 V. To se odnosi na okruzenje u kojem cip radi i na moguce smetnje i probleme koje mu mogu uzrokovati ti naponi. Auto elektrika radi na 12V, kamioni i industrija na 24V. 12/24 znaci da se cip moze koristiti u oba okruzenja. Pretpostavljam da to izmedju ostalog i znaci da cip nece crci ako se uslijed bilo cega desi da greskom na CANH i CANL dodju ti naponi 12/24 V.
I to takodje ne znaci da ce diferencijalni napon svakog bita prilikom slanja biti +-12/24 V i da cip u automobilu treba spojiti npr. na napajanje od 12V, a u kamionu ili u industrijskom postrojenju na 24V.npr. Napon izmedju CANH i CANL moze da ide i do 40-tak volti, a da on ispravno radi, ali to je margina smetnji, a sam cip nikad nece generisati toliki napon izmedju CANH i CANL. Ne znam da li to ima neke veze, ali 40-tak V je jedan od probojnih napona BJT tranzistora, pa je pretpostavljam to zbog ona dva sto se nalaze na tim linijama (vidi se na blok semi u @mradomirovoj poruci).

Znaci cip treba spojiti na napajanje od tih 4-5 V kako stoji u datasheetu, linije terminisati tim otporima (i kondenzatorima, zavisi od konfiguracije) i to je to. Ne spaja se cip na napajanje od 12/24 V niti putuje tolika razlika potencijala kroz linije veze, osim u slucaju velikih EM smetnji.

Izgleda da si u pravu (ko bi sad jos i standarde proucavao), ali sudeci po prvom korakovom postu, upravo je drajvovanje vecim naponom ono sto bi zeleo.

Ukoliko nista drugo ne pomogne, ne ginu mu diskretno realizovani predajni drajveri.

Pa jeste, on je napisao da bi drajvovao magistralu sa 24V, ali meni se onda namecu druga pitanja:

1- jedini razlog zasto bi se to radilo je da vec postoje neke druge jedinice koje tako komuniciraju preko te magistrale, ali u tom slucaju ako to nije CAN onda ne vredi ni CAN umetati tu, jer se njegov format podataka razlikuje od ostalih i napravice se haos na toj magistrali?!

2- ako su te ostale jediniece ipak spojene preko CAN, onda nema potrebe da to bude 24V, zasto se ne bi koristili standardni nivoi?

3- narucilac posla tako zahtjeva sto znaci da nema pojma o cemu prica. U tom slucaju ja bi napravio kako "bog zapovijeda" (dakle po standardu) i ubacio neku bezveze plocicu da tu stoji (npr. od pokvarene video igrice iz 70-tih godina) i rekao naruciocu posla da to transformise naponeske nivoe na 24V, tako da i on moze mirno da spava.

Uvijek postoji taj problem sa naruciocima posla koji vole da pametuju na tudj racun. U tom slucaju obicno pomaze sledeca recenica: "U redu, ja cu napraviti tacno onako kako Vi kazete, ali u tom slucaju odgovornost za ispravno funkcionisanje je na Vama. Ja ne mogu da garantujem za odluke koje ste Vi donijeli i ako ja budem morao da dolazim da popravljam nesto sto ne radi kao posljedica Vasih odluka - naplaticu."
Onda se obicno sloze da se to uradi kako treba.

_{[Ovu poruku je menjao Odin D. dana 22.01.2009. u 12:38 GMT+1]}

Vidim solidnu zainteresovanost za ovu temu, pa je zgodno da je rasvetlimo.
Dosta sam lutao po internetu interesujuci se za fizicki nivo CAN-a. Ima puno drajvera koji se napajaju sa oko 5V i mogu da generisu CANH i CANL prema masi napon samo do 5V, ali izlazi ne mogu biti unisteni ako na CAN liniju dodje i vise od 24V (kamioni), jer majstori obisno neoprezno brckaju po zicama. Ali, vec sam napisao LT1796 moze da se napaja naponom do 44V i da generise tolike napona na CAN liniji, ali ne moze da izdrzi struju koji treba da da na CANH i CANL ako se kabl zatvori karaktristicnom impedansom. Cak ni naponi ne mnogo veci od 5V mogu da dovedu do povecane disipacije i iskljucenja rada cipa zbog pregrevanja. Dakle nasao sam drahver koji mi odgovara, ali postoji problem disipacije.

Ako ste gledali kako salje CAN jedan bit onda ste uocili sledece: ako je na primer CAN 1Mbit/sec, jedan bit se prenese za 1us. Ali vreme od 1us je podeljeno na 10 faze od po 100ns. Prvo ide 1 faza log 0 za sinhronizaciju, pa paiza od 3 faze i u sledecih 6 se salje vrednost bita. Na mestu prijema se vrednost bita cita po okoncanju 7 faze. Za sinhronizaciju mogu da se koriste i dve faze na ustrb pauze. Cini mi se da ako bit koji se salje ima vrednost 1 da je u vreme pauze signal 0, a ako je vrednost bita koji se salje 0, onda je u pauzi vrednost 1 (za ovo nisam siguran ali mi je logicno). Dakle na CAN basu nije frekvncija 1/2 MHz vec 5MHz ili 2.5MHz ako je sinhronizacija za bit dve faze. Sobzirom da se svaki bit sinhronise, ne postoji ogranicenje u broju bitova koji se sukcesivno salju, niti postoji nagomilavanje greske kao kod SCI (od prvog pa do 8 bita).

Zakljucak: SCI 9600 boda je frekvencija od 4.8kHz, a CAN sa 9600bita/sec generise frekvenciju na liniji od 48kHz ili 24kHz. Jasno je da linija za CAN mora biti bolje podesena.

Svetlost (i el. mag. talas) predje za 1ns 30cm. Dakle ako se salje signal sa pocetka linije koja je dugacka 60m javice se refleksija sa kasnjenjem od 60x2/0.3
sto je 0.4us. Za SCI na 9600 boda trajanje 1 bita je 104us, pa deformacija od reflektovanog signala je zanemarljiva. Za CAN na 1Mb/s gde je jedna faza 100ns reflektovani signal je dramaticno stetan. Dakle reflektovani signal uvek postoji (sem ako je linija dobro zatvorena) pa su zato moja merenja za SCI na 9600 boda, kada sam na osciloskopu gledao signal "oka" sa 25us po podeljku nisam mogao (logicno) da vidim nikakav uticaj na oblik signala kada je kabl (od 60m) zatvoren razlicitim impedansama.

Inace komunikaciju moram da ostvarim u uslovima mnogo vecih smetnji od onih koji su u automobilu. Ves cam rekao da je protokol po principu master - slave sa kratkim porukama i da se stalno ponavljaju (oko 30 puta u sekundi). Nije kriticno ako se kod jedne poruke detektuje greska, jednostavno ona se nece prihvatiti, ali ce verovatno sledeca biti prihvacena.

CAN drajver moze da ima nizu impedansu na liniji pa racunam da ce manje skupljati smetnje. To je razlog zbog cega sam zainteresovan za fizicki nivo CAN komunikacije. Za konkretni uredjaj mi ostale prednosti CAN-a ne znace mnogo zbog same prirode komunikacije koju sam opisao. Za buduce aplikacije mozda.

Pozdrav svima.

CAN interfejsi nisu bas tako tako elementarno izvedeni, kako se moze uciniti na prvi pogled, pa da se nije vodilo racuna o reflektovanim talasima. Kao sto je vec spomenuto u nekoj poruci iznad, presudnu ulogu igra CMRR, a ne razlika napona izmedju prenosnih linija, tj. koliko ce smetnje i refleksije da uticu na ono sta se nalazi na linijama nije jedino i iskljucivo odredjeno impedansama kojima su linije zatvorene, vec i onim sto je unutar cipa.
Sami sumovi koji su prisutni u automobilu nisu najveci izvor sumova u njemu vec okolina i razne okolnosti koje se automobilu nadju na putu (dalekovodi, tramvajske linije napajanja, staticki elektricitet, razni krsevi koji varnice oko njega, indukcija svega i svacega zbog kretanja itd...), tako da po mom misljenju mozes biti siguran da ce i u tvom okruzenju raditi kako treba i da ces sebi sigurno olaksati brigu ako to izvedes kako je vec predvidjeno, bez nekih dodatnih prepravki. Jer sve sto sad uradis kako je nestandardno, to ce se prolongirati dalje i u buducnosti opet tebi (ili nekom drugom) praviti problem.

CAN statistika kaze da jedna od 100 milijardi gresaka (ne normalnih poruka) nece biti detektovana. Ako bi svaka druga tvoja poruka bila pogresna, tj kad bi od tih 30 poruka u sekundi 15 bilo pokvareno smetnjama, provukla bi se jedna od njih neopazeno na svakih 211 godina.

Pozdrav.

Da, u pravu si, nisu u pitanju samo smetnje koje automobil proizvodi, to je ohrabrujuce.

Ali me interesuje kako cenis da SCI komunikaciju pustam kroz CAN drajver sto mi je najjednostavniije uzimajuci u obzir da sada imam RS485 na 9600 boda.

Pozdrav.

Pa mozes ti pustiti SCI kroz CAN interfejs, ali na toj duzini i u tom okruzenju moras biti spreman na smetnje i greske u prenosu. Ne znam tacno koji SCI mislis da propustis, ali ako on vec u sebi nema ugradjenu detekciju (i eventualno korekciju) gresaka onda moras ti to sve implementirati na tebi dostupnom nivou, a to je program mikrokontrolera, ili ako uC dalje prosledjuje to npr. na neki PC, onda moze i tamo da se provjerava da li je primljena poruka ispravna ili ne. Ali, ti detalji zavise vec od strukture, namjene i zahtjeva za pouzdanoscu citavog tog postrojenja.
Detekcija gresaka se ne obavlja u CAN interfejsu nego u CAN controleru (poseban cip, ili implementiran u uC-u). Tako da time sto bi propustio SCI kroz CAN interfejs nista ne bi dobio sto se tice pouzdanosti, osim ako sam fizicki oblik signala kod CAN-a i karakteristike interfejsa ne garantuju neku vecu otpornost na elektricne smetnje u toku prenosa poruke.

Ja se licno ne bih oslonio na "parity bit" kao jedinu zastitu od gresaka na vezi, cak ni za najbezazleniju industrijsku aplikaciju.

RS485 je samo "fizicki layer" za prenos podataka, tj. samo transmisiona linija za prenos elektricnih signala na odredjeni nacin, a ne citav protokol (u to spada jos i sta ti signali znace, a RS485 nema pojma sta znace ti bitovi koje on prenosi). Na njemu su npr. implementirani i Profibus i SCSI. Ako nemas vec ugradjen odgovarajuci protokol u svom uC-u ili ako ne koristis poseban cip za to, onda ti sve te vislje nivoe ( "layere") svoje komunikacije moras sam implementirati u softveru, sto cesto nije bas trivijalno. Ako ti je RS485 half-duplex (jedna upredena parica) onda moras da vodis racuna kad ko smije da emituje poruke na liniju (jer je RS485 interfejs takav da na njemu ne smije doci do sudaranja) tako da ti svejedno moras da se odlucis koji protokol ces da saljes preko postojeceg RS485 i kako ces regulisati sve te zahtjeve. I tako svejedno ces morati kupiti neke cipove za taj neki izabrani protokol (jer bilo bi suludo implementirati to rucno u softveru uC-a i to na svakom cvoru koji je nakacen na tu liniju).

Po mom misljenju najbolje je da uzmes CAN controler (ako nije vec integrisan u uC) i interfejs (Transciever) i mirno spavas. Na jednoj strani samo upises sta hoces da posaljes, na drugoj strani primis poruku sa vjerovatnocom od (ErrorTransmitRate * 10EXP-11) da je to nedetektovana greska. Tesko da mozes bolje od toga za toliko malo posla koliko je potrebno za implementaciju toga i koliko to malo sve kosta.

E sad, ako je to sve vec ranije radilo OK na RS485 i sa SCI protokolom bez detekcija/korekcija greski, onda tu izgleda i nema toliko smetnji koliko se cini, pa ako u medjuvremenu nisu ubacene neke nove masina ili instalacije kao moguci izvori smetnji i nece ni biti ubacivano u buducnosti, onda mozes da uradis i tako kako si naumio. Ako je radilo do sad, sto ne bi i od sad?

Pozdrav.

Da pojasnim, proizvedeno je oko 50 uredjaja sa RS485 i oni prvi vec rade 2 god. bez problema Uredjaje proizvodim za poznatog kupca koji mi je i postavio tehnicke zahteve. E sad, neki drugi kupci koje smo kontaktirali, uvek postavljaju pitanje "a zasto poseban sirmovan kabl".

Poruke su vrlo kratke, do 10 bajtova i koristim samo cek sumu za kontrolu ispravnosti primljenog bloka podataka. Naravno, cek suma moze da propusti i neispravan podatak a da to ne detektuje. Povecanje pouzdanosti se mozda dobija i time sto imam karakter za pocetak poruke i za kraj poruke, poruke su fiksne duzine, a salje se i adresa prijemnika. Pored dobre cek sume treba da su poklope i ova cetri dodatna uslova. Zatim svaki podatak je veci od 32 (0 je 32) sto zadovoljava priroda podataka koji se salju. Ne umem da procenim koliko sve ovo doprinosi povecanju pouzdanosti, ali do sada se nije desila ni jedna greska koju sam mogao da pripisem losem prenosu podataka.

Poznato mi je da se na visim nivoima detektuje pouzdano greska jer sam napravio skoro jedan uredjaj koji se vezuje USB-om na PC. Integrisani kontroler USB-a u MCU je zavrsavao sav posao i svi blokovi podataka su uve bili primljen ispravno i na strani PC-a i MCU-a.

CAN je jednostavniji od USB-a (barem se meni tako cini), imam MCU sa CAN-om, ali bi morao da menjam PCB uredjaja ako bi zeleo u potpunosti da primenim CAN. Zapravo vec razmisljam o novoj verziji uredjaja jer moram da ga inoviram i nekim novim funkcijama, pa bi mozda bilo zgodno da tada primenim CAN. A do tada bi pokusao da iskoristim samo fizicki nivo CAN-a.

Hvala na sugestijama.

Pozdrav.

Zar protokol preko CAN-a nije standardizovan? Kako ti možeš da ubacuješ dodatne bajtove u poruku?

Ne pisem o CAN protokolu, vec o SCI sa CAN drajverom, dakle od CAN-a koristim samo fizicki nivo.

Pozdrav.

Po mom razmisljanju ta dva karaktera sto oznacavaju pocetak i kraj poruke imaju uticaja samo na to da li je poruka pocela i zavrsila ispravno, ali nemaju uticaja na sam sadrzaj sredine poruke, kao npr. ako su adresa posiljaoca i primaoca na koverti u redu, to ne garantuje i da je sadrzaj koverte takodje u redu. Sve sto stiti sam sadrzaj poruke je i dalje samo CRC, a ako je stigla i ispravna adresa (koja je dio poruke), to pored ta dva karaktera dodatno povecava vjerovatnocu da je taj prenos protekao bez smetnji, ali koliko sve to u zbiru povecava mogucnost detekcije greske, ne bih znao, to bi trebalo racunati. Ali nije mnogo ni bitno ako to sve radi OK.

Mislim da mozes koristiti SCI sa CAN interfejsom, ali bih ipak preporucio da se obavi experiment i testiranje, da ne bi bilo po onoj: "papir sve trpi, a more proguta". Najvise tu mislim na priorite slanja poruka, kao i sta se desava kad dva ili vise uredjaja krenu istovremeno da salju poruku, ili kad neki od interfejsa crkne da li zablokira citavu magistralu i tako to. Ako su u tom pogledu dosadasnji interfejs i CAN interfejs kompatibilni onda valjda nema smetnji da se zamjene.

Pozdrav.

Pa ako od CAN-a koristis samo fizicki nivo, razlike u odnosu na RS485 nema.

Glavna razlika izmedju RS485 i CAN drajvera (fizicki nivo layera) je u detekciji kolizije. CAN je moze detektovati, a RS485 ne. Da razjasnim, pod kolizijom se podrazumeva da dva drajvera istovremeno posalju na liniju razlicit podatak. Ako jedan posalje log. 0 a drugi log. 1, nastaje kolizija podataka.

Ovo je moguce zbog drajvera koji je izveden tako da poslata log. 0 uvek pregazi log. 1 (kao sto u I2C protokolu master ili slave slanjem logicke 0 "pregazi" logicku 1 generisanu pull-up otpornikom). To omogucava da nod koji je vec poceo sa slanjem logicke 1 detektuje da je na liniji i dalje log. 0, i prekine dalje slanje, odnosno prepusti dalju predaju onome ko je prvi zapoceo slanje logicke 0. Oblik signala svakog noda je specifican (recimo da svaki ima svoj unikatan serijski broj), i ukoliko pri istovremenom slanju tog serijskog broja (on se prvi salje) na liniji jedan nod detektuje da se predato i primljeno stanje ne slaze (neko drugi vec zapoceo komunikaciju), prepustice njemu dalji rad sve dok linija ne bude slobodna.

U praksi nije sve bas tako jer se ne moze govoriti o logickoj 0 i 1 u diferencijalnim signalima, ali takav je princip.

Ovakav princip omogucava mogucnost koja se ne srece kod ostalih komunikacionih protokola. Da bilo koji nod bez intervencije mastera (ukoliko master uopste postoji) u bilo kom trenutku moze poceti sa slanjem podataka. Da bi se ipak smanjio "upad" u vec zapocetu vezu, svi nodovi moraju odredjeno vreme "osluskivati" stanje na liniji, i tek ako je ona cista poceti sa predajom.

Ostale razlike (izlazna impedansa, maksimalna brzina i daljina) su otprilike podjednake. Mozda bi se jedan drajver pokazao bolji od drugog, ali mislim da bi se isto dobilo i sa drajverima drugih proizvodjaca. To su ipak samo finese.


Dallas 1-wire protokol sa vecim brojem nodova upravo zbog kolizije primenjuje slanje obicnog pa invertovanog bita masteru u slucaju poslate komande za iscitavanje njegovog serijskog broja. Jedino je na taj nacin moguce detektovati koliziju po prijemu drugog bita. CAN protokolom detekcija kolizije je omogucena u samom drajveru, na fizickom nivou.

I2C protokolom sa vecim brojem nodova master uvek diktira kompletnu komunikaciju pojedinacnim prozivkama nodova, tako da u njemu nema potrebe za detekcijom kolizije (dva noda ne mogu zapoceti istovremenu predaju).

RS485 protokolom komunikaciju moze ili diktirati master (kao kod I2C), ili se pak ona resava prenosom tokena (poruke kojom prethodni nod omogucava kontrolu nad linijom sledecem). Korekcija gresaka je ipak i ovde neophodna da token ne bi negde "zalutao" i tako se nepovratno izgubio. Postoje naravno i drugi nacini (u DMX512 protokolu master neprestano salje podatke svim slave redom, samo simpleksom).


To je znaci glavna razlika na fizickom nivou. Ukoliko ti je bitna detekcija kolizije, uzmi CAN, a ukoliko nije, koristi i dalje RS485. Uostalom, mozes koristiti i CAN drajvere umesto RS485 drajvera jer su (ukoliko ne koristis detekciju kolizije) kompatibilni (mozda je eventualno signal invertovan). Naravno, potrebno je obratiti paznju i na ostale finese (max broj nodova, duzina i sl.).

Mislim da je CAN drajver ipak u maloj prednosti zbog mogucnosti eksternog podesavanja (trimerom na SLOPE-CONTROL pinu) vremena prelaska sa log 0 na log 1 (i obrnuto) cime se moze smanjiti refleksija za konkretno okruzenje. Takodje i zbog bolje zastite u slucaju kvara pojedinacnih drajvera, kako se ne bi zablokirala linija.


Koliko vidim, nije ti bitan bas svaki bit, a izbegao bi korekciju gresaka. U tom slucaju moguce da bi ti simpleksni DMX512 odgovarao. Detaljnije o njemu imas u AN1076 sa www.microchip.com .

Pogledaj i prilog. U njemu su objasnjeni prakticni problemi koji se srecu pri konstrukciji mreze. Jeste da je za RS485, ali isto vazi i za CAN.


Za buduci rad, smatram da bi bilo bolje da ovladas i CAN protokolom. Ipak je on standardan, a buduci da je integrisan, omogucuje mikrokontroleru mnogo manji utrosak instrukcijskih ciklusa u odnosu na rucnu detekciju i korekciju gresaka. Buduci da si vec ovladao kompleksnijim USB protokolom, CAN ces lakse shvatiti. Pogledaj i poglavlje o razlikama izmedju pojedinih protokola sa mog sajta.

Uf, glava me zabolela čitajući AT90CAN32 datasheet.
Nije baš tako jednostavno, možda je to cena sigurnosti prenosa.
Jel neko radio sa pomenutim MCU?

Da odmah unapred napomnem da nemam prakticnih iskustava ni sa CAN ni sa RS485 protokolom, tako da bi ipak bilo korisno kao sto je Odin D. naveo testirati hardver pre upotrebe.

Takodje, nije moguce "mesati" drajvere (da ih pola bude sa RS485 a pola sa CAN drajverima), cak iako se ne koristi kolizija (zbog razlicitih impedansi, ali i drugih razloga). Mozda bi RS485 drajveri cak mogli i podneti koliziju (sa njenom detekcijom pa bi se i oni mogli upotrebiti umesto CAN drajvera), ali oni jednostavno nisu namenjeni za takve stvari.


@mradomir
Probaj najpre da shvatis sam protokol. Imas ga odlicno objasnjenog u npr. MCP2510 datasheetu (sa www.microchip.com ). Posebno pogledaj data frame-ove i poglavlja sa prijemom i predajom poruka. Jednom kada shvatis protokol, lakse ces ukapirati kako je implementovan u mikrokontroleru.

Zašto ne?
RS485 drajver ima izlazni stepen koji radi u mosnom spoji, tako da je uključena ili jedna ili druga dijagonala
mosta tako da je na izlazima H i L napon +- ili -+ respektivno ,
a kod CAN busa je napon +-(dominantan, uključeni izlazni tranzistori)) ili
0V(recesivan, izlazni tranzistori isključeni).
Potrebo je samo PULL-UP otpornicima (H -Otpornik-Minus i L-Otpornik-Plus) ostvariti takvo stanje na busu
da kada je stanje CAN transivera recesivno ti PULL-UP otpornici drže BUS na -+ tako da je to stanje i za RS485
transiver logička "0" kao i za CAN transiver.
Pre par godina san našao u ELEKTOR-u jedan članak baš sa tom temom gde su prikazano i rešenje tog "problema".
Videću da ga pronađem i postaviću ga u ovom forumu.

Pozdrav.

Pa dobro, uz takvo budzenje moglo bi raditi.

Mislio sam prvenstveno na pogorsanje karekteristika linije usled razlicitih impedansi CAN i RS485 drajvera, i eventualno njihovih drugacijih (brzih ili sporijih) odziva.

Daleko odoste...

Procitao sam sve o CAN-u i kako resava problem konflikta na liniji. Znam da svaki uredjaj zapocinje slanje na liniju prvo svojom adresom, i sve vreme slanja istovremeno cita sta je na liniji. Ako se jos neki uredjaj prijavio onda ce adresa na liniji da bude ona koja je najmanja (nule nadvladaju jedinice) i kada uredjaj procita adresu, a ona je manja od njegove on odustaje od daljeg slanja prepustajuci liniju uredjaju sa nizom adresom. Njegovo je samo da nadgleda liniju i da detektuje sledece idle stanje pa da ponovo pokusa sa slanjem. i td...

Kod mene je problem vrlo jednostavan: imam RS485, 9600 bida, koji radi u modu master - slave, broj bajtova koji se salju je manji od 10 i imam cek sumu . Dakle vrlo prosta stvar koja iskljucuje konflikt na liniji a zbog malog broja bajtova i cek suma je efikasna a zbog male brzine nije potrebno precizno podesavanje linije. Zelim samo da sirmovan kabl zamenim upredenom paricom i nista vise. Racunam da umesto RS485 drajvera iskoristim CAN drajver (ima ih koji su i pin to pin kompatibilni) jer moze da drajvuje vise cvorova, pa racunam da manje skuplja smetnje (sto ne mora da znaci sve dok se ne proba).

Takodje sam napomenu da zbog dodatnih zahteva ove godime moram da napravim novu verziju maticnog PCB-a uredjaja i tada cu mozda da uvedem CAN. Dakle, postavio sam problem kao privremeno resenje da izbegnem sirmovana kabl, a da nista ne menjam na postojecoj verziji uredjaja. Samo to.

Pozdrav svima.