Cześć wszystkim

Na podstawie kursu autorstwa SunRiver http://forum.atnel.pl/topic1183.html, chciałem postawić swoją sieć CAN. Najpierw wykonałem moduły u układach MCP2515 i MCP2551 z wejściami SPI. Było to moje pierwsze lutowanie SMD wiec szału nie ma ale starałem się zrobić to porządnie.







Powstały dwa takie moduły, każdy podłączyłem do Atmegi328p o taktowaniu 8MHz. Korzystam z bibliotek MCP2515 dostarczonych w poradniku oraz biblioteki UART z GB.

No i teraz pojawiły się schody. Moduły nie chcą mi się od razu zainicjować.



Mikrokontroler nie może wykonać pozytywnie funkcji mcp2515_init().

Sprawdzałem miernikiem kilka razy poprawność połączeń na płytce. Wszystko wygląda dobrze. Podczas pomiarów okazało się, że kiedy dokonuje pomiaru napięcia linii RX i TX pomiędzy MCP2515 i MCP2551 za którymś razem(czasem od razu) moduł inicjuje się. Podobnie dzieje się przy pomiarze linii wyjściowych MCP2551 - CANL i CANH.

Początkowo prace układu sprawdzałem dla pojedynczego modułu wraz z mikroprocesorem. Następnie funkcjonowanie sprawdzałem dla dwóch modułów połączonych ze sobą, gdzie każdy moduł miał Atmege328p identycznie skonfigurowaną. Moduły spiąłem za sobą zgodnie ze schematami z poradnika, umieściłem dwa rezystory terminujące 120R.
W obu przypadkach dzieje się to samo. Jeśli nic nie robię, moduły nie inicjują się - nawet przez 20min. Cały czas odczytuje w terminalu te informacje. Tu powtórzę: Kiedy zacznę dokonywać pomiarów, za którymś pomiarem opisanym wyżej, moduł inicjuje się.

Nie mam pomysłu co może być źle. Zakładam że skoro moduły potrafią się zainicjować - kiedy wpływam na nie, to układy działają. Jednak z drugiej strony, w kodzie wymagam narazie tylko inicjalizacji.
Doczytałem na forum, że komuś pomogło dociskanie układów MCP. Mi nie pomogło

Co mogę robić źle? Może coś przegapiłem.

Poradnik dokładnie przeczytałem, swoja drogą bardzo przystępnie napisany. Wydaje mi się, że wszystko jest jasne. Jednak dopóki nie zrobię sam takich urządzeń, nie będę tego rozumiał tak dobrze jak autor. Dlatego proszę o wskazówki, albo wskazanie błędu który może być oczywisty.


Pozdrawiam,
Tomek

Podczas inicjacji kontroler CAN czeka na potwierdzenie od jakiegokolwiek innego modułu, że go "usłyszał", czyli próby z samotnym modułem w "sieci" są z góry skazane na porażkę.



Pisałeś o terminatorach, a o podciąganiu linii CAN H i L nic nie wspominasz, mogą okazać się niezbędne do wymuszenia stanów "recesywnych" na sieci.

Dziękuje za odpowiedz.

Zrobiłem to zgodnie z tym schematem poniżej oraz z takim opisem, cytuje "Dla sieci CAN najczęściej stosowanym medium transmisyjnym jest para skręconych przewodów, tworząca magistralę dla dołączanych węzłów. Magistrala (dwie linie: CAN-H i CAN-L) z obu stron powinna być zakończona dopasowującymi imp. (terminatory – 120ohm). "


Nie wiedziałem że trzeba podciągnąć linie danych.


Mam to zrobić tak jak w przypadku tego schematu do Modbusa? Rozumiem że układy muszą mieć wspólną masę.

te układy mają tryb "loopback" w którym można sprawdzić jeden układ, konieczny jest terminator miedzy tx i rx.

tomek2864
w Twoim kodzie jest:


a w poradniuku deklaracja

nie ma tam też "return"

