Koordynacja nadawania ramek w CAN: co się dzieje przy tym samym ID?

Tue Nov 23, 2004 9:13 am   

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?

pozdrawiam i prosze o wyrozumialosc
slawek

Tue Nov 23, 2004 9:48 am   

Użytkownik "Sławomir Kapelko" <skapelko@elka.pw.edu.pl> napisał w
wiadomości news:cnuv0m$n76$1@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.

P.G.

Wed Nov 24, 2004 8:22 am   

Użytkownik "Sławomir Kapelko" <skapelko@elka.pw.edu.pl> napisał w wiadomości
news:cnuv0m$n76$1@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.

QmX.