ATNEL tech-forum

Re: Siec CAN - układy MCP2515 i MCP2551

2016-05-30T20:20:48+01:00

Witam wszystkich jako nowy na forum i od razu z grubej rury.
Mam identyczny problem jak tomek tak więc podłącze się do tematu.
U mnie sprawa wygląda tak iż z jednej strony mam STM32 + MCP2515 + MCP2551 a po drugiej stronie ATMEGA + MCP2515 + MCP2551
Jako moduły użyłem gotowych dostępnych w handlu.
Po obu stronach moduły przechodzą init.
STM32 nadaje a AVR ma odebrać wiadomość i przesłać poprzez RS na terminal.
Problem jest taki iż w rejestrach TXBnCTRL otrzymuje 0x18 tak więc analizując problem tomka mam coś na magistrali.
Lecz magistrala to 15cm przewodu. Nie pomaga rozłączenie modułów.
W każdym module mam wpięte rezystory 120ohm. Po stronie AVR'a mam podciągnięcia do masy oraz +5V poprzez rezystory 2,2kohm.
Kończą mi się już pomysły.
Loopback przechodzi bez problemu.

Statystyki: Napisane przez Samuraj — 30 maja 2016, o 20:20

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-15T12:24:20+01:00

Tak, w dokumentacji jest coil voltage 24V/48V, ale już przy opisie produktu na stronie zamówienia:
http://sklep.impol-1.pl/Zam%C3%B3wienia ... fault.aspx
jest 12V. Napisałem do nich, żeby nie było że przyślą niewłaściwy stycznik.

Statystyki: Napisane przez tomek2864 — 15 kwi 2015, o 12:24

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-15T07:53:09+01:00

