Należy się

W while() projektu m8, tylko funkcja odbierz_can(); odbiera. Te warunki z enkoderem są przygotowane do wysłania danych. Wgrałem do procka ten projekt z samą funkcją odbierz_can(); w pętli. Jednak nic nie odbiera. Tak ogólnie to masz dość rozbudowane te funkcje. Dlatego wole najpierw wysłać i odebrać na podstawie po prostu mcp2515_send_message(&message) i mcp2515_get_message(&message). Wydaje mi się to logiczne, jak zrobiłem. No ale nie działa

One nie są rozbudowane, tam poprostu jest niezły bałagan.

Według oryginału funkcja mcp2515_check_message() sprawdza tylko stan pinu INT, następnie funkcja _get_message() sprawdza w którym z 2 "rejestrów/ mailboxów" odbiorczych znajduje się nowa wiadomość, odczytuje spod wyznaczonego "adresu" nagłówek i dane tejże wiadomości.
SUNRiver obsługiwał tylko standardowy nagłówek, ja potrzebowałem extended więc modyfikując na szybko oryginał strasznie nabałaganiłem, no ale u mnie działa.
MCP2515 ma jeszcze opcję filtrowania nadchodzących ramek/ wiadomości, ja z tego nie korzystałem, SUN chyba też nie, więc nie sądzę aby u Ciebie takie filtry się pojawiły i miały blokować odbiór ramek.

A pokaż wiadomość jaką wysyłasz.

Spróbuj w module nadającym, w chwilę po transmisji odczytać rejestry TXB0CTRL i TXB1CTRL, tam są chyba bity obrazujące status transmisji.

Nie ogarniam już tego. Tryb loopback niby się udaje a jednak jak widać na screenie odczyt rejestrów TXB0CTRL i TXB1CTRL, maja one wartości 0. To samo przy zmianie trybu na normalny. Nadawanie tam tez zwraca taka wartość. Zeby nie było wątpliwości, rejestry sprawdzam w module, którym nadaje wiadomość do urządzenia, które tylko nasłuchuje.

Ze zrzutu wynika, iż zapełniasz wszystkie trzy bufory nadawcze(TXB0-TXB2), a kolejne próby kończą się błędami, bo w buforach wciąż tkwią niewysłane ramki.

Natomiast wartości 0 w TXBnCTRL świadczą o tym, że albo transmisja przebiegła bez problemów (wtedy kontroler sam czyści bit TXREQ) co nie może mieć miejsca bo bufory się zapychają, albo w Twojej procedurze nadawczej brakuje na końcu żądania transmisji (ustawiony bit TXREQ w TXBnCTRL , gdzie n to nr bufora nadawczego oczywiście). ds. str. 17

W poprzednim poście pisząc o zrzutach z TXBnCTRL zapomniałem o trzecim - TXB2CTRL (moja wina), ale podejrzewam, że tam też masz 0.

Mając w pamięci poprzednie doświadczenie z NIEZAPISYWANIEM wartości do rejestrów lub odczytywaniem dziwnych wartości, zrobiłbym mały eksperyment, a mianowicie w zupełnie nowej funkcji wpisał do TXB0CTRL priorytet 1 czyli ustawiony bit TXP0, w TXB1CTRL priorytet 2 czyli bit TXP1, a w TXB2CTRL prior 3 czyli oba powyższe bity, a następnie odczytał zawartość tych rejestrów, ciekawe czy pokrywały by się z wartościami wpisanymi? ds. str.18

Korci mnie jeszcze, żeby zapytać czy aby nie masz zamienionych linii CAN H i L pomiędzy modułami. Taki twister w poprzedniej firmie zabrał nam kilkanaście godzin dochodzenia dlaczego tylko połowa cylindrów silnika pracuje.

Sprawdziłem dla obu tych procedur wysyłania:






"Clearing the TxBnCTRL.TXREQ bit while it is set, or setting the CANCTRL.ABAT"
Jest procedura ustawiająca i sprawdzająca czy rejestry TXBnCNTRL.TXREQ są 0, z tym że nie może ich ustawić. Wprawdzie jest to napisane tak: if (bit_is_clear(status, 2)) ale zgodnie z językiem najpierw jest czyszczenie bitu a potem sprawdzenie czy zwraca prawdę(powidło się czyszczenie). W ds jest mowa o ustawieniu CANCTRL.ABAT=1, ale to nie jest warunek konieczny jeśli TxBnCTRL.TXREQ są zero.


Ale już wiem co robiłem na pewno źle! Odczyt rejestrów robiłem w złej funkcji. Z tym że teraz, kiedy odczytuje rejestry, nie mam wartości 0 dla TxBnCTRL. Tak wygląda odczyt:


Sprawdzam czy poprawnie idzie zapisywać do rejestrów priorytety i je odczytać. Funkcje:


Wynik odczytu:


Widać zmiany w rejestrach, kiedy ustawiam priorytety. Kiedy następuje wysyła też się one zmieniają. Funkcja send nie zwraca też tutaj zera. Tylko że drugi moduł nie odczytuje nic. Sprawdziłem połączenie. Mam tak samo jak na poprzednich zdjęciach. Miernikiem też te połączenia są zwarte. Nie mam zamienionych linii H i L


Moduł odbierający w ma zapętloną funkcje odbierz_can(), z Twoich bibliotek