Moim zdaniem sieć działa, tylko sprawdzanie wartości funkcji zwracającej "void" powoduje wysłanie nie prawdziwej informacji o aktywacji układu. Ustaw jeden moduł żeby coś wysyłał, a w drugim przekieruj to na uart i zobacz czy jest odbierane.

W ostatnim kodzie zamieszczonym w poradniku, jest program podsumowujący(wraz z instrukcją dla loopback). Funkcja mcp2515_init zwraca typ bool. Jest ona wsród paczki plików zamieszczonych w poradniku SunRivera ale pozwolę sobie ja tutaj przywołać.



Autor w programie testowym robi inicjacje tak:


Mi wydaje się to dziwne, ponieważ jeśli moduł będzie niegotowy, następuje zapętlenie nieskończone. Nie rozumiem po co. Dlatego, dodałem pętle while() a for() usunąłem.



Chciałbym spróbować nawiązać komunikacje(przesłać coś i to odebrac), jednak oba mikrokontrolery ciągle próbują zainicjować swoje kontrolery CAN. Niestety one same z siebie, nie inicjują mi się. Musze wpłynąć na ich prace np. dokonując pomiarów a i to nie zawsze wychodzi.
Chciałbym rozwiać moje wątpliwości co do pull-up na magistrali. Mam je robić? Nie znalazłem w opisach sieci CAN, informacji że takie pull-upy są konieczne.

no funkcja wygląda poprawnie, tylko ten bool.. w standardzie C go nie ma, trzeba dołączyć bibliotekę no to nic, można i tak.

sprawdź połączenia z siecią, czy rezystory na obu końcach są miedzy H i L, czy masa jest wspólna.
Pamiętam że walczyłem z uruchomieniem mojego mcp aż się okazało że musi być połączony nawet do pustej sieci.

napisz jeszcze kiedy się uruchamiają, gdy mierzysz woltomierzem napięcie miedzy H i L? jeśli tak to może wskazywać na problem z rezystorami.

kurcze ciężko coś wymyślić..

Ja bym zaryzykował z tym podciąganiem. U siebie mam na obu końcach magistrali po 2,2k na H i na L.
O loopbacku zapomniałem całkiem, ale jeśli dobrze pamiętam to jest metoda na test wewnętrzny mcp2515,
który w tym trybie nic nie wysyła na driver(2551) albo nie nasłuchuje, tylko wewnętrznie łączy swoje tx i rx tworząc echo,
jeśli się mylę to mnie poprawcie.