Z pdf`a wynika, że produkują również wersje 48V.

Statystyki: Napisane przez volt_1 — 15 kwi 2015, o 07:53

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-14T20:18:13+01:00

Wybrałem taki stycznik:
http://sklep.impol-1.pl/Portals/1/ZelNet_HermesNet/ProductFiles/B_70E%203GY12DGFW.pdf
tyle że z napięciem cewki 12V. Prąd jest tam do 60A, a chwilowy do 80A.
Co do projektu, to po jego ukończeniu dam znać i pochwale się.

Statystyki: Napisane przez tomek2864 — 14 kwi 2015, o 20:18

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-11T18:21:46+01:00

Proponował bym ten prąd pobierany przez silnik przemnożyć x 1,5; tak się robi dla odbiorników indukcyjnych.
Na jakie napięcie jest cewka tego przekaźnika, nie widziałem przekaźników samochodowych na 48 v.

Jak już uruchomicie maszynę to pochwal się.

Statystyki: Napisane przez volt_1 — 11 kwi 2015, o 18:21

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-08T19:10:10+01:00

Skuter powinien przetrwać deszczową pogodę, także będziemy musieli rozpatrzeć jakieś szczelne obudowy chroniące elektronikę. Jednak hermetyczne złącza, z jakąś mechaniczną blokadą wyjdą tylko na plus.

Jestem Ci wdzięczny za wszystkie wskazówki. Dotychczas nie myślałem tak poważnie o doborze złącz i przewodów. Trochę tego okablowania będzie, wiec warto też z głową podejść do ułożenia tras kabli. Tym bardziej, że silnik mamy o mocy 1,75kW, a bateria jest o napięciu 48V. Oznacza to, że natężenie prądu płynącego w głównym kablu zasilającym może przekraczać 35A. Dodatkowo przewidujemy umieszczenie przekaźnika(np. przekaźnik samochodowy LR-4120) do głównej wiązki oraz przekaźniki do świateł i zasilania modułów. Wszystko może generować szereg zakłóceń.

Zaopatrzyłem się w książkę "Elektrotechnika i elektronika w pojazdach samochodowych" - Anton Herner, Hans-Jürgen Riehl. Liczę że pomoże mi wejść głębiej w temat rozwiązań elektronicznych stosowanych w motoryzacj. Nic tak nie uczy jak praktyka, ale skądś jakieś podstawy muszę posiąść aby resztę szybciej przyswoić

Statystyki: Napisane przez tomek2864 — 8 kwi 2015, o 19:10

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-06T10:55:49+01:00

A nie powinieneś szukać hermetycznego złącza? i najlepiej z mechaniczną blokadą przed rozpięciem przy wibracjach.
No chyba, że planujesz moduł razem ze złączem zamknąć w szczelnej obudowie.

Podobne do Twego złącza oznaczone jako typ EDG ja stosuję w swoich modułach w domu ale u mnie nie będzie drgań, a w większości pomieszczeń będzie względnie sucho i czysto. Ja stosuję pojedyncze złącze, ale pod jeden pin podłączam dwa przewody zaciśnięte w jednej tulejce.
Oczywiście dwa oddzielne złącza są o wiele wygodniejsze w obsłudze i ewentualnych przepinkach-rozbudowach, ale zajmują dodatkowe miejsce na płytce i w obudowie.

Jeśli chodzi o przewód:
- aluminiowy ekran kojarzy mi się z folią aluminiową, czyli problem z wyprowadzeniem/ podłączeniem tego ekranowania, a na jednym z końców każdego odcinka trzeba ekran "uziemić". Wolałbym pełen oplot, no chyba, że źle zrozumiałem opis.
- przekrój żyły ok jeśli będzie to wiązka nieruchoma, jeśli ma pracować na styku dwóch elementów mechanicznych, szybko będziesz ją wymieniał, dobra praktyka każe stosować 1mm2, jednocześnie zbyt sztywna izolacja całego kabla spowoduje połamanie i poprzecieranie żył, tu musisz poeksperymentować.
- w zwykłych pojazdach z napędem spalinowym wiązki w ramie i w komorze silnika muszą być wykonane w izolacji olejoodpornej, ale Wasz skuter ma być elektryczny jak pamiętam, więc problemem będą zakłócenia od napędu.
Pociągi, które uruchamiałem miały kable zasilające silniki napędowe w podwójnym oplocie ekranującym, pomyślcie o tym w swoim projekcie.

Budowa węzłów zależy od producenta / gałęzi przemysłu:
- w automatyce przemysłowej "stacjonarnej" (PLC itp) przeważnie stosuje się złącza D-SUB męskie + damskie podobnie jak w Twojej wizji jednym gniazdem wchodzi do modułu drugim wychodzi.
- w przemyśle kolejowym podobnie jak wyżej, dwa złącza jedno in drugie out, choć są przypadki gdzie obie funkcje pełni jedno złącze, wtedy po prostu dwa przewody są w jednym pinie, co do użytych złącz to pełna gama: począwszy na podobnych to tego Twojego Phoenix`a, D-Sub`y, RJ, M12 wszystko zależy od producenta osprzętu. Tak było w firmie w której pracowałem.

Oba powyższe przypadki to szyna zgodna ze specyfikacją Bosch`a czyli magistrala z ograniczoną do minimum długością odczepów, terminatory włączane switchami/zworkami w węzłach na obu końcach szyny.

