Tervetuloa puoliduplex-viestintäjärjestelmien suurimpaan haasteeseen.

RS-485 ei ole protokolla, se on standardi, joka määrittelee puoliduplex (*) differentiaalilinkin sähköiset ominaisuudet. Spesifikaatiossa ei ole mitään siitä, miten tietoja lähetetään linkin kautta tai miten linkkiä käytetään.

Koska tällaisilla RS-485-lähetinvastaanottimilla ei ole automaattista "linja on varattu" -signaalia / lippua / mitä tahansa, eivät myöskään mikro-ohjaimet, jotka ovat rakentaneet RS-485-ohjaimet, eivätkä ne, jotka käyttävät ulkoiseen lähetinvastaanottimeen kytkettyä UART-ydintä.

Kaikki virtauksen ja suunnan ohjauksen toteutus jätetään käytetylle protokollalle. On olemassa useita tunnettuja protokollia, jotka käyttävät RS-485-ohjaimia, kuten Modbus. Voit myös toteuttaa minkä tahansa ajateltavan protokollan.

Tässä on muutama idea protokollista:

1. Sinulla on isäntä-orja-tyyppinen protokolla. Tässä on pääsolmu, joka koordinoi väylää, ja orjasolmut, joilla kullakin on jokin yksilöllinen tunniste.

   Orjasolmut eivät saa lähettää tietoja ennen kuin pääsolmu lähettää nimenomaisesti niille osoitetut komennot. Kun orja on osoitettu, se voi sitten vastata mihin tahansa komentoon jollakin ennalta määrätyllä tavalla - sanoa kiinteän pituisen vastepaketin.

   Tässä tapauksessa vältät useiden laitteiden ongelmat, jotka haluavat puhua samanaikaisesti, koska päällikkö on paikalla koordinoimaan kaikkea.

2. Voit käyttää jonkinlaista aikataulutusta, jolloin väylän jokaisella laitteella on kiinteä paikka, jossa tietoja voidaan lähettää muille laitteille. Kun korttipaikka on loppunut, sen on lopetettava lähettäminen ja annettava seuraavan laitteen puhua.

   Laitteet voivat tehdä ajoituksen itse ilman ulkoista koordinointia.Ensimmäinen laite puhuu ja lähettää sitten viestin, että se on tehty.Seuraava laite (esim. Se, jolla on seuraava korkeampi tunniste) tietäisi sitten, että se voisi mennä.Jos laite ei vastaa, sinulla voi olla aikakatkaisu, jolloin jokainen seuraava aikataulun laite voi sanoa - no, en ole kuullut laitteesta ennen minua jonkin aikaa, joten minun on oltava vuoroni.

(*) Uskon, että se määrittelee myös kaksisuuntaisen version kahdella differentiaalilinkillä.

Se muistuttaa hyvin armeijan tai poliisin radioviestintää.Protokolla vaaditaan.Master-orja on helppoa ja hyvää useimmissa tapauksissa.Mutta toinen vaihtoehto on tehdä se kuten ihmiset:

1. Kuuntele.
2. Jos joku puhuu - odota.
3. Jos luulet, ettei kukaan puhu, voit puhua.
4. Odota vahvistusta.
5. Jos vahvistusta ei saatu, puhu uudelleen.
6. Jos haluat lähettää lähetyksen, pyydä kaikkia asemia vahvistamaan kuuntelu.
7. Jos haluat puhua jonkun kanssa, joka ei kuule sinua, kysy, onko joku muu, joka voi välittää.

Ja niin edelleen.Saattaa olla erittäin mielenkiintoinen toteuttaa.Onnea!

Tässä on muutama mahdollisuus ratkaista ongelma.

1. Ota käyttöön tunnuksen välitysjärjestelmä.Kun laitteella on tunnus, sen sallitaan lähettää rajoitetun ajan.Sitten se välittää tunnuksen seuraavalle laitteelle.On varauduttava puuttuvista solmuista, jotka eivät voi vastaanottaa ja siirtää tunnusta.
2. Katso vastaanottorivi.Jos se on varattu, luo satunnainen viive ja yritä uudelleen.Satunnainen viive auttaa varmistamaan, ettei kukaan solmu voi monopolisoida lähetysikkunoita.Törmäyksiä voi silti tapahtua, mutta tarkistussummaominaisuus voi määrittää, onko vastaanotettu paketti ehjä.Jos se ei ole ehjä, vastaanottaja voi pyytää uudelleenlähetystä.

Kuinka hallitus löytää, jos UART-linja voi vapaasti lähettää tietoja,

Yleinen vastaus on, että ilman jonkinlaista protokollaa se ei voi tehdä sitä luotettavasti.luotat yleensä ohjaimeen tai välimieheen nähdäksesi onko linja varattu vai ei.Yksi yksinkertainen olisi OD-tappi, joka vetää ilmaisulinjan alas ennen lähetystä ja vapauttaa sen jälkeen.Lukemalla tuon linjan lähetin voi selvittää, onko väylä käytettävissä vai ei.

vähemmän luotettava, mutta yksinkertaisempi järjestelmä on väyläjännitteen integrointi (esimerkiksi r / c-verkon kautta).

ja jos se havaitsee väylän olevan varattu, odota, kunnes väylä on vapaa, ja lähetä sitten omat tietonsa?

