Kysymys:
Miksi aluksella olevalla viestinnällä, kuten I2C, SPI jne., Ei ole virhetarkistuksia yleensä?
Alper
2016-06-04 02:18:59 UTC
view on stackexchange narkive permalink

Joitakin virhetarkistusmenetelmiä, kuten pariteettitarkistus, tarkistussumma, CRC jne., käytetään langallisessa / langattomassa viestinnässä. Suurin osa IC: stä, jossa on liitännät, kuten I2C, SPI jne., Eivät kuitenkaan käytä virhetarkistusmenetelmää.

Etsitään sanaa "i2c i / o expander" ja avataan satunnainen tietolomake. Tarkastellaan esimerkiksi PCF8574 TI: stä, joka on 8-bittinen I / O-laajennin. Jos lähtörekisteriä vastaava bitti käännetään I2C-lähetyksen aikana, IC ajaa vastaavan nastan ei-toivotulle tasolle. Miksi suurimmalla osalla tällaisista mikropiireistä ei ole lainkaan virheen tarkistusmekanismia? Oletukseni on, että vaikka viestintä olisi IC: n välillä, kaikki signaalit ovat meluisia. Vaikka todennäköisyys on melko pieni, melu voi aiheuttaa hieman käänteen.

Voiko tämä olla syy ?: Mikään virheen tarkistusmekanismista takaa täysin virheettömän viestinnän. Ne voivat vain auttaa meitä vähentämään virheiden todennäköisyyttä. On selvää, että bittivirheen todennäköisyys pitkän kantaman viestinnässä on suurempi kuin aluksella tapahtuvassa viestinnässä. Ehkä bittivirheiden todennäköisyys aluksella tapahtuvassa viestinnässä on hyväksyttävällä alueella jopa ilman virheen tarkistusmekanismia.

Mitä mieltä olet?

Samasta syystä tie ei tarjoa tyynyä, jos kaatut.Tie tarjoaa vain mahdollisuuden kuljettaa autosi.Voit laittaa haluamasi turvalaitteet autoon.Sarjaportit tarjoavat mahdollisuuden siirtää bittiä dataa.Suunnittelijan tehtävä on tarjota niin paljon virheiden ja vikojen tarkistusta kuin halutaan.
nopeus, jolla väylää kellotat, ja käytetty jännitetaso (i2c on avoin kollektori, voit käyttää laajaa jännitealuetta) auttaa merkittävästi vähentämään mahdollisia virheitä
"Jos lähtörekisteriä vastaava bitti käännetään I2C-lähetyksen aikana, IC ajaa vastaavan nastan ei-toivotulle tasolle.
@Passerby hän tarkoittaa, että jos lähetät komennon I2C IO -laajennuslaitteelle, muuttaa lähtötiloja, jos jostain syystä on olemassa tilanne, jossa jossakin ulostulonastaa edustavasta bitistä sattuu kohinaa kellosyklin aikana,tarkoitettu lähtö on erilainen kuin mitä IC todella antaa, kiitos I2C: n komennotavun
@DanLaks Näen mielesi.Voin lisätä virhetarkistuksen, jos suunnittelen * minä * sarjaportin kautta kommunikoivia yksiköitä.I2C-tapauksessa IC-toimittaja korjaa komennot ja protokollat, eivätkä ne sisällä virheen tarkistusta yleensä.
@Passerby KyranF: n selitys on se, mitä yritin sanoa.Kiitos KyranF
Muokkaa sitä sisään, koska se ei ole tällä hetkellä selvää.
Jotkut I2C / SMBus / PMBus-laitteet tukevat PEC: tä, eräänlaista 8-bittistä CRC: tä.Jos se ei täsmää, paketti hylätään.Tämä vaatii edelleen sovelluksen sulkemaan silmukan, ts. Havaitsemaan, että pyydetty komento ei tullut voimaan, tai lähettämään kyselyn uudelleen.
Virheiden havaitsemista tai korjaamista ei voi tehdä lisäämättä yleiskustannuksia protokollaan.Eri sovelluksilla on erilaiset tarpeet virhetoleranssin (ja riskin) ja yleiskustannusten välillä.Kaikille sopivia ratkaisuja ei ole, joten parempi tapa on olla tekemättä sitä lainkaan tällä tasolla, vaan pikemminkin sallia, että protokollapinon korkeammat tasot käsittelevät sitä tarpeen mukaan.
Seitsemän vastused:
Olin Lathrop
2016-06-04 02:57:45 UTC
view on stackexchange narkive permalink