- w przemyśle motoryzacyjnym wolna amerykanka:
*jeśli na danym CAN`ie jest więcej niż 2 moduły/węzły to stosuje się "punkty gwiaździste" zwane również "rozdzielaczami potencjałów" i od tych punktów doprowadza się linie do danego węzła (nierzadko jest to kilkanaście metrów dla zestawów "ciężarowych"), terminatory są zabudowane w rozdzielacz (tak jest u mojego obecnego pracodawcy) czyli faktycznie jest to jeden rezystor umieszczony gdzieś w centralnym punkcie sieci bo szyną to trudno to nazwać.
*złącze jest zależne od modułu/sterownika, bo ster silnika, hamulców, AirBag, wszelkie komforty, multimedia itp każdy ma inne złącza.

P.S. Pisząc o ETH miałem na myśli przemysł i kolei, o zastosowaniu w motoryzacji praktycznej nie słyszałem, podobno były eksperymenty ale jakoś się nie przyjęły. Za to w osobówkach wchodzi światłowód, na szczęście zanim wejdzie do powszechnego użytku w ciężarówkach to jeszcze zdążę z probówką popracować.

Statystyki: Napisane przez volt_1 — 6 kwi 2015, o 10:55

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-04T21:41:59+01:00

Jest to projekt, który wykonujemy w ramach koła naukowego a więc hobbistycznie.
Z tego co wiem, to Ethernet zyskuje popularność również w przemyśle. Podobno jego budowa nie zapewnia determinizmu czasowego dla dostarczania wiadomości, ale mądrzy ludzie sobie z tym poradzili i przykładowy ProfiNet z powodzeniem zastępuje Profibus'a.
Najpóźniej we wakacje planuje podjąć się pierwszych samodzielnych prac, przy budowie sieci opartej o Ethernet oraz realizacji komunikacji Wifi. O LIN'ie słyszałem dosłownie kilka zdań, ale dobrze widzieć że warto go znać szerzej. Strasznie dużo tego wszystkiego, ale to dobrze - jest w czym wybierać

Powiedz mi, jak wyglądają węzły dołączające urządzenie do sieci CAN? Dla Ethernetu są wtyczki RJ45, więc hub/switch. Jak widziałeś teraz wykorzystałem gniazda śrubowe. Tyle że są niewygodne. Myślałem o aby każde urządzenie miało dwie takie listwy 4piny:

Jedna listwa doprowadzałaby V,GND,CANH,CANL, a druga wyjściowa odprowadzająca sygnały i zasilanie do następnego modułu.
Co do wyboru przewodów, masz namyśli jakąś konkretną firmę? Myślałem o przewodzie ze sklepu elektronicznego, prezentującego się następująco:
Liczba żył: 4 + ekran
Przekrój jednej żyły: 0,5mm²
Izolacja wykonana z PCV
Typ żyły: wielodrutowa, linka, YTDY
Aluminiowy ekran z miedzianą żyłą.
Wychodzi ok. 1zł za mb.
Terminacje zrobiłbym w każdym module, z możliwością jej podciągnięcia do sieci przy pomocy zworki. Takie zwarcie wykonałbym dla pierwszego i ostatniego urządzenia. Powinno to działać i być w miarę pewnie wykonane.

Wszystkiego dobrego.

Statystyki: Napisane przez tomek2864 — 4 kwi 2015, o 21:41

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-04T07:39:31+01:00

Praca dyplomowa, czy hobby?
Owszem, CAN obecnie dominuje w pojazdach wszelkiego rodzaju, chociaż ma też swoje mankamenty i dlatego koncerny motoryzacyjne tworzą coraz to nowe sieci komunikacyjne, np LIN który niby dużo wolniejszy od Can`a i bez multimastera ale za to jaki stabilny i odporny na zakłócenia.
Jeśli chodzi o sieć rozproszoną to największa z jaką miałem doczynienia była na pociągach,łączna długość szyny sporo ponad 200 metrów, sterowniki rozrzucone po całym pojeździe, ale dla bezpieczeństwa był redudantny CAN i ciągłe porównywanie komunikacji na obu z nich.
Obecnie popularność zyskuje Ethernet.

Z mojego doświadczenia podpowiem:
1) dobrze przemyśl jakie funkcje będą realizowane przez który moduł.
2) ustal sobie dostatecznie długie timeout`y w oczekiwaniach na komunikaty.
3) nie żałuj środków na dobrej jakości, bardzo dobrze ekranowane przewody dla szyny.

Statystyki: Napisane przez volt_1 — 4 kwi 2015, o 07:39

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-03T23:22:51+01:00

Finalnie sieć miałaby działać na skuterze. Projektujemy go mechanicznie i elektrycznie, stopniowo urzeczywistniamy. Trzeba wpakować trochę elektroniki do pomiaru drgań, przerobienia komercyjnej stacyjki - zamiast kluczyka odbiornik RFID/iButton z przyciskiem "Start Engine" do zapłonu(jeśli w elektryku można mówić o zapłonie) , wszystkie te dane, zdarzenia zapisywać i wyświetlać. Ogólnie pomysłów jest bardzo dużo, pracy również ale wszystko po kolei. Awaria jednego urządzenia, nie może wpłynąć na prace pozostałych. Dlatego musi to być rozproszony system, który trzeba skomunikować ze sobą.
CAN rządzi w niemalże każdym samochodzie. Nie miałem z nim jeszcze do czynienia, a skoro jest tak powszechny to znaczy że musi być ciekawy i wart poznania. Chyba się nie mylę?

Statystyki: Napisane przez tomek2864 — 3 kwi 2015, o 23:22

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-03T09:45:32+01:00

Dobrze, że w końcu się udało.
Teraz pobaw się filtrowaniem odbieranych ramek.

Mógłbyś bliżej opisać swoje plany? Co chcesz w przyszłości tym CAN`em "napędzać"?

Statystyki: Napisane przez volt_1 — 3 kwi 2015, o 09:45