Z tym uruchamianiem to na prawdę wygląda bardzo randomowo. Raz mi się uruchomił jak mierzyłem napięcie pomiędzy poligonem(GND) a ścieżka RX lub TX. Co ciekawe, niekoniecznie łączy się ten mikrokontroler którego moduł mierze tylko ten drugi Ale na 100 pomiarów tylko z trzy, cztery raz poszło. Czasami się udało jak sprawdzałem napięcia na liniach CAN H i CAN L, ale to tez co przy co 30 pomiarze. Czasami jak, dosłownie - masowałem moduł, następowała inicjacja. Jednak czasami z 10min próbuje je zmusić do pracy - masuje, mierze, dociskam, chucham i dmucham a one nic:( Tak jak pisałem na początku, wszystkie ścieżki sprawdzałem omomierzem czy są połączone z odpowiednimi nóżkami oraz sprawdzałem dla każdego pinu czy napięcie na nim jest takie jak na ścieżce.
Na sieci jest stan recesywny. Napięcia pomiędzy GND-CANH oraz GND-CANL wychodzą 2.4-2.5V. Różnicowe napięcie jest w mV.





Żeby dokładnie zobrazować jak podciągnąłem rezystory wykonałem rysunek:


Nie miałem rezystorów o wartości 2,2k, dlatego oba Rp podłączyłem o rezystancji 2,7k ohm. Rp- terminatory mają cały czas 160ohm. Układ zachowuje się tak samo. Jak mu się zachce to się aktywuje, ale zaznaczam że dzieje się to jak coś przy nich dotykam. Jeśli zostawię wszystko, to nawet z 30min mija a one nic.

Tak wygląda cała funkcja main(), którą wgrałem do układów. Jest to funkcja z poradnika SunRiver'a z paroma moimi poprawkami.



Próbowałem zrobić jakieś pseudo debugowanie funkcji mcp2515_init(), wiem że zwraca ona false w tym warunku


CNF1, ten rejestr odpowiada za ustawienia prędkości.



Jedyne co się różni to to że SunRiver robił te konfiguracje dla mikroprocesora taktowanego z zewnątrz 16MHz. Moje są taktowane z wewnątrz z 8MHz. Jednak, to nie powinno robić różnicy, ponieważ jak rozumiem, zmienia to tylko taktowanie SPI z 8MHz na 4MHz. Jednak przy 125kbps to chyba nie powinno robić CAN'owskim kontrolerom różnicy.
Nie mniej jednak, inicjacja nie przechodzi pozytywnie tutaj. Nie wiem dlaczego...

Cała funkcja init

Gdy ja uruchamiałem ten zestaw (MCP2515+2551) robiłem to na ATMega8 taktowanym wewnętrznym RC 8MHz i ruszyło bez żadnych problemów, więc i u Ciebie powinno zadziałać, ale na schemacie który zamieściłeś mcp taktujesz z kwarca 8 MhZ, czy to nie wymaga przypadkiem zmiany w bittimingu?, no chyba że błąd jest na schemacie, ja miałem 16M tak samo jest u Sun`a.

Gdybyś przerobił swoją funkcję debagującą tak, żeby zamiast tekstu wysłała wartość zwracaną przez mcp2515_read_register(CNF1) mogło by się co nieco wyjaśnić, a tak wiesz tylko że różni się ona od zadanych wartości preskalerów (BPRx), być może otrzymujesz 0, bo np MCP2515 nie odpowiada - w funkcji init w tym momencie pierwszy raz próbujesz cokolwiek odczytać z tego kontrolera.

Jeśli powyższe okaże się prawdą, a nawet jeśli nie to popraw luty na tym układzie, zwłaszcza pin 9 czyli GND sprawia wrażenie "zimnego".

To prawda. Dziękuje że zwróciłeś mi na to uwagę. MCP taktuje z 8MHz. Pokierowałem się wartością oscylatora na schemacie z poradnika.



rej=mcp2515_read_register(CNF1);
Zwraca 255.



Musze kupić oscylatory 16MHz i przy ich przylutowywaniu od razu poprawie brzydkie luty. Boje się tylko rozlutowywania tych obecnych. Chciałbym najpierw uruchomić sieć aby wiedzieć że fizycznie wszystko gra. Na razie nie mogę zrozumieć z noty ustawień dla Bit Timing, a nie chce na ślepo i bez pełnego zrozumienia manipulować przy tych rejestrach aby nie tworzyć dodatkowych błędów. Może wydziwiam, ale przydałby się tam jakiś przykład obliczania ustawień dla danych parametrów.

Ja uruchomiłem ten zestaw zgodnie z przykładami SunRiver`a, a potem przesiadłem się na STM, f103 ma wbudowany kontroler CAN więc MMCP2515 nie jest mi potrzebny, a w stm'ach jest trochę inny zestaw rejestrów niż mcp2515. Niemniej wydaje mi się że w ds mcp2515 jest opisane obliczanie segmentów czasowych -bittiming, chyba nawet wzory były, zresztą o ile dobrze pamiętam poradniki Sun'a tam też była o tym mowa, ale gdzieś w komentarzach. Generalnie chodzi o to, że pojedynczy bit składa się z segmentów, czas trwania każdego z nich jest wielokrotnością kwantu czasu. Zakładając czas trwania tego kwantu, oraz ilość tych kantów dla poszczególnych faz bitu wiesz ile trwa jeden bit, a z tego wynika prędkość transmisji, ale szczegóły to już w dokumentacji np kontrolera z którym walczysz.

A odnośnie zwracane wartości, sprawdzałeś co znaczą poszczególne bity w CNF1? I czy napewno taką wartość próbowałeś wpisać.

Nie czekaj z lutowaniem na kwarca tylko porządnie podgrzej pady, żeby zimnych lutów nie było. Nie chodziło mi o wygląd tylko o to, że skoro układ zaczyna działać gdy przy nim manipuluje to pewnie coś nie łączy, np gnd.

Wiesz co, porównałem Twoją funkcję mcp2515_init z tą od Sun`a i różnica jest spora , nie używasz funkcji mcp2515_write_register(), której pierwszym argumentem jest adres docelowy, tylko pakujesz swoje BPR`y nie do końca wiadomo gdzie, 45 linia w Twoim kodzie.
To wyjaśniałoby dlaczego próbujesz ustawić preskaler a z CNF1 odczytujesz coś zupełnie innego.
Przy tej konfiguracji powinieneś odczytać bitowo 11000111 czyli 199 jeśli się nie mylę, Twoje 255 znaczy tyle, że masz dodatkowo ustawine BPR3-5.
Jeśli chodzi o obliczenia to strony 37-42 w DS wszystko wyjaśniają, nie jest to nie wiadomo jak straszne a może oszczędzić przelutowywania kwarca, jeśli tylko można przeliczyć i zmienić wartości w rejestrach.

Init z którego korzystałem był w w jednym z plików archiwum zamieszczonym na końcu poradnika. Też zastanawiało mnie dlaczego tam jest przesyłanie po SPI.



Teraz zmieniłem wszystko, zamieściłem tylko funkcje które były w poradniku zamiast tych z archiwum.

Init wygląda teraz tak:


Obecny main()




Tylko że nadal odczytuje wartość 255. Zarówno dla wartości bit timingu od SunRiver'a jak i tych nowych zapisanych w hex. Wartości te wygenerowałem sobie przy pomocy programu "Microchip Controller Area Network (CAN) Bit Timing Calculator".

Tutaj wrzucam rezultat, wygenerowany przez ten program. U doły są wartości HEX, które chciałem wgrać.


Poprawiałem dziś luty nóżek scalaków przy obu modułach. Sprawdzając omomierzem wszystko piszczy. GND również poprawiłem oraz luty kwarców. Luty pinów i gniazd śrubowych jeszcze poprawie ale to jutro bo dziś miałem dostępny tylko grot 0.4mm.

Wziąłem się za dokładne tłumaczenie 5roz z noty, postaram się to jeszcze dziś przed spaniem ogarnąć. Może przyjdzie coś nowego do głowy. Jednak martwi mnie to że pomimo wykorzystana już prawidłowej funkcji do zapisu rejestrów, ciągle jest to samo przy odczycie.

1.
2.

Jutro po 16 będę miał dostęp do kompa to podeślę Ci swój kod.
A z innych rejestrów możesz odczytać prawidłowe dane?

Sprawdziłem:


I dla wszystkich mam 255, choć żaden z tych rejestrów nie powinien mi taką wartością odpowiadać.

Zapewne sprawdzałeś dla obu płytek i w obu przypadkach dostajesz 255,co eliminuje problemy sprzętowe.
Podeślę jutro działający projekt, to coś może się wyjaśni.

Naprawdę, to musi być jakiś felerny zbieg okoliczności. Do wystartowania korzystam z gotowych funkcji, które są sprawdzone. Dlatego, mimo wszystko nie wykluczałbym jeszcze problemów sprzętowych. Sprawę uprościłby oscyloskop. Musze w końcu założyć sobie dla niego skarbonkę

Sprawdzam oba mikrokontrolery, tylko że muszę przekładać pin TX ponieważ mam jeden konwerter UART. Jutro wraz z kwarcami 16MHz będę miał drugi, uprości mi to pogląd sytuacji.

A ciekawe co byś dostał od funkcji, gdybyś wogóle nie połączył mcp2515 do megi.
A na czas programowania odłączasz mcp od spi, bo mnie często przerywało flashowanie i musiałem odpisać,
nie mam żadnej separacji.

Jest to samo po odłączeniu układu. Nie nawiązują ze sobą łączności. Tak sobie myślę, że przedtem MCP potrafił się załączyć kiedy na niego wpłynąłem. Czy aby dobrze zrobiłem kwestie resetowania? Może moje mierzenie, resetowało go. Reset mam cały czas podciągnięty do VCC. Na nóżce 17(RESET) MCP mierze napięcie zasilania. Ale kiedy on ma się zresetować skoro napięcie VCC jest z zasilacza(to samo źródło zasila uP), wiec jest cały czas podtrzymywane. Zgodnie z tym schematem RST mam wyprowadzone na jednym z PINów ale nic do niego obecnie nie podłączam. Powinienem moduł jakiś przerobić aby jednak moc sterować zasilaniem dochodzącym do nóżki RESET?



Kiedyś jak bawiłem się kartą SD musiałem odpinać piny SPI. Tutaj układ mi się programuje. Oczywiście sprawdzałem to i nie było różnicy, mikrokontrolery pracowały tak samo.

PS. To nie powinno mieć znaczenia ale wole napisać że kondensatory przy oscylatorze mają wartość 33pF. 27pF akurat nie mogłem dostać.

Reset musi być podciągany do + ,ja mam go podłączonego do AVR`a ale w funkcji init ten pin jest tylko ustawiony i nie wykorzystywany, jeśli masz wymuszony stan wysoki przez rezystor, to nie powinno Ci bruździć.
W załączniku mój projekt na m8 poza inicjacją MCP wysyła jedynie dwie wiadomości w zależności od stanu dwóch przycisków miał być enkoder i dlatego taka nazwa się tam przewija. Na pewno błędów tam nie brakuje ale działa.

Dołożyłem jeszcze projekt z m16, poza inicjacją obsługa ds18b20 i wysyłanie wyników pomiaru.
Porównaj zawartość wszystkich plików w katalogach mcp25xx ze swoimi wersjami.
p.s. Ale będzie obciach jak problem będzie w podłączeniu modułu do AVR`a.

Na pierwszy rzut oka bibliotekę masz taką jak ta z archiwum w poradniku. Zaprzęgłem ją do siebie i mam takiego maina()



Dodałem też w init mcp


no i taka odpowiedz


Mam tylko odpowiedz z jednej atmegi.
Coś nie mogę uruchomić drugiego układu uP. Mam go na płytce uniwersalnej i od spodu są elementy powlekane. Musze sprawdzić czy nic mi się tam przypadkowo nie zwiera.

Dziękuję, że chce Ci się tak angażować w pomoc dla mnie:) Dziś już nie mogę przy tym grzebać ale jutro podłącze wszystko na nowo, sprawdzę jeszcze raz pracę każdego układu. Porównam też dokładnie Twoje biblioteki MCP2515 z tymi SunRiver'a. Mam oscylatory 16MHz więc będę mógł zrobić z nich użytek.