Sinun on oletettava, että tietyt asiat vain toimivat, jopa maailmassa, jossa virheiden tarkistus. Miksi valita IIC tai SPI, kun taululla on yleensä paljon enemmän digitaalisia signaaleja? Vaikuttaa siltä, ​​että oletat, että kaikki tulkitaan tarkoitetulla tavalla.

Oikein suunnitellun piirin oikein suunnitellulla piirilevyllä pitäisi olla luotettava. Ajattele CMOS-ulostuloa, joka ohjaa CMOS-tuloa kaikkialle. Muuta kuin suoraa komponenttivikaa (mikä on aivan erilainen ongelma kuin satunnaisessa tietojen vioittumisessa), mieti, mikä voi todella mennä pieleen. Ajon päässä sinulla on FET, jolla on jonkin verran taattu vastus, joka yhdistää linjan joko Vdd: hen tai maahan. Mikä voi kuvitella tarkalleen, mikä voi aiheuttaa sen, että vastaanottopäässä ei ole oikeaa tasoa?

Aluksi tilaa ei voida määrittää, mikä tahansa kapasiteetti radalla on ladattu tai purettu. Silloin voi kuulua sointia lyhyessä jäljessä. Voimme kuitenkin laskea pahimman tapauksen enimmäisajat, kun kaikki tämä laskeutuu ja linja ylittää luotettavasti jonkin kynnyksen toisessa päässä.

Kun tämä aika on saavutettu ja olemme odottaneet mitä pahinta tahansa logiikan tapauksen etenemisviive on, signaalin muuttamiseen on vähän. Saatat ajatella, että levyn muissa osissa esiintyvä melu voi kytkeytyä signaaliin. Kyllä, niin voi tapahtua, mutta voimme suunnitella myös sen. Melun määrä levyn toisessa osassa on yleisesti tiedossa. Jos ei, niin se tulee muualta ja oikeassa suunnittelussa se kiinnitettäisiin rajoittumaan joihinkin maksimiarvoihin / dt ja muihin ominaisuuksiin. Nämä kaikki voidaan suunnitella.

Ulkoinen melu voi teoriassa häiritä taululla olevia jälkiä, mutta kenttävoimakkuuden olisi oltava kohtuuttoman suuri oikein suunnitellulle levylle. Melua aiheuttavia ympäristöjä on olemassa, mutta ne on rajoitettu tunnettuihin paikkoihin. Taulu ei välttämättä toimi 10 metrin päässä 10 kW: n lähettimestä, mutta jopa se voidaan suunnitella.

Vastaus on siis pohjimmiltaan, että samalla kortilla olevia digitaalisia signaaleja, jos ne on suunniteltu oikein, voidaan pitää ehdottoman luotettavina useimmissa tavallisissa käyttötarkoituksissa. Erityistapauksissa, joissa epäonnistumisen kustannukset ovat hyvin korkeat, kuten avaruudessa ja joissakin sotilassovelluksissa, käytetään muita strategioita. Näihin kuuluvat yleensä redundantit alijärjestelmät. Pidät silti taulun yksittäisiä signaaleja luotettavina, mutta oletetaan, että levyt tai alijärjestelmät kokonaisuutena saattavat toisinaan virheitä. Huomaa myös, että nämä järjestelmät maksavat paljon enemmän, ja tällainen kustannuskuorma tekisi useimmista tavallisista järjestelmistä, kuten esimerkiksi henkilökohtaisista tietokoneista, hyödyttömiksi olemalla liian kalliita.

Kaikesta huolimatta on tapauksia, joissa jopa tavallisissa järjestelmissä kulutuselektroniikan virheiden havaitsemista ja korjaamista käytetään. Tämä johtuu yleensä siitä, että prosessilla itsessään on tietty virhetodennäköisyys ja koska rajoja ylitetään. Tietokoneiden nopea päämuisti sisältää usein ylimääräisiä bittejä virheiden havaitsemiseksi ja / tai korjaamiseksi. On halvempaa saada suorituskyky ja lopullinen virhesuhde työntämällä rajoja ja lisäämällä resursseja virheenkorjaukseen kuin hidastaa asioita ja käyttää enemmän piitä tekemään kaikesta luonnostaan ​​luotettavampi.

Kiitos pitkästä vastauksesta.En pitänyt erityistapausta siitä, että oikeastaan ei saada oikeaa bittiä.Ajattelin, että se oli paljon yksinkertaisempi.Olen käyttänyt I2C I / O -ohjaimia sovelluksissani ohjaamaan jotain, enkä halua avata releä yhden bitin kääntämisen takia, sanotaan.Lisäkohinaa on kaikkialla (vastukset, transistori jne.), Miksi se ei aiheuta hiukan kääntöä viestinnän aikana.?
supercat
2016-06-04 02:28:10 UTC
view on stackexchange narkive permalink