Re: Siec CAN - układy MCP2515 i MCP2551

2015-04-02T20:44:17+01:00

Równo miesiąc z tym walczyłem, ale było warto Udało mi się nadać i odebrać wiadomość
Tak wygląda fragment nadanej ramki, jest w niej ACK.

Polutowałem dwa nowe moduły. Byłem co do tego sceptycznie nastawiony, ale jednak. Wina leży w wykonaniu poprzednich modułów CAN. Nadal nie wiem, co z nimi jest źle. Tak wyglądają dwa nowe, dziś polutowane i jeden z tych starych modułów. Trochę lepiej mi teraz wyszło, to lutowanie SMD.

Kiedy w sieci jest moduł nadający i odbierający, w rejestrach TXBnCTRL nadającego mam zera po nadaniu wiadomości. Jak odłączę drugi moduł - odbierający, rejestry TXBnCTRL zapełniają się wart. 24.

Dziękuję za pomoc! Volt, przez Twoje komentarze nie odpuściłem tematu:D Mam nadzieje że będzie już z górki, chce rozbudować transmisje i skomunikować ze sobą kilka urządzeń. Czysta przyjemność:)

Statystyki: Napisane przez tomek2864 — 2 kwi 2015, o 20:44

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-31T20:16:45+01:00

Polutowałeś już nowe moduły? To powinno wyjaśnić sprawę sprzętową.

Statystyki: Napisane przez volt_1 — 31 mar 2015, o 20:16

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-31T00:47:18+01:00

Większe prawdopodobieństwo jest w tym, że błąd jest natury technicznej - w budowie modułów CAN? Nie chce niepotrzebnie błądzić. Dlatego muszę, stopniowo ograniczać obszar poszukiwań. Lepszego pomysłu nie mam.

Statystyki: Napisane przez tomek2864 — 31 mar 2015, o 00:47

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-29T22:22:25+01:00