Spokojnego wieczoru.

Dobrze by było jednak to ogarnąć, patrząc na liczbę wyświetleń tego wątku kibiców nie brakuje .
Biblioteki to dzieło Sun`a, ja dopisałem tylko te funkcje od obsługi rozszerzonych (extended) nagłówków, więc inicjacji nie modyfikowałem.
Swoją drogą dobrze, że mnie ruszyło od kopa, bo bym pewno w kąt rzucił i do RS485 wrócił.

Heh teraz to już nie wypada rzucać tego w kąt






Teraz pewna historia. Wczoraj wieczorem już się poddałem, ponieważ działy się "dziwne" rzeczy. Mianowicie łączyłem ze sobą układ 1 i 2(ze zdjęcia). Mikroprocesory ustawione są identycznie, dodatkowo wyjmowałem je i zamieniałem ze sobą. Po włączeniu zasilania z odłączonymi modułami CAN, mikrokontroler nr 1 wypisał "USART TEST" i dalej konturował inicjalizacje MCP(nie podpiętych) wypisując "255 E:MCP nie gotowy". Drugi natomiast wypisał tylko "USART TEST" i podziękował - nic już się nie odzywał, jakby utknął w nieskończonej pętli. Zamieniłem mikroprocesory, konwertery USART, porty COM, zasilałem z programatora ATB lub zasilacza stabilizowanego. Wgrałem inne programy na mikrokontroler 2, które działały. Dziś chciałem wszystko powtórzyć i otrzymałem ten sam rezultat. Uznałem że zrobię nową płytkę bo być może ta na płytce uniwersalnej szwankuje. Tak powstał układ trzeci ze zdjęcia. Podłączyłem układ 3 i się okazało że bez modułu pracuje tak jak ten układ 2, czyli napisał "USART TEST" i podziękował. No i trochę zonk, układy 2 i 3 działają tak samo a to 1 się wyróżnia. Ciągle bez modułów CAN.

Tak wygląda podłączenie moich układów:


Pominąłem na zdjęciach podłączanie konwerterów RS aby nie robić zamieszania. Tak sytuacja wygląda w terminalu. Układy 2 i 3 wraz z modułami CAN zaczęły więcej pisać. Jednak układ 2 z CAN'em 1, wypisuje USART TEST i się zacina, albo dodatkowo wypisuje kilkanaście razy 255 i po jakimś czasie milknie. Z kolei układ 3 z CAN'em 2, wypisuje rożne wartości rejestru. Musiałem uruchomić ponownie układy ponieważ uP nr. 2 się zacinał. Jednak jak widzisz na screenie, 3 się aktywowała. Dodałem po czasie w kodzie, zwrócenie rejestru po aktywacji. CNF1 zwraca wtedy 0. Wniosek wyciągam na razie taki, że moduły CAN nie są do siebie bliźniaczo podobne. Muszę się zastanowić, może wykonam jeszcze jeden moduł. Miernikiem już tyle sprawdzałem, on jest na bank sprawny. ahhh




PS. Oscylatorów jeszcze nie wymieniłem. Ciągle mam 8MHz. Jak obecnie rozumiem to wszystko, pomimo innego taktowania nie powinny się dziać takie rzeczy.

Ile czasu musi upłynąć od uruchomienia 3 do pełnej udanej aktywacji mcp? Czy wynik jest powtarzalny?
Może trzeba dać jakieś opóźnienie po próbie init()? w końcu taktujesz kontroler wolniejszym kwarcem, to i zapis do rejestrów zapewne będzie trwał dłużej.
Wszystkie trzy moduły CAN zbudowałeś tak samo (ten sam schemat, identyczna płytka)? Dlaczego nie miały by być bliźniacze?

Właśnie zobaczyłem, że masz delay`a.

