co sie stanie gdy dwa wezly w tym samym czasie rozpoczna nadawanie ramek o tym samym ID (czyli priorytecie) ale o innej zawartosci prawdopodobnie podczas nadawania zostanie zgloszony blad. ale czy docelowo wezel ktory czeka na te informacje otzyma je i konroler cana sam sie tym zajmie zby ponowic transmisje czy tez musze nadac ramki sam tylko kazda w innym czasie
pytanie 2 jak dokladnie w canie jest z mailboxami? wysyłam dane przez jakiś mailbox ale do ktorego on trafia w wezle odbierajacym? w jaki sposob wykorzystac cana aby nie był on, jak ktos napisal, tylko szybkim rsem czy moge podmapowac w wezle jakąś srtukture (8 bajtów) do któregoś mailboxa i wszelkie zmiany tej struktury beda przenosily sie automatycznie na struktury w innych wezlach?
Użytkownik "Sławomir Kapelko" snipped-for-privacy@elka.pw.edu.pl> napisał w wiadomości news:cnuv0m$n76$ snipped-for-privacy@news.onet.pl...
Nigdy nie stosowałem CANa więc mogę się mylić. Arbitraż ma miejsce chyba tylko w czasie ID więc nie powinno być dwu ramek o takim samym ID. Jakby były to z danych zrobi się AND - nie będą ani z jednej, ani z drugiej ramki.
Użytkownik "Sławomir Kapelko" snipped-for-privacy@elka.pw.edu.pl> napisał w wiadomości news:cnuv0m$n76$ snipped-for-privacy@news.onet.pl...
W zasadzie należy unikać takich sytuacji. Każda ramka powinna mieć swój niepowtarzalny ID. Ale moim zdaniem nie powinno się stać nic specjalnie groźnego. A co się stanie w takiej sytuacji? Myślę (bo nie robiłem w praktyce takich crash-testów), że może wystąpić jeden lub szereg błędów:
*!!! błąd bitu - kontroler wystawiając bity na szynę sprawdza jednocześnie, co się tam pojawiło i jeśli wykryje różnicę, to zgłosi błąd;
błąd formy ramki - niektóre bity w ramce mają ustalony poziom i kontroler powinien wykryć taką niezgodność;
błąd bitu wypełniającego - jeśli w ciągu bitów kilka (chyba 5 - nie pamiętam) mają ten sam poziom, to dodawany jest tzw. "stuff bit" o poziomie przeciwnym do tego ciągu, usuwany automatycznie podczas odbioru - jeśli tego bitu nie będzie, to kontroler zgłosi błąd;
błąd CRC - każda ramka posiada dodawaną i sprawdzaną sprzętowo sumę CRC - jej niezgodność też spowoduje błąd. Najbardziej prawdopodobne jest, że wystąpi, wymieniony przeze mnie jako pierwszy, błąd bitu, czyli kontroler wykryje, że wystawił na szynę stan recesywny, a wrócił do niego stan dominujący (na szynie CAN nie ma pojęcia stanów typu jedynka i zero, tylko recesywny i dominujący). W takim przypadku kontoler przerywa nadawanie ramki i czeka na zawolnienie szyny. Następnie ponowi nadawanie. Za pewne, ten drugi węzeł, z którym rozpatrywany kontroler wszedł w konflikt nie będzie ponownie próbował nadawać, bo poprawnie dostarczy ramkę. Jest to jak najbardziej możliwe, bo dana transmisja wysypała się na bicie dominującym wystawionym przez ten drugi węzeł, którego rozpatrywany nie mógł zakłócić.
Trafią one do tego mailboxa, którego ID z uwzględnieniem ewentualnej maski będzie pasowało do ID danej ramki. Zazwyczaj jest tak, że jeśli dany kontroler ma kilka mailboxów, i ramka pasuje do kilku z nich, to pojawi się w pierwszym według wewnętrznej kolejności obsługi w kontrolerze. Ale tu dużo zależy od rozwiązanie konkretnego kontrolera. Tak jest, np. w mikrokontrolerach DSP Texasa serii 24xx z wbudowanym CANem.
CAN nigdy nie będzie tylko szybkim RSem. :) Zwłaszcza, że jeśli odliczyć ten cały śmietnik, który dodawany jest do każdej porcji 8 bajtów, to efektywny transfer spada 2..3x w stosunku do RSa. Ale mamy za to zrealizowane sprzętowo adresowanie odbiorców, arbitraż w sieciach wielomasterowych i rozbudowaną kontrolę poprawności transmisji z automatycznym powtarzaniem w przypadku błędu. W końcu CAN nie został zaprojektowany z myślą o szybkiej transmisji dużych porcji danych.
Możesz, ale automatycznie nic się nie prześle. Każdą transmisję musisz świadomie zainicjować w programie.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.