Przed wejściem do pętli głównej while(), ustawiam tryb normalny
[syntax=c]mcp2515_bit_modify(CANCTRL, (1<Moduł, który nadaje zawiera w pętli tylko procedure wysłania, przy użyciu funkcji mcp2515_send_message:
[syntax=c]PRINT("Próba wysłania wiadomości przez CAN\r\n");

if (mcp2515_send_message(&message)) {
PRINT("Wiadomość została napisana w buforze\r\n");
read_rej();
}
else {
PRINT("Błąd: Nie można wysłać wiadomości\r\n");
read_rej();
}
_delay_ms(2000);[/syntax]

Tak wygląda definicja funkcji mcp2515_send_message, która jest prosto z archiwum w poradniku Sun'a
[syntax=c]uint8_t mcp2515_send_message(tCAN *message)
{
uint8_t status = mcp2515_read_status(SPI_READ_STATUS);

//* Statusbyte:

// * BitFunction
//* 2TXB0CNTRL.TXREQ
// * 4TXB1CNTRL.TXREQ
//* 6TXB2CNTRL.TXREQ

uint8_t address;
if (bit_is_clear(status, 2)) {
address = 0x00;
}
else if (bit_is_clear(status, 4)) {
address = 0x02;
}
else if (bit_is_clear(status, 6)) {
address = 0x04;
}
else {
// all buffer used => could not send message
return 0;
}

RESET(MCP2515_CS);
spi_putc(SPI_WRITE_TX | address);

spi_putc(message->id >> 3);
spi_putc(message->id << 5);

spi_putc(0);
spi_putc(0);

uint8_t length = message->header.length & 0x0f;

if (message->header.rtr) {
// a rtr-frame has a length, but contains no data
spi_putc((1<}
else {
// set message length
spi_putc(length);

// data
for (uint8_t i=0;ispi_putc(message->data[i]);
}
}
SET(MCP2515_CS);

_delay_us(1);

// send message
RESET(MCP2515_CS);
address = (address == 0) ? 1 : address;
spi_putc(SPI_RTS | address);
SET(MCP2515_CS);

return address;
}[/syntax]

W module odbiorczym sprawdzałem funkcje z poradnika mcp2515_get_message() oraz odbierz_can()
mcp2515_get_message() :
[syntax=c]uint8_t mcp2515_get_message(tCAN *message)
{
// read status
uint8_t status = mcp2515_read_status(SPI_RX_STATUS);
uint8_t addr;

if (bit_is_set(status,6)) {
// message in buffer 0
addr = SPI_READ_RX;
}
else if (bit_is_set(status,7)) {
// message in buffer 1
addr = SPI_READ_RX | 0x04;
}
else {
// Error: no message available
return 0;
}

RESET(MCP2515_CS);
spi_putc(addr);

// read id
message->id = (uint16_t) spi_putc(0xff) << 3;
message->id |= spi_putc(0xff) >> 5;

spi_putc(0xff);
spi_putc(0xff);

// read DLC
uint8_t length = spi_putc(0xff) & 0x0f;

message->header.length = length;
message->header.rtr = (bit_is_set(status, 3)) ? 1 : 0;

// read data
for (uint8_t i=0;imessage->data[i] = spi_putc(0xff);
}
SET(MCP2515_CS);

// clear interrupt flag
if (bit_is_set(status, 6)) {
mcp2515_bit_modify(CANINTF, (1<}
else {
mcp2515_bit_modify(CANINTF, (1<}

return (status & 0x07) + 1;
}[/syntax]

odbierz_can():
[syntax=c]uint8_t odbierz_can(void)
{if (mcp2515_check_message())//czy INT w stanie niskim?
{
uart_puts("M odebrano\r\n");
if(j>9) j=0;//jesli ilosc odebranych wieksza niz 10 to zerujemy licznik
// Czytanie wiadomości z buforów MCP2515
if (mcp2515_get_extend_message(&odebrane_ramki_can[j]))//jesli udalo sie odczytac wiadomosc to zapiszemy ja w tablicy
{

if (odebrane_ramki_can[j].header.eide)//jesli jest to ramka rozszerzona
{

uart_putint(odebrane_ramki_can[j].Dane[0],10);
uart_puts("\r\n");
uart_putint(odebrane_ramki_can[j].Dane[1],10);
uart_puts("\r\n");;
uart_putint(odebrane_ramki_can[j].Dane[2],10);
uart_puts("\r\n");
uart_putint(odebrane_ramki_can[j].Dane[3],10);
uart_puts("\r\n");
uart_putint(odebrane_ramki_can[j].Dane[4],10);
uart_puts("\r\n");
uart_putint(odebrane_ramki_can[j].Dane[5],10);
uart_puts("\r\n");
uart_putint(odebrane_ramki_can[j].Dane[6],10);
uart_puts("\r\n");
uart_putint(odebrane_ramki_can[j].Dane[7],10);
uart_puts("\r\n");
uart_puts("F:");uart_putint(odebrane_ramki_can[j].Funkcja,10); uart_puts("\r\n");
uart_puts(" N:"); uart_putint(odebrane_ramki_can[j].Nadawca,10); uart_puts("\r\n");
uart_puts(" O:");uart_putint(odebrane_ramki_can[j].Odbiorca,10); uart_puts("\r\n");
uart_puts("\r\n");uart_putint(odebrane_ramki_can[j].header.rtr,10); uart_puts("\r\n");
// GLCD_WriteString(" dlc:");GLCD_Int(odebrane_ramki_can[j].header.length);
//
// GLCD_TextGoTo(0,8);// set text coordinates
// for(uint8_t i=0;i// GLCD_Int(odebrane_ramki_can[j].Dane[i]);
// GLCD_WriteChar(';');
// }
analizuj_wiadomosc(&odebrane_ramki_can[j]);

}

j++;//zwiekszamy licznik do tabeli
}
else {uart_puts("\r\n");// set text coordinates
uart_puts("E: Nie mozna ode\r\n");_delay_ms(1000);
return 0;}

}[/syntax]

W przypadku obu funkcji odbiorczych, ciągle oczekują one na odbiór. Moduł nadawczy, ustawia rejestry TXBnCTRL na 24 czyli jedynki dla TXERR i TXREQ.
Filtrów nie ustawiałem. Chciałbym uruchomić najpierw najprostszą transmisje.

Sprawdziłem funkcje
[syntax=c]mcp2515_send_extend_message(&message)[/syntax]
dla
[syntax=c]MYtCAN message;
message.Funkcja=100;
message.Nadawca=My_CAN_Adres;
message.Odbiorca=Ogolny;
message.header.length=1;
message.header.eide=1;
message.header.rtr=0;
message.header.res=0;
message.Dane[0]=0xaa;[/syntax]

Taki wygląda ramka:

Na końcu jest brak potwierdzenia jako NAK - negative-acknowledge.
Rejestry TXBnCTRL dla czytają to samo, a odbiorczy bez wzruszenia nasłuchuje

Statystyki: Napisane przez tomek2864 — 29 mar 2015, o 22:22

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-28T21:46:11+01:00

Jaglarz napisał(a):

A nie różnią się pewnie niczym...

może ... ale oryginał to oryginał i ma suport

właśnie nie widzę tu potwierdzenia.

Statystyki: Napisane przez SunRiver — 28 mar 2015, o 21:46

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-28T20:33:56+01:00

Właśnie widziałem na "Aledrogo" od 35, no trzeba będzie nabyć.

Panowie Moderatorzy, widzą na tym zrzucie bit potwierdzenia? bo na telefonie to kiepsko oglądnąć.

Statystyki: Napisane przez volt_1 — 28 mar 2015, o 20:33

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-28T20:19:01+01:00

A nie różnią się pewnie niczym...

Statystyki: Napisane przez Jaglarz — 28 mar 2015, o 20:19

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-28T20:16:13+01:00

volt_1 napisał(a):

P.S. Ile taki analyzer kosztuje?

klon ok 40pln ... znajdziesz na taniocha markt
ja za swój logic16 dałem 1,7 kpln ..

Statystyki: Napisane przez SunRiver — 28 mar 2015, o 20:16

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-28T19:57:43+01:00

SunRiver napisał(a):

1. Adresat nie jest ustalony
2. Ramka nie jest kompletna

Tomek pokaż funkcję odbierz_CAN którą zastosowałeś w module odbiorczym?
A nadajesz przez _send_message, czy send_extend_message?
Nie wiem czy to może mieć wpływ, ale filtrów w odbiorczym nie ustawiłeś?
Moduł odbierający też wyprowadziłeś z LOOPBack`a?
Nie mogę teraz obejrzeć tego zrzutu, ale czy po CRC jest ACK od odbiornika; a później EOF?

P.S. Ile taki analyzer kosztuje?

Statystyki: Napisane przez volt_1 — 28 mar 2015, o 19:57

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-28T18:44:19+01:00

tomek2864 napisał(a):

sprawiłem sobie elegancki chiński analizator. Już pojawiły się pierwsze ciekawostki, które można uznać za postęp.

Widzisz ... może on chiński , ale swoją robotę robi , a czasem bez analizatora jak bez ręki ...
Ja bez saleae się nie biorę do roboty z magistralami, bo wole widzieć co tam się dzieje
a teraz tak...
Widzę ramka poszła ale cos jest nie tak w komunikacji prawdopodobnie nie zostaje zainicjowany odbiór
w module , czyli:

1. Adresat nie jest ustalony
2. Ramka nie jest kompletna
3. Inicjacja odbioru na magistrali nie wystąpiła

Statystyki: Napisane przez SunRiver — 28 mar 2015, o 18:44

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-28T16:04:17+01:00

Witam ponownie:), sprawiłem sobie elegancki chiński analizator. Już pojawiły się pierwsze ciekawostki, które można uznać za postęp. Do rzeczy:
Pierwsze moje kroki z obsługą takiego sprzętu, dały te oto ramkę

Jak widać Data Field Byte 171 i 205 daje to co przesyłam czyli
[syntax=c]message.id = 0x123;
message.header.rtr = 0;
message.header.length = 2;
message.data[0] = 0xab;
message.data[1] = 0xcd;[/syntax]
171 = 0xab
205 = 0xcd
A to dobrze.
Tylko dlaczego drugi moduł tego nie odbiera i dlaczego z rejestrów TXBnCNTRL modułu nadającego odczytuje 24?

Dodam że są to stare moduły. Nowe mam już wytrawione(poprawiłem linie do oscylatora), tyle że muszę je polutować

Ale mi to poprawiło humor

Statystyki: Napisane przez tomek2864 — 28 mar 2015, o 16:04

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-24T20:49:14+01:00

Muszę przyznać, że nie mam pomysłów na Twój problem.
A dodatkowo stwierdzam, że wynik pomiaru napięć, który właśnie wykonałem na swojej "sieci", potwierdza Twoje pomiary; jednocześnie burząc moje dotychczasowe wyobrażenia o stanach: dominującym i recesywnym.

Dotychczas uważałem, że stan recesywny czyli ustępujący, czyli sytuacja gdy żaden z węzłów nie wpływa na stan linii CAN H i L to różnica napięć wynikająca tylko i wyłącznie z faktu istnienia rezystorów podciągających (H~VCC, L~GND => 5V w moim i Twoim przypadku), a stan dominujący to wymuszona różnica ~ 0V.

Przyznaję, że w swych chaotycznych przemyśleniach zapomniałem o wpływie terminatorów na napięcia linii.
Nauka jednak nie pójdzie w las.

Tak więc u mnie w prawidłowo (tak myślę) działającej sieci, gdy żaden z węzłów nie nadaje (cisza w eterze) różnica napięć wynosi 200mV, niestety również nie posiadam sprawnego oscyloskopu więc napięć podczas transmisji nie podam.

Chyba jednak będziesz musiał polutować trzeci moduł i podmieniać go, aby wykluczyć czy któryś nie śmieci, ja bym tak próbował.
Ale może ktoś mądrzejszy zaproponuje inne rozwiązanie.

P.s. A może by spróbować użyć karty dźwiękowej do przybliżonego podglądu szyny, zakres napięć 5V powinien pasować, ale ale częstotliwość! baudrate trzeba by obniżyć, sam nie wiem, to chyba jednak kiepski pomysł.

Statystyki: Napisane przez volt_1 — 24 mar 2015, o 20:49

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-23T18:12:27+01:00

Z tych napięć wynika napięcie różnicowe. W druga stronę już nie. Gdybym podał tylko różnicowe powstała by niejasność jakie jest H-GND i L-GND. Zakładając pomiar innych napięć na modułach, można byłoby się spodziewać że któryś z nich źle pracuje. Dlatego zmierzone wartości tego nie wyjaśniły.

Napięcie różnicowe w przedziale [0;0.5]V daje stan recesywny czyli dla stanów logicznych 1 - jak napisałeś

Pomiar magistrali, + do CAN H, (-) do CAN L.
-Napięcie różnicowe na magistrali, kiedy żaden z modułów nie nadaje(tylko init) wynosi +0.05V. Odłączyłem najpierw każdy moduł z osobna i oba. Napięcie różnicowe nie uległo zmianie.
-Następnie, jeden moduł nadaje, drugi się tylko inicjuje. Wraz z pojawianiem się w rejestrach TXBnCTRL 24, napięcie różnicowe mierzę -0.57V. Kiedy odłączę moduł drugi(nie nadający) nie wpływa na zmianę napięcia, lecz ponowne podłączenie tego modułu, daje odczyt(różnie) w okolicy [-1; - 0.8] V, gdzie to napięcie zaczyna spadać aby ustabilizować się w okolicy -0.57V.

Co do analizatora to wydaje mi się że ważne aby pokazał przebiegi. Nie musi wspierać tych protokołów. W sieci są Saleae z okolicach 40zł, jest to cena do zaakceptowania. Pytanie tylko czy jest sens to kupować. Już kiedyś kupowałem miernik, lutownice za 30zł i i tak po paru miesiącach musiałem kupić droższy sprzęt, a tamto teraz leży i gnije...

Statystyki: Napisane przez tomek2864 — 23 mar 2015, o 18:12

Re: Siec CAN - układy MCP2515 i MCP2551

2015-03-23T17:01:48+01:00

tomek2864 napisał(a):

Wiec nie wyjaśniło to za bardzo niczego.

No raczej wyjaśniło, prosiłem o pomiar napięcia pomiędzy H i L, tymczasem jak wnioskuję mierzyłeś względem GND, no ale nawet, jeśli dla obu linii masz ten sam potencjał (różnica 50 mV) to znaczy, że ...? Napięcie różnicowe wynosi 0V, CAN to przesył różnicowy prawda?
http://en.wikipedia.org/wiki/CAN_bus
Według WIKIPEDII 0V to 1 bitowa.
Któryś z modułów nadaje?
Ja bym przy podpiętym voltomierzu (+ do CAN H, - do CAN L) odłączał od szyny kolejno same moduły CAN, tak żeby terminatory i podciąganie pozostało, i obserwował miernik.

P.S. mowa o analizatorze CAN czy SPI?

Statystyki: Napisane przez volt_1 — 23 mar 2015, o 17:01