------------------------ [ Dodano po: 20 minutach ]

O jasna ch. czy wszystkie Twoje moduły są zbudowane na płytce wg wzoru z pierwszego postu?
Przecież wogóle nie masz podłączonego drugiego pinu kwarcu do MCP pin 8.
Zrób tak jak w załączniku, ewentualnie zmień złącze do CAN i kondensatory na smd.
NIE lepiej podłącz kawałkiem przewodu i testuj.

W obu dodałem przewód oraz zamieniłem oscylatory na 16MHz. Zdziwił mnie ten błąd. W projekcie Eagla, w tworzeniu PCB nie wie o tej ścieżce - choć na schemacie jest. Może przypadkowo dokonałem jakieś zmiany, kiedy nie powinienem.


Sytuacja się nieco zmieniła. Jest o tyle spoko, że prawie za każdym uruchomieniem układów sytuacja się tak przedstawia. Moduł po lewej wypisuje 255 kilkanaście razy, a potem trochę 127 i znów 255. Tak w kółko.
Moduł po prawej cały czas wypisuje 255. Sprawdzałem napięcia na ścieżkach, i wartości tych napięć są porównywalne przy obu modułach CAN.
[ obrazki umieszczamy w MINIATURKACH - zgodnie z instrukcją umieszczania obrazków na forum - mirekk36 ]

