NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jakie są ograniczenia maksymalnej ilości danych w ramce CAN według standardu?
Tawez
Guest
Guest
Fri Oct 22, 2004 4:58 pm
Witam,
chodzi o magistralę CAN
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
--
pozdrawiam
Tawez
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
peters
Guest
Guest
Fri Oct 22, 2004 5:23 pm
Quote:
chodzi o magistralę CAN
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
Maksymalnie 8. Nic jednak nie stoi na przeszkodzie, bys przesylal dlugie
bloki danych (np pliki) dzielac je na 8-bajtowe ramki.
peters
Piotr Gałka
Guest
Guest
Sat Oct 23, 2004 8:15 am
Użytkownik "Tawez" <tawezWYTNIJTO@poczta.onet.pl> napisał w wiadomości
news:3ab6.00000a10.41794a3b@newsgate.onet.pl...
Quote:
Witam,
chodzi o magistralę CAN
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
chodzi o magistralę CAN
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
To jest po to, aby ramki o wyższym priorytecie (alarmy itp.) nie
czekały bo ktoś sobie zrobi ramkę 1024 bajty.
P.G.
Tawez
Guest
Guest
Sat Oct 23, 2004 12:07 pm
Quote:
chodzi o magistralę CAN
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
Maksymalnie 8. Nic jednak nie stoi na przeszkodzie, bys przesylal dlugie
bloki danych (np pliki) dzielac je na 8-bajtowe ramki.
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
Maksymalnie 8. Nic jednak nie stoi na przeszkodzie, bys przesylal dlugie
bloki danych (np pliki) dzielac je na 8-bajtowe ramki.
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.
--
pozdrawiam
Tawez
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Tawez
Guest
Guest
Sat Oct 23, 2004 12:09 pm
Quote:
chodzi o magistralę CAN
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
To jest po to, aby ramki o wyższym priorytecie (alarmy itp.) nie
czekały bo ktoś sobie zrobi ramkę 1024 bajty.
ze specyfikacji, którą mam ze strony http://www.can-cia.de
wynika że w ramce może być maksymalnie 8 bajtów danych
czy jest to absolutne maksimum, czy o czymś nie wiem.
(poruszamy się na płaszczyźnie standardu)
To jest po to, aby ramki o wyższym priorytecie (alarmy itp.) nie
czekały bo ktoś sobie zrobi ramkę 1024 bajty.
No tak, trochę zapomniałem o podstawowym przeznaczeniu tej magistrali.
--
pozdrawiam
Tawez
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
neuron
Guest
Guest
Sat Oct 23, 2004 1:52 pm
Quote:
To jest po to, aby ramki o wyższym priorytecie (alarmy itp.) nie
czekały bo ktoś sobie zrobi ramkę 1024 bajty.
No tak, trochę zapomniałem o podstawowym przeznaczeniu tej magistrali.
czekały bo ktoś sobie zrobi ramkę 1024 bajty.
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
www.neuron.com.pl
Dariusz Zolna
Guest
Guest
Sat Oct 23, 2004 3:26 pm
Użytkownik "neuron" <neuron@WONTOzipnet.com.pl> napisał:
Quote:
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
!!
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
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
neuron
Guest
Guest
Sat Oct 23, 2004 6:14 pm
Quote:
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 :)
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 .
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 :)
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
Tawez
Guest
Guest
Sat Oct 23, 2004 7:26 pm
Quote:
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
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ć ;>>
--
pozdrawiam
Tawez
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Dariusz Zolna
Guest
Guest
Sat Oct 23, 2004 8:15 pm
Użytkownik "neuron" <neuron@WONTOzipnet.com.pl> napisał:
Quote:
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.
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.
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
peters
Guest
Guest
Sun Oct 24, 2004 10:08 am
Quote:
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ę ;
dokładnie jeszcze nie policzyłem,
ale jest duże prawdopodobieństwo, że dane stracą aktualność
zanim je prześlę ;
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
Tawez
Guest
Guest
Sun Oct 24, 2004 11:37 am
Quote:
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ę ;
Ile uC bedzie w Twoim rozwiazaniu sie ze soba komunikowac? Wszystkie
przesylane komunikaty musza miec wysoki priorytet?
dokładnie jeszcze nie policzyłem,
ale jest duże prawdopodobieństwo, że dane stracą aktualność
zanim je prześlę ;
Ile uC bedzie w Twoim rozwiazaniu sie ze soba komunikowac? Wszystkie
przesylane komunikaty musza miec wysoki priorytet?
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.
Quote:
Podstawowe zalety CAN-a to architektura mulimaster oraz krotkie ramki i
arbitraz. Umozliwia to wlasnie szybkie przeslanie krotkiego komunikatu.
arbitraz. Umozliwia to wlasnie szybkie przeslanie krotkiego komunikatu.
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.
Quote:
Mozna latwo obliczyc maksymalny czas po jakim taki komunikat dotrze do
odbiorcy.
odbiorcy.
jeśli wszystko potrzebne do tego jest w dokumentacji, to można :)
--
pozdrawiam
Tawez
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
peters
Guest
Guest
Sun Oct 24, 2004 2:48 pm
Quote:
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.
Mozna latwo obliczyc maksymalny czas po jakim taki komunikat dotrze do
odbiorcy.
jeśli wszystko potrzebne do tego jest w dokumentacji, to można :)
1. masz male odleglosci. jest wiec szansa na ustawienie sporej szybkosci
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.
Mozna latwo obliczyc maksymalny czas po jakim taki komunikat dotrze do
odbiorcy.
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.
3. co do narzutu to nie koniecznie jest tak zle. Na dane masz 8 bajtow, ale
masz tez 11 (standard frames) lub az
29(extended frames) bitow na numer urzadzenia, typ ramki a nawet na numer
kolejnej paczki danych.
4. 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
elektroda NewsGroups Forum Index - Elektronika Polska - Jakie są ograniczenia maksymalnej ilości danych w ramce CAN według standardu?