Yleinen lähestymistapa on odottaa satunnaista aikaa ja yrittää uudelleen.

Ratkaisen tämän ongelman esimerkiksi seuraavilla tavoilla:

Sen sijaan, että käytän 2 nastaa komm.Lyhyillä etäisyyksillä se toimii.Kolmas tappi on linjan varattu ilmaisin.Tämä tappi vedetään ylös isäntäpuolelta.Kun joku (MCU tai mikä tahansa) haluaa puhua:

• tarkistaa tämän tapin (INPUT).
• jos tappi on KORKEA, tekee tappi matalaksi (OUTPUT)
• ja puhuu.
• Kun viesti siirretään, vapautetaan tappi (INPUT) (korkea impedanssi), tappi nousee korkealle.
• Jos tappi on matala, odottaa jonkin aikaa ja palaa sitten tarkistamaan tappi-jakson.

Tämä on toteutus Gregory Kornblumin vastauksesta.

Voit käyttää avoimen lähdekoodin BACnet-protokollapinoa mikrokontrolleriviestintään RS485: llä, jos et halua käyttää modbusia.Pohjimmiltaan se vain välittää tunnuksen ympärille, joka kertoo jokaiselle laitteelle, milloin se voi lähettää, samanlainen kuin tunnuskehän topologia ja Ethernet.Tässä on muutama linkki aloittaaksesi:

http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/

Ohjelmiston vuonhallinta

Sekä ohjelmisto- että laitteistovirtauksen hallinta tarvitsevat ohjelmiston kättelytehtävän suorittamiseen. Tämä tekee termistä ohjelmiston virtauksen hallinta hieman harhaanjohtavan. Tarkoituksena on, että laitteistovirtauksen ohjauksessa tiedonsiirtokaapelissa on ylimääräisiä johtoja, jotka ilmoittavat kättelyolosuhteista. Ohjelmistovirtauksen ohjauksella, joka tunnetaan myös nimellä XON-XOFF-vuonohjaus, tavut lähetetään lähettäjälle vakioviestintälinjoja käyttäen.

Laitteiston vuonohjauksen käyttö tarkoittaa, että lähettimen ja vastaanottimen välillä on oltava enemmän viivoja, mikä johtaa paksumpaan ja kalliimpaan kaapeliin. Siksi ohjelmistovirtauksen hallinta on hyvä vaihtoehto, jos sitä ei tarvita maksimaalisen suorituskyvyn saavuttamiseksi viestinnässä. Ohjelmiston vuonohjaus käyttää datakanavaa kahden laitteen välillä, mikä vähentää kaistanleveyttä. Kaistanleveyden pieneneminen ei useimmissa tapauksissa ole kuitenkaan niin hämmästyttävää, että on syytä olla käyttämättä sitä.

Kaksi tavua on määritetty ennalta ASCII-merkistöön, jota käytetään ohjelmiston vuonohjauksessa. Nämä tavut ovat nimeltään XOFF ja XON, koska ne voivat pysäyttää ja aloittaa lähetyksen uudelleen. XOFF: n tavuarvo on 19, se voidaan simuloida painamalla Ctrl-S näppäimistöllä. XON: lle on määritetty arvo 17, joka vastaa Ctrl-Q: tä.

Ohjelmistovirtauksen hallinta on helppoa. Jos merkkien lähettämistä on lykättävä, merkille XOFF lähetetään riville viestinnän uudelleenkäynnistämiseksi XON: ää. XOFF-merkin lähettäminen lopettaa viestinnän vain XOFF: n antaneen laitteen suuntaan.

Tällä menetelmällä on muutamia haittoja. Yhdestä on jo keskusteltu: tavujen käyttö tietoliikennekanavalla vie jonkin verran kaistanleveyttä. Yksi syy on vakavampi.

Kättelyä käytetään enimmäkseen estämään vastaanottimen puskurin ylitys, muistissa oleva puskuri, jota käytetään äskettäin vastaanotettujen tavujen tallentamiseen. Jos tapahtuu ylitys, se vaikuttaa tapaan, jolla viestintäkanavan uusia merkkejä käsitellään. Pahimmassa tapauksessa, jos ohjelmisto on suunniteltu huonosti, nämä merkit heitetään pois tarkistamatta niitä. Jos tällainen merkki on XOFF tai XON, viestintävirta voi vahingoittua vakavasti. Lähettäjä toimittaa jatkuvasti uusia tietoja, jos XOFF katoaa, tai ei koskaan lähetä uusia tietoja, jos XON: ää ei vastaanotettu.

Tämä pätee myös tiedonsiirtolinjoihin, joissa signaalin laatu on huono. Mitä tapahtuu, jos XOFF- tai XON-viestiä ei vastaanoteta selvästi linjan kohinan takia? Erityistä varovaisuutta tarvitaan myös, jotta lähetetyt tiedot eivät sisällä XON- tai XOFF-merkkejä tietotavuina.

Siksi sarjaliikenne ohjelmistovirtauksen ohjauksella on on hyväksyttävää vain, kun tiedonsiirtonopeudet eivät ole liian suuret, ja puskurin ylitysten tai datavaurioiden todennäköisyys ovat vähäiset.

nopea CSMA

Suurille nopeuksille, kuten Ethernet, CSMA -kantoaaltotunnistus on analysoitu stokastisten todennäköisyyksien optimoimiseksi.