Oba moduły CAN mają taki sam schemat. Pisząc - że nie są bliźniacze, miałem namyśli ich prace. Teraz ich praca jest bardziej zbliżona. Oba się nie inicjują i dlaczego odczytują te 255... Co to pytania o ich udaną aktywacje. Teraz już taka nie następuję. Kiedy dokonuje pomiarów to po jakimś czasie, ten mierzony wypisze 0 i się zawiesza. Wtedy też na nóżce INT jest spadek napięcia - podczas wypisywania 255 napięcie tam wynosi 4V.

PS. na tym zdjęciu ten przewód może źle wygląda ale nie zwiera się do GND.

Coś ten screen nie chce się wgrać tak jak powinien. Przepraszam

Czyli poprawne podłączenie kwarca wszystko popsuło? Przestaję to rozumieć.Zbyt dużo robi nam się możliwych przyczyn.
Dlaczego 4v na int; albo zasilanie 5v, albo 0v? Dlaczego manipulacje multimetrem powodują zwiechy, albo prawidłowy init i dlaczego nie jest to powtarzalne?

Proponuję "głęboki wdech", rozbierz to w drobiazgi, jeszcze raz zaprojektuj płytkę CAN (chcesz to wypróbuj moją wersję), polutuj na spokojnie,
od nowa podłącz uwzględniając definicje pinów MISO, MOSI, SCK, CS, RST, INT (ja mam to w pin_config.h),
sprawdź jeszcze raz podłączenia i wtedy spróbuj uruchomić.

