Kuten muut ovat sanoneet, SPI: tä ja I2C: tä voidaan käyttää pitkiä matkoja niin kauan kuin vetovastukset, kellotaajuudet ja niin edelleen.

Tärkeimmät vaihtoehdot (jotka antavat paremman meluneston) ovat RS485 ja CAN. Molemmat näistä käyttävät differentiaalilinjoja meluhaittojen minimoimiseksi ja sopivat paremmin tähän tiedonsiirron pituuteen kuin I2C tai SPI. En usko, että monissa (yhtään?) AVR: ssä on sisäänrakennetut CAN-oheislaitteet, jotka tekevät CAN: n käytöstä paljon helpompaa.

Sanoisin, että tärkein asia, joka on otettava huomioon bussia valittaessa, on varmistaa, että laitteiden väliseen viestintään käytettävä protokolla sisältää CRC: n tai vastaavan, jotta voit määrittää, onko viesti vastaanotettu oikein (CAN: lla on tämä osa pakettia). Tämän vuoksi on myös hyödyllistä saada ACK / NACK-tyyppinen vastaus osana protokollaa, jotta vioittunut viesti voidaan lähettää uudelleen.

Useiden jalkojen ei pitäisi olla ongelmallisia, käytä vain kierrettyjä johtoja, jos voit. SPI: tä on paljon helpompi puskuroida (jos tarvitset) kuin I2C, koska SPI-signaalit ovat kaikki yksisuuntaisia, kun taas I2C: n signaalit ovat jaetuilla linjoilla.

Voivatko AVR-mikrokontrollerit käsitellä I2C- ja SPI-orjatiloja sekä isännöidä tilat? (tarvitset molempia)

Pitkien matkojen I2C: lle kannattaa ehkä etsiä joitain "I2C-väylän toistin" -ratkaisuja. Muista, että I2C- tai SPI-tiedonsiirron yhteydessä mahdollisesti löydetty enimmäisetäisyys viittaa enimmäkseen väylän kokonaismatkaan eikä väylän kahden solmun väliseen etäisyyteen.

Haluat ehkä etsiä RS485-mallista tällaisia ​​ongelmia. Se on sarjaväyläprotokolla, joka kommunikoi differentiaalilinjoilla, joten kierrettyjä johtoja käytettäessä melun mahdollisuudet minimoidaan. Hyvin pitkiä matkoja voidaan saavuttaa tällä tavalla. Haittapuoli olisi, että tarvitset ylimääräisen RS485-kooderipiirin (kuten MAX485, ei kovin kallista) piirisi.

Yksi SPI: n etu, jota ei ole vielä mainittu I2C: hen nähden, on se, että kaikki SPI-johdot ovat yksisuuntaisia ​​ja ajetaan aina korkealla tai matalalla. Tämä mahdollistaa paljon nopeamman viestinnän kuin on mahdollista I2C: n kanssa, vähentää alttiutta melulle ja mahdollistaa yksinkertaisten porttien käytön toistimina. Toinen hyödyllinen vaihtoehto on yksinkertainen asynkroninen tiedonsiirto (yksi lanka kumpaankin suuntaan). Ainoa haittapuoli, jonka pystyn näkemään asynkronoinnissa, on se, että se vaatii yleensä molempien osapuolten olevan "hereillä", vakaan kellon kanssa tietojen vaihtamiseksi.

Omassa projektissani käytin 3- langan hieman modifioitua SPI-protokollaa ja ovat löytäneet tulokset tyydyttäviksi. Lähetän näytön bittikarttatiedot (joissa satunnainen tietojen vioittuminen ei ole iso juttu) nopeudella 10 Mbps ja muut tiedot nopeudella 2,5 Mbps.

Vain FYI, langattoman Nintendo Wii -kaukosäätimen ja sen Nunchuck-kumppanin välinen käyttöliittymä käyttää I2C: tä noin 3 metrin pituisella kaapelilla. On myös 3-jalkaisia ​​jatkojohtoja, jotka pidentävät kokonaispituuden noin 6 jalkaan. Ei täsmälleen sama kuin asetuksesi (vain kaksi laitetta on kytketty toisiinsa), mutta se on esimerkki I2C: stä kaapelin kautta laajasti käytetyssä kulutustuotteessa.

Vaikka sekä I2C että SPI on suunniteltu lyhyen matkan matkoille (muutama tuuma), molempia voidaan käyttää pidemmillä matkoilla asianmukaisella kaapelilla ja huomioiden väylän kapasitanssi.

Minulla on vain vähän kokemusta SPI: n kanssa I2C ei ole kovin vaikeaa, koska sinun on aina laskettava oikea vastusvastuksen koko. Lisäksi on olemassa omistettuja ja edullisia I2C-puskureita, joita on melko helppo käyttää. Sinun on silti käytettävä verkkoon sopivan kokoista vetovastusta.

Olen käyttänyt I2C: tä verkostoitumiseen kahden AVR: n välillä 8 jalan etäisyydellä käyttäen vain vetovastuksia ja korkealaatuinen, hyvin suojattu, kierretty kaapeli.

Kuten monet ovat ehdottaneet, I2C: tä ja SPI: tä käytetään parhaiten lyhyillä matkoilla. Vaikka ratkaisu voi olla mahdollista toteuttaa näillä rajapinnoilla, suosittelen ehdottomasti erilaisten, "tavallisempien" ratkaisujen etsimistä (esim. Ethernet, RS485, CAN jne.). - Varsinkin jos aiot käyttää kaapeleita päästäksesi 6 jalan etäisyydelle mikro-ohjaimista.

Olen työskennellyt projektissa, johon osallistui noin 80 AVR-pohjaista solmua tähtiverkossa I2C: n kautta. Se oli täydellinen sotku ja ei lopulta toiminut. Päivitysten saaminen kaikkiin solmuihin kesti sekunteja ja yksi viallinen yhteys heittäisi pois koko verkon. Viimeinkin puhuin kaverille, joka teki solmut, hän sanoi lopettaneensa I2C: n käytön tällaisissa projekteissa. Valitettavasti en tiedä miksi nimenomaan I2C oli riittämätön täällä.

Sen pitäisi olla helppoa lyhyillä matkoilla. Mitä voisit tehdä, on selvittää, mitä nämä etäisyydet ja kaapeloinnit merkitsevät kapasitanssin ja linjan impedanssin suhteen, ja nähdä, millaisia ​​taajuuksia (nousu / laskuajat) voit saada niiden läpi. Tietyn pisteen jälkeen on parasta kohdella heitä siirtolinjoina. Jos se näyttää huonolta, voit todellakin vaihtaa johonkin muuhun sarjajohtoon, kuten EIA-232 tai 422. Se saattaa tarkoittaa ylimääräistä sirua molemmissa päissä, mutta ulottuu kauas. Jos sinun on todella mentävä nopeasti ja kauas, tarvitset jotain enemmän (ethernet, älä laske radiota tai laseria :).

Jos pystyt hallitsemaan kellonopeutta etkä tarvitse nopeaa tiedonsiirtoa, yritä hidastaa kelloa. Tämä tekee siitä vähemmän altis melulle.