Wartości zwracane z TXBnCTRL są oczywiście w zapisie dziesiętnym?
24 bitowo 0b00011000 czyli bit TXERR ustawiony, znaczy szyna zajęta podczas próby nadania ramki.
Przy 81 dodatkowo ustawiny bit ABTF porzucono nadawanie ramki, ale tu użyłeś funkcji read_status, moim zdaniem jednak powinno być mcp2515_read_register(TXB1CTRL).

------------------------ [ Dodano po: 12 minutach ]

Właśnie poprawiałem
A gdybyś tak po udanej initi odłączył moduł odbierający, może on jednak śmieci?

W błąd Cie wprowadziłem.
Korzystam z mcp2515_read_register(TXB1CTRL), przy odczycie. Przedtem korzystałem z read_status co było błędem, i zwracało 0

czyli 24 to z read_register jest?

Tak, rejestry TXBnCTRL odczytuje funckja read_rej().

Odłączyłem moduł odbierający(kontroler CAN i atmege) od zasilania, po inicjacji obu układów. Nadawczy wypisuje to samo

Odpięcie podciągniętych rezystorów tez nie zmienia niczego

Zamień moduły CAN pomiędzy Megami, bo pewnie trzeciego modułu nie posiadasz w zapasie?
Moduł podczas nadawania ramki sprawdza stan linii RX i jak sam wystawia recesywny a jednocześnie odbiera dominujący to stwierdza błąd bo coś nadaje w tym samym czasie.

Do trzeciego mam płytkę wytrawioną ale posiada uszkodzoną jedną ze ścieżek. Dopiero w pn bym mógł ją zlutować.

Zmieniłem moduły CAN, w obu atmegach. Jest to samo, czyli kontrolery CAN pracują identycznie.

Zmień program w nadającym tak żeby nic nie nadawał żaden z modułów tylko init i cisza, a potem zmierz napięcie pomiędzy CAN H i L powinno być bliskie nap zasilania/ podciągania linii, ale jeśli będzie wynosić blisko 0V to jednak któryś zwiera, podobno 2551 są szczególnie wrażliwe na przepięcia, dziwne że inita przechodzą, a potem cuda.

Uporządkuje to:
uint8_t 24 to bitowo 0b00011000
czyli TXERR i TXREQ

TXERR: Transmission Error Detected bit
1 = A bus error occurred while the message was being transmitted.

Błąd na magistrali podczas przesyłania wiadomość

TXREQ: Message Transmit Request bit
1 = Buffer is currently pending transmission
(MCU sets this bit to request message be transmitted - bit is automatically cleared when
the message is sent)
Bufor jest zajęty i wystąpiło żądanie transmisji. Powinno wyczyścić ale nie czyści skoro if(bit_is_clear(status, 2)) zwraca fałsz. Więc wie że nie wysłał nic.

Także coś na magistrali dzieje się złego. Tylko co... po odłączeniu drugiego modułu nic się nie zmienia. Może ten kontroler sam się jakoś zakłóca? Ścieżki za blisko? Jakaś pasożytnicza pojemność gdzieś się nie tworzy...?

Wyjechałem z układami ale nie zabrałem miernika. Dopiero w pn to zmierzę :/

No to weekend'uj, a od poniedziałku ostro do roboty:-)

hm... ciekawe możliwe że masz jakiś kłopot na samej magistrali , układy, które opisałem działają bez zarzutu i nie mam z nimi kłopotów odpalają od strzała. Dobrze by było jakbyś podsłuchał analizatorem co się dzieje na:

SPI --- dojście do kontrolera MCP2515 z atmegi (choć wygląda że masz tu dobrze i init się wykonuje , ale może coś nie dochodzi)
RX/TX -- przed MCP2551 czy w ogóle cos idzie na transceiver
MAgistrala -- czyli na samej magistrali CAN


warto sprawdzić czy terminacja jest właściwa i poziomy napiec , magistralkę powinieneś prowadzić na jednej parze przewodów skrętki

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Pomiary zrobiłem dla układów zasilanych z programatora napięciem 5V.

W obu atmegach wykonała się tylko funkcja init:
Moduł 1
H 2.45V
L 2.45V
TX 4.8V
RX 4.8V

Moduł 2
H 2.5V
L 2.45V
TX 5V
RX 5V

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


W poście z dnia 14 mar 2015, o 21:39 umieściłem zdjęcia jak wyglądają moje układy. Wykorzystuje terminatory 120 Ohma i rezystory podciągające 2.7K Ohma. Biały przewód widoczny na zdjęciu to 6x0.5mm YTDY. Ma on jakieś 0.6m. Analizatora się jeszcze nie dorobiłem, próbuje sobie radzić inaczej. Po kilku dniach wraz z pomocą volt_1 udało się przejść init, wiec liczę że nadanie i odebranie pierwszej wiadomości też się uda

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?

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...

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ł.

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

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

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

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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?

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

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

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

_________________
http://www.jaglarz.info

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ąć.

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

właśnie nie widzę tu potwierdzenia.

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Przed wejściem do pętli głównej while(), ustawiam tryb normalny

Moduł, który nadaje zawiera w pętli tylko procedure wysłania, przy użyciu funkcji mcp2515_send_message:



Tak wygląda definicja funkcji mcp2515_send_message, która jest prosto z archiwum w poradniku Sun'a


W module odbiorczym sprawdzałem funkcje z poradnika mcp2515_get_message() oraz odbierz_can()
mcp2515_get_message() :


odbierz_can():


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

dla


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

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.

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

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ść:)