Tak w sumie mógłbym Ci wysłać swój moduł do testów.

Chyba się udało! Pisze że chyba ponieważ nie mogę odebrać wiadomości na sieci. Ale układy przechodzą przez inicjację i wysyłają wiadomość w trybie loopback, po czym ją odbierają.
Co poprawiłem? Od czasu dodania nowego oscylatora i przewodu, podgrzałem każdy pad na płytkach i wszędzie dodałem jeszcze cyny. Dosłownie tak że jest ona na nóżkach widoczna. Zmiana była taka że oba układy dawały mi wartość 255 ale ciągle jeden z nich, nie próbował inicjować MCP. Pobrałem jeszcze raz cały kod SunRiver'a. Usunąłem wszelkie odczytywanie z rejestrów i wywalanie czegokolwiek na USART. Teraz jeden z układów odrazu wypisuje mi że poprawnie aktywowano MCP, a drugi muszę po chwili włączyć do zasilania aby też się połączył.

Próbuje teraz nadać cokolwiek na sieci i to odebrać. Wydaje się że tryb loopback działa. Nie działa mi natomiast nadanie wiadomości do drugiego układu. Układ, który w while() nadaje wiadomość, po drugiej próbie nadania(napisania do buforu), już wypisuję tylko błąd - że nie może wysłać.

Kod jest SunRiver'a, różnica jest tylko w pętli while() w obu modułach.
Moduł pierwszy:


Moduł drugi:

Czyli oba przechodzą inita?
W sieci masz conajmniej 2 moduły? w normalnym trybie podczas nadawania ramki moduł odbierający nie wystawia przypadkiem. ACK? No bo chyba nie próbujesz jednocześnie nadawać z obu modułów takich samych ramek chodzi o id, mogłoby. dojść do utraty arbitrażu, a wtedy ramka pozostaje w buforze i go blokuje, dlatego ja miałem funkcję która sprawdzała czy aby bit mla nie został ustawiony dla któregoś z buforówi jakby co, to ponowna próba wysłania.
p.s. Nie lubię pisać z telefonu

Oba przechodzą inta. Mam dwa moduły w sieci. Jeden z nich w pętli while() tylko odczytuje wiadomość a drugi tylko wysyła - co dwie sekundy. Chciałbym odebrać tą wiadomość. Wtedy bedę już na 100% wiedział że sieć działa.

Wcześniej, przed pętlą, każdy moduł przechodzi pozytywnie tryb loopback

Projekt na m8 pełnił u mnie rolę "nasłuchu ", chyba tę wersję wysłałem w załącznikach.
Skoro inita przechodzą i w normal wchodzą to już z górki.
P.s. dzięki za pochwałę, polecam się