Komunikacja CAN na Raspberry Pi z nakładką Waveshare RS485 - błędne ramki

Witam,

Chce nawiązać komunikacje CAN z nakładką nr RP Waveshare RS485 CAN HAT w pythonie.
wykonuje prosty przykład


i otrzymuje dziwne ramki, kilka i to z dziwnymi wartościami. Nic oprócz RP do magistrali nie jest podłączone. Bitrate dobrze ustawione na 100kHz


W przypadku testów z ST32 wszystko jest ok. Wiec oscyloskop chyba dobrze dekoduje.


Czy ktoś komunikował się magistralą CAN z Raspberry Pi i może pomóc?

Ja ciągle jestem w trakcie oczekiwania na moduł od chińczyka - koronawirus effect a CAN HAT wydawał mi się za drogi (5zł vs 50) jak na zabawę, więc jeszcze do RPi tego nie podłączyłem, jednak te oscylogramy u góry wyglądają jakoś dziwnie - włączyłeś terminację. Niestety nie opisałeś sygnałów. Swoją drogą CAN słucha to co nadaje, nie zgłąszał problemów?

Znalazłem przyczynę nieprawidłowych ramek. Błędnie skonfigurowany moduł w RP. Bazowałem na dokumentacji w PDF-ie i nie było tam wzmianki jak na stronie czyli:

There are two versions. The only difference betweem these version are the crystal. The old one use 8M and the line added to config.txt file should be:
dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25,spimaxfrequency=1000000
The new one use 12M crystal and the line should be
dtoverlay=mcp2515-can0,oscillator=12000000,interrupt=25,spimaxfrequency=2000000

oczywiście mam wersje 12MHz i trzeba było wpisać drugą wersje.

Teraz mam


tylko jeszcze muszę rozpoznać dlaczego tyle identycznych (kilkadziesiąt) ramek jedna komenda Send wypuszcza.
Może to standard wypuszczania kilku (dziesięciu) ramek przy CAN-nie?



Sygnały od góry: CAN_TXD na MPC2551 przy STMF32F103C8T6, CAN_RXD, CANH i CANL.
terminatory są.

No na to bym nie wpadł, że niewłaściwie skonfigurowałeś moduły
Nie używałem nigdy modułu pythona, używałem cansniffer, cansend itd z can-utils i nie było problemu, może to efekt braku potwierdzeń.