CAN

Maksymalnie 8. Nic jednak nie stoi na przeszkodzie, bys przesylal dlugie bloki danych (np pliki) dzielac je na 8-bajtowe ramki.

peters

U¿ytkownik "Tawez" snipped-for-privacy@poczta.onet.pl> napisa³ w wiadomo¶ci news: snipped-for-privacy@newsgate.onet.pl...

To jest po to, aby ramki o wy¿szym priorytecie (alarmy itp.) nie czeka³y bo kto¶ sobie zrobi ramkê 1024 bajty.

P.G.

widzę przynajmniej jedną przeszkodę, narzuty dawane przez ramkę komunikatu. ale rzecz jest oczywiście warta przemyślenia.

czasam muszę przesyłać kilka bajtów, a czasami cały ekran VGA. trzeba pomyśleć o innym rozwiązaniu.

No tak, trochę zapomniałem o podstawowym przeznaczeniu tej magistrali.

CAN wymaga psychicznego przelamania pewnej bariery - to nie jest szybki rs !! CAN w zamysle swoich tworcow ma umozliwoac realizacje przestrzennie rozproszonej pamieci. Nie wysylasz polecenia '' zmien bit w bajcie x w sterowniku y'' tylko poprostu go zmieniasz - ot taka subtelna roznica :)

wojtek

U¿ytkownik "neuron" snipped-for-privacy@WONTOzipnet.com.pl> napisa³:

Nie. CAN zapewnia tylko przesy³anie danych z korekcj± b³êdów. To o czym piszesz jest realizowane w wy¿szej warstwie (np w wyspecjalizowanym uP).

Darek ¯o³na

Zdecydowanie ma kolega racje - ale wlasnie o te warstwe mi chodzi . Oczywiscie mozna wykorzystac warstwe fizyczna CANa i jego kontrolery aby zrobic cos w stylu szybkiego modbusa - sam mam cos takiego rozwarzalem. Jednak gdzie by nie zajrzec i z kim by nie porozmawiac to wszyscy traktuja CANa jak szybkiego rsa - a przeciez cala frajda z jego wykorzystania jest taka ze mozna koncentrujac sie na wyzszych warstwach uzyskac struktury danych wymieniane miedzy procesorami poza swiadomoscia programisty. Nikt mowiac o stosach tcp/ip (poza kilkoma abitnymi programistami ktorzy robia je na piechote) nie zawraca sobie glowy ile bitow ma ramka na ethernecie. wojtek

tak, tylko stosunek danych do informacji nadmiarowych w ramce jest w przypadku ethernetu trochę lepsza ;) niż w CAN w CAN masz w _najlepszym_ przypadku ~1:1

w moim konkretnym przypadku mam system działający w czasie rzeczywistym. dokładnie jeszcze nie policzyłem, ale jest duże prawdopodobieństwo, że dane stracą aktualność zanim je prześlę ;>

dlatego trzeba pomyśleć o innym rozwiązaniu. albo bardzo dobrze policzyć ;>>

U¿ytkownik "neuron" snipped-for-privacy@WONTOzipnet.com.pl> napisa³:

No a mnie CAN akurat interesuje ze wzglêdu na swoje w³a¶ciwo¶ci do których by³ zaprojektowany, czyli wiarygodnego przesy³ania danych w dosyæ trudnym ¶rodowisku jakim jest samochód :-) Tyle ¿e prawdê mówi±c dopiero rozpoznajê ten temat, a wykorzystujê I2C ;-)

Darek ¯o³na

Ile uC bedzie w Twoim rozwiazaniu sie ze soba komunikowac? Wszystkie przesylane komunikaty musza miec wysoki priorytet? Podstawowe zalety CAN-a to architektura mulimaster oraz krotkie ramki i arbitraz. Umozliwia to wlasnie szybkie przeslanie krotkiego komunikatu. Mozna latwo obliczyc maksymalny czas po jakim taki komunikat dotrze do odbiorcy.

peters

system ma być rekonfigurowalny czyli liczba węzłów zmienna, ograniczona z góry specyfikacją CAN (CAN przykłądowo bo brane są jeszcze pod uwagę I2C, RS-422A/485). dla tego jedyny wiarygodny parametr to pesymistyczny czas na dostardzenie komunikatu. na szczęście odległości są niewielkie - maksymalnie 50cm. Oczywiście, jeśli skorzystamy z dobrodziejstw CAN, priorytety komunikatów będą zróżnicowane. Zastanawiałem się nad dynamiczną zmianą tych priorytetów.

Komunikaty będą różne, przeważnie 1-2 ramki wystarczą, ale czasami trzeba będzie przesłać całą klatkę VGA więc albo trzeba zmienić architekturę albo magistralę, albo jedno i drugie; albo założenia.

jeśli wszystko potrzebne do tego jest w dokumentacji, to można :)

1. masz male odleglosci. jest wiec szansa na ustawienie sporej szybkosci transmisji.
2. rozumiem, ze przesylanie calej klatki VGA bedzie nastepowalo na tyle rzadko, ze magistrala sie nie zapcha.

-to jest chyba pierwsza rzecz, jaka musisz rozstrzygnac.

1. co do narzutu to nie koniecznie jest tak zle. Na dane masz 8 bajtow, ale masz tez 11 (standard frames) lub az

1. wez kalkulator i oszacuj czy przy zalozonej szybkosci transmisji uda sie przeslac tyle danych ile musisz przesylac. Jesli istotny bedzie fakt prawie natychmiastowego przesylania krotkich komunikatow o wysokim priorytecie, jesli przesylanie duzych blokow danych bedzie odbywalo sie z niskim priorytetem (w tle) to magistrala CAN jest dobrym wyborem. Odciazy procesory od zmudnego odbierania bajtu po bajcie, liczenia CRC a przede wszystkim od sterowania rywalizacja o dostep do magistrali. Zapewni dodatkowo, ze w systemie nie bedzie slabego punktu w postaci komputera sterujacego transmisja (architektura multimaster)

peters