Erityisesti protokollissa, joita ei ole suunniteltu käytettäväksi kaapeleiden kanssa, oikein suunnitellussa kortissa ei ole virheitä, ja huonosti suunniteltu levy ei toimi hyvin virhetarkistuksella tai ilman sitä. Esimerkiksi I2C-väylän häiriöt, joissa on useita orjia, voivat lukita väylän pysyvästi (*), ellei päälliköllä ole ohjainta, joka pystyy vetämään SDA: n korkealle, vaikka orjat yrittävät vetää sitä matalalle. Suojautuminen sitä vasten tekisi protokollasta hitaamman, mutta jos väylässä on riittävästi häiriöitä, ettei tällaista mahdollista käyttäytymistä pidetä riskinä, virhetarkistuslogiikkaa ei yleensä tarvita.

(*) Jos orja ajattelee näkevänsä aloitusolosuhteen toisesta laitteesta luettavan datatavun keskellä, ja tulkitsee luettavan datan käynnistävän komennon, jonka pitäisi lukea nollan merkkijono, niin se olisi mahdollista jokaiselle orjalaitteelle kuittaamaan toiselle lähetetyt datatavut siten, että kulloinkin ainakin yksi orjista pitää väylää alhaalla.

Katso myös: SMBus.
Kommentti: päällikkö ** ei yleensä ** voi nostaa SDA: ta korkealle, koska se käyttää avointa kerääjää.Vaikka päällikkö siirtyisi väliaikaisesti push-pull -lähtöön ja ajaisi korkealle, sinulla olisi bussitaistelu matalajokaisen orjan kanssa, mikä johtaisi määrittelemättömään tilaan ja mahdollisiin siruvaurioihin.Oikea tapa yrittää tyhjentää väylä on vaihtaa SCL, kunnes orjat vapauttavat SDA: n, ja sitten lähettää (uskon) noin 8 enemmän kelloja.
@DoxyLover: Jos orjia on kaksi tai useampia ja he ovat päässeet synkronoinnista, voi olla tilanne, jossa yksi orja vetää SDA: n matalalle kahdeksalle yhdeksästä jaksosta ja toinen vetää SDA: n matalalle kahdeksalle yhdeksästä jaksosta.Mikään määrä SCK-pulsseja ei korjata tilannetta.Jos isäntä olisi kytketty kuhunkin orjaan * itsenäisesti * esim.100ohmin vastus ja voisi vetää SDA: n kovaksi korkealle, kun SCK: n pyöräily yhdeksän pulssin ajan todennäköisesti korjata ongelman.Ei kiva ratkaisu, mutta tärkein asiani on, että on vältettävä sitä, että I2C pääsee ensin kyseiseen tilanteeseen.
Claudio Avi Chami
2016-06-04 02:31:50 UTC
view on stackexchange narkive permalink

Miksi kysyt vain virhetarkistuksista?

Kuinka voit olla varma, että alkuehdot tulkitaan oikein? Langallisessa tai langattomassa tietoliikenteessä kehyksen alku on hyvin monimutkainen bittien yhdistelmä, kun taas RS-232: ssa se on yksinkertainen suuresta alhaiseen muutokseen ja I2C: ssä yksinkertainen protokollarikkomus.

Oma asiani on että virheen tarkistus ei ole vain erilainen, mutta kaikki protokollan elementit ovat paljon, paljon yksinkertaisempia sisäisillä protokollilla kuin langattoman ja langattoman viestinnän vastaavat. Syynä on se, että virheen todennäköisyys on useita kertoja pienempi kuin langallisessa / langattomassa viestinnässä.

ACK-bitti tarkistaa komennon vastaanoton, eikö?(Entä jos ACK käännetään? Menee ikuisesti ...) Uudelleenlähetys on toinen viestintäkohta ja se on hyväksyttävä monille sovelluksille.Nastan ajaminen väärälle tasolle bittikäännön ja riittämätön virhetarkistuksen vuoksi on paljon kriittisempää kuin uudelleenlähetys.
John Birckhead
2016-06-04 03:06:30 UTC
view on stackexchange narkive permalink

Lyhyt vastaus on, että monet laitteet, joihin I2C ja SPI on suunnattu, ovat pienitehoisia laitteita, joissa on pienet käskyjoukot ja rajoitettu ohjelmamuisti. Tekniset tiedot mahdollistavat niiden toteuttamisen laiteohjelmistolla, jolla ei ole yleisiä kustannuksia. Jos sinulla on hevosvoimaa, voit lisätä niin monta kerrosta kuin tarvitset, mutta nämä kerrokset eliminoivat monet pienet upotetut sovellukset.

En kuitenkaan voi muuttaa mainitun I2C I / O -laajennuslaitteen käyttäytymistä, vaikka muodostaisin yhteyden neliytimiseen prosessoriin (hevosvoimaa).En voi lisätä ylimääräistä virheenkorjausmekanismia sen päälle.
einzeln00
2016-06-04 02:31:42 UTC
view on stackexchange narkive permalink

En voinut antaa virheellistä vastausta, mutta vertailun. Verkkoprotokollat ​​tarvitsevat mekanismikerroksia, kaiken tarkoituksen tekeminen kerralla ei ole hyvä idea, sinulla ei ole pakettikoodeja PHY: ssä, ennen kuin MAC-kerros on havainnut 802.11: n RF-virheen.

SPI: llä ja i2c: llä on synkronoitu kello, joten virhesuhde ja viestintäristiriidat ajoituksessa ovat vähäisiä, ja laitteita niiden toteuttamiseksi pidetään niukkana.

se on kaikki mitä voin ajatella. / p>

user5792628
2018-02-10 17:31:46 UTC
view on stackexchange narkive permalink

Etsi tietty ratkaisu tiettyyn ongelmaan.

Jos sinulla on 3 relettä, jotka vaativat ehdottoman luotettavuuden: Mittaa sitten niiden lähtö 3 digitaalisella tulolla, redundantilla vahvistusjärjestelmällä, joka on räätälöity sovelluksellesi.

Jos valitsisit suunnitellessasi mukautetun yhteyskäytäntöprosessin ratkaistaksesi kaikki luotettavuusongelmat lopullisesti, tekisit yleisen suunnitteluvirheen. Poikkeaminen erityisvaatimuksista päästä sivuraiteelle yleisesti.

Eric Novikoff
2020-03-18 22:44:24 UTC
view on stackexchange narkive permalink

Ensinnäkin on tärkeää muistaa, että I2C tarkoittaa integroitujen piirien ja integroitujen piirien viestintää. Se on suunniteltu toimimaan sirulta sirulle PC-kortilla. Kuitenkin sellaisissa järjestelmissä kuin Raspberry Pi, joka ajaa I2C-yhteyttä kaapeleiden kautta, standardia ei käytetä siihen, mihin se oli tarkoitettu, ja tuloksena oleva signaalin heikkeneminen tarkoittaa, että lähetys tulee olemaan paljon todennäköisempi virheille. Luen tätä ketjua, koska etsin vihjeitä siitä, miten I2C-virheitä voidaan vähentää Raspberry Pi -asennuksessani.

Jokainen väyläni I2C-yhteensopiva laite tarkistaa ja luo CRC: t väylävirheiden varalta. Mikä ei tarkista virheitä, on saapuva I2C-laiteohjain Linuxissa, mutta voit helposti löytää kirjastot verkosta C: lle tai Pythonille tarkistamaan palaavat CRC: t. Voin kertoa teille, että niiden tarkistaminen avasi silmät, koska hälyttävä osa palanneista tiedoista oli huono. Hylkään sen vain ja yritän lukea tiedot uudelleen, mutta pidemmän aikavälin ratkaisu on suunnitella I2C-järjestelmäni siten, että siinä on vähemmän etäisyyttä / kapasitanssia. Harkitsen I2C-kytkintä laitteiden eristämiseksi omilla signaaliajoillaan. Tai siirtyminen Modebusiin tai CANbusiin, jotka ovat sähköisesti kestävämpiä (ja hieman kalliimpia käyttää, koska laitteet ovat kalliimpia.)

Pitkistä signaaliajoista peräisin olevan standardin heikkouksista johtuen on joitain virheitä, kuten orjalaite pitää SDA: ta, jota ei voida palauttaa tyypillisillä linux I2C -ohjaimilla ja jotka voivat vaatia virrankierron. Voit korjata Pi-väylän lukitukset muuttamalla I2C-nastat yleisiksi I / O-nastoiksi ja palauttamalla väylän ohjelmistossa tarvittavilla yhdeksällä kellolla 400 KHz: llä, ennen kuin vaihdat ne takaisin I2C-toimintoon, mutta siellä on paljon tämä sisältää C-koodin vaatimisen CLK-nastan vaihtamiseksi tarpeeksi nopeasti palautusta varten. Vaikka olen nähnyt tämän keskustellun verkossa, en ole vielä löytänyt koodia sille, ja harkitsen vain kirjoittamista itse. Tai pelastaa I2C: n.

Muuten, mielestäni I2C: n käyttö lähellä sitä, mihin se oli tarkoitettu, kuten tyttärikorttien liittäminen Pi: hen, on melko turvallista.Minulla ei ole ollut ongelmia tällaisten mallien kanssa.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...