딱 바뀐 값만 보여준다고. 리버싱 용
[링크 : https://manpages.debian.org/testing/can-utils/cansniffer.1.en.html]
[링크 : https://makersweb.net/linux/23696] socketCAN / linux
| can / 상위 프로토콜(?) (0) | 2026.09.14 |
|---|---|
| MCP2515와 CAN2.0B (0) | 2026.09.14 |
| can.. 개조? (0) | 2026.08.31 |
| can 트랜시버 - SN65HVD230 (0) | 2026.08.20 |
| MCP2515 on rpi .. 2번째 (0) | 2026.07.24 |
SAE J1939는 대형차량, OBD-2 는 JAE J1979로 경량 차량용
완전히 연관이 있는것도 아니고 없는것도 아니고 애매한 느낌
[링크 : https://en.wikipedia.org/wiki/SAE_J1939] 차량 구성 요소 간 통신 및 진단 프로토콜
GPS는 NMEA 0183 로 시리얼 포트.
[링크 : https://en.wikipedia.org/wiki/NMEA_2000] NMEA2K , 센서/디스플레이 등 해군용 프로토콜
[링크 : https://ko.wikipedia.org/wiki/CANopen] 자동화 임베디드 시스템에 사용하는 통신 프로토콜
[링크 : https://en.wikipedia.org/wiki/ISO_11783] isobus / 트랙터 농업용 기기를 위한 통신 프로토콜
| cansniffer (0) | 2026.09.16 |
|---|---|
| MCP2515와 CAN2.0B (0) | 2026.09.14 |
| can.. 개조? (0) | 2026.08.31 |
| can 트랜시버 - SN65HVD230 (0) | 2026.08.20 |
| MCP2515 on rpi .. 2번째 (0) | 2026.07.24 |
CAN2.0B 라는게 보여서 그럼 CAN1.0 이나 CAN2.0A도 있나 하고 찾아보는 중
| • Implements CAN V2.0B at 1 Mb/s: - 0 to 8-byte length in the data field - Standard and extended data and remote frames standard - 11bit  extended - 29bit   |
스펙까지 볼 여유가 안되니(!) 일단 요약된걸 맞다는 가정하에
AMP가 can이 통신이 깨지지 않고 통신한다라는 핵심 기능이고
id에 대해서 0이 우성 1이 열성이라 자기가 쏜걸 읽어서 값이 바뀌었나 보고
낮은 번호가 우성 id를 가지기에 더 우선권을 가지고, 높은 번호가 통신을 id 만 보고 포기하게 만드는 구조.
| 11비트: 차량 내부 제어 네트워크(파워트레인, 섀시), CANopen, OBD-II 요청(0x7DF) 29비트: SAE J1939(상용차), NMEA 2000(선박), ISO 11783(농기계). ID 안에 PGN, 우선순위, 소스 주소를 필드로 나눠 넣는 구조라 29비트가 필요합니다 AMP가 하는 일 이더넷의 CSMA/CD는 충돌이 나면 양쪽 다 전송을 포기하고 랜덤한 시간만큼 기다렸다가 재시도합니다. 보내던 프레임은 버려지고, 언제 성공할지 예측할 수 없습니다. AMP는 다릅니다. 충돌이 나도 우선순위가 높은 프레임 하나는 중단 없이 계속 전송됩니다. 진 쪽만 조용히 물러나므로 버스 시간이 전혀 낭비되지 않습니다. 이걸 비파괴적 비트 단위 중재(non-destructive bitwise arbitration)라고 부릅니다. 작동 원리는 두 가지 성질에 기대고 있습니다. 버스가 wired-AND로 동작한다. 우성(0)이 열성(1)을 항상 덮어씁니다. 한 노드라도 0을 내보내면 버스 전체가 0이 됩니다. 모든 노드가 자기가 쓴 비트를 되읽는다. 중재 필드(식별자 + RTR)를 MSB부터 한 비트씩 내보내면서 매 비트마다 비교합니다. 진 노드들은 프레임을 버리지 않고 송신 버퍼에 그대로 들고 있다가, 버스가 다시 유휴 상태가 되면 자동으로 재시도합니다. AMP가 만들어내는 결과 결정론적 지연이 보장됩니다. 우선순위가 가장 높은 메시지는 최악의 경우에도 "현재 전송 중인 프레임이 끝날 때까지"만 기다리면 됩니다. 실시간 제어에서 CAN이 오래 살아남은 이유입니다. 비트레이트와 버스 길이가 묶입니다. 중재가 성립하려면 한 비트 시간 안에 신호가 버스 끝까지 갔다가 돌아와 모든 노드가 같은 값을 봐야 합니다. 그래서 1Mbps면 약 40m, 125kbps면 500m 식으로 속도를 낮춰야 거리가 늘어납니다. 비트 타이밍에서 샘플 포인트를 비트 후반(보통 75~87.5%)에 두는 것도 이 때문입니다. 같은 ID를 두 노드가 쓰면 안 됩니다. ID가 동일하면 중재가 승자를 가리지 못하고 둘 다 끝까지 송신하는데, 데이터 내용이 다르면 그 지점에서 비트 에러가 터집니다. ID는 시스템 전체에서 유일해야 합니다. 우선순위 기아(starvation)가 생길 수 있습니다. 버스 부하가 높으면 낮은 우선순위 메시지가 계속 밀립니다. 그래서 실제 설계에서는 ID를 아무렇게나 배정하지 않고, 주기와 마감시간을 고려한 응답시간 분석(worst-case response time analysis)을 거쳐 우선순위를 정합니다. 참고로 CAN FD도 중재 구간만큼은 AMP를 그대로 씁니다. 고속 전환은 중재가 끝난 뒤 데이터 필드에서만 일어나기 때문에, 이 원리는 최신 CAN에서도 유효합니다. |
[링크 : https://claude.ai/share/c17e28ff-b3f8-4953-918e-407f2c6987f3]
| cansniffer (0) | 2026.09.16 |
|---|---|
| can / 상위 프로토콜(?) (0) | 2026.09.14 |
| can.. 개조? (0) | 2026.08.31 |
| can 트랜시버 - SN65HVD230 (0) | 2026.08.20 |
| MCP2515 on rpi .. 2번째 (0) | 2026.07.24 |
이건 CAN 트랜시버, 3번이 Vcc 이고
[링크 : https://www.nxp.com/docs/en/data-sheet/TJA1050.pdf]
SPI - CAN 컨트롤러 18번이 Vdd 전원 입력 핀이다.
| can / 상위 프로토콜(?) (0) | 2026.09.14 |
|---|---|
| MCP2515와 CAN2.0B (0) | 2026.09.14 |
| can 트랜시버 - SN65HVD230 (0) | 2026.08.20 |
| MCP2515 on rpi .. 2번째 (0) | 2026.07.24 |
| obd can (0) | 2026.07.23 |
+
2026.08.21
트랜시버 칩이지, mcp2515를 대체할 녀석은 아닌듯
|
[링크 : https://www.waveshare.com/wiki/2-CH_CAN_HAT]
---
mcp2515는 투칩이었는데, 얘는 원칩 으로 구성된 녀석인가..?
그리고 3.3V 라서 아두이노 보다는 라즈베리 쪽에 통합하기 유리할 듯.
[링크 : https://www.ti.com/product/ko-kr/SN65HVD230]
최대는 6V 까지 되나보다.
권장은 3~3.6V. typical은 3.3V 일 듯.
[링크 : https://itempage3.auction.co.kr/DetailView.aspx?itemno=C297096709] 750원
| MCP2515와 CAN2.0B (0) | 2026.09.14 |
|---|---|
| can.. 개조? (0) | 2026.08.31 |
| MCP2515 on rpi .. 2번째 (0) | 2026.07.24 |
| obd can (0) | 2026.07.23 |
| DeviceNet CAN (0) | 2025.04.01 |
벌써 3년전에 가볍게(?) 해봤었네..
또 까먹다니 이 기억력 어쩔.. ㅠㅠ
그때와 다른건.. 작년 부터 /boot/config.txt의 경로가 달라졌다는 정도?
| $ uname -a Linux raspberrypi 6.12.25+rpt-rpi-v7 #1 SMP Raspbian 1:6.12.25-1+rpt1 (2025-04-30) armv7l GNU/Linux $ cat /boot/config.txt DO NOT EDIT THIS FILE The file you are looking for has moved to /boot/firmware/config.txt $ cat /boot/firmware/config.txt [all] dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=12 dtoverlay=spi-bcm2835-overlay $ sudo ip link set can0 up type can bitrate 125000 $ ifconfig can0 can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 $ dmesg | grep -i can [ 12.948060] CAN device driver interface [ 13.070005] mcp251x spi0.0 can0: MCP2515 successfully initialized. $ lsmod |grep can can_dev 40960 1 mcp251x |
loopback 설정. ifconfig 상으로는 별다른 티가 안난다
| $ sudo ip link set can0 up type can bitrate 125000 loopback on $ sudo ifconfig can0 can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 |
[링크 : https://forums.raspberrypi.com/viewtopic.php?t=7027&start=225]
아무튼 loopback을 활성화 하고 ssh 로 창 두개 열어서 한쪽은 candump 실행해두고
다른 한쪽에서 cansend로 보내면 보내진다.
| $ cansend can0 5A1#11.2233.44556677.88 |
| $ candump can0 can0 5A1 [8] 11 22 33 44 55 66 77 88 can0 5A1 [8] 11 22 33 44 55 66 77 88 |
| $ demsg | tail [ 965.109222] can: controller area network core [ 965.109370] NET: Registered PF_CAN protocol family [ 965.136117] can: raw protocol [ 1028.671698] mcp251x spi0.0 can0: bus-off |
[링크 : https://whiteknight3672.tistory.com/346]
[링크 : https://blog.naver.com/mts90/221644429413]
[링크 : https://wp.mytv.kr/2019/10/31/raspberry-pi-에서-can-통신-사용하기/] 결선도
2023.10.31 - [모종의 음모/CAN] - MCP2515 on rpi
2025.02.19 - [모종의 음모/CAN] - candump, cansend와 vcan
+
MCP2515 / TJA1050
D0695323C 라고 써있어서
이게 8 MHz 인지 16 MHz 인질 모르겠다. 검색해도 안나온다.
일단 두대를 보니 서로 다른게 써있어서 그냥 시리얼 번호라고 생각하는 중.
일단은 3.3V했는데 이러면 외부로 신호는 발생시키지 못할 듯.
예전에도 본건 데 전원이 잘못되었다고 개조를 해야 한다고 하는데
지금 다시 읽어보니 라즈베리 파이 gpio 가 3.3V 라서 아두이노와는 다르게 5V로 주면 라즈베리가 데미지 입게된다.
| Because MCP2515 must be powered from 3,3V, because MCP2515 is directly connected to Pi GPIO and GPIO only accept 3,3V |
[링크 : https://forums.raspberrypi.com/viewtopic.php?t=141052]
데이터 시트를 찾아보면
MCP2515는 2.7 V~5.5 V 면 되지만 SPI 도 Vdd 전압 따라가게 되면 흐음..
CAN tranceiver칩은 4.75~5.25V 사이에 전압을 공급해야 한다.
[링크 : https://www.nxp.com/docs/en/data-sheet/TJA1050.pdf]
걍 속편하게 SPI 쪽만 레벨 시프터 쓸까? 개조가 나을까..
| can.. 개조? (0) | 2026.08.31 |
|---|---|
| can 트랜시버 - SN65HVD230 (0) | 2026.08.20 |
| obd can (0) | 2026.07.23 |
| DeviceNet CAN (0) | 2025.04.01 |
| candump, cansend와 vcan (0) | 2025.02.19 |
can 찾아보게 된 이유가 OBD 통신에 쓴다고 해서 봤던거니 다시 기록!
[링크 : https://clemencyking.tistory.com/m/26]
7.29
https://www.instructables.com/Raspberry-Pi-Based-CAN-BUS-Reader/
| can 트랜시버 - SN65HVD230 (0) | 2026.08.20 |
|---|---|
| MCP2515 on rpi .. 2번째 (0) | 2026.07.24 |
| DeviceNet CAN (0) | 2025.04.01 |
| candump, cansend와 vcan (0) | 2025.02.19 |
| linux can 테스트(가상 CAN IF) (0) | 2025.02.18 |
이거 머 보다가 나온거지 -ㅁ-?
FC-SAN 쪽에서 CIP로 시작한 것 같은데 기억이...
| The Common Industrial Protocol (CIP) is an industrial protocol for industrial automation applications. It is supported by ODVA. Previously known as Control and Information Protocol,[1] CIP encompasses a comprehensive suite of messages and services for the collection of manufacturing automation applications – control, safety, synchronization, motion, configuration and information. It allows users to integrate these manufacturing applications with enterprise-level Ethernet networks and the Internet. It is supported by hundreds of vendors around the world,[2] and is media-independent. CIP provides a unified communication architecture throughout the manufacturing enterprise. It is used in EtherNet/IP, DeviceNet, CompoNet and ControlNet. ODVA is the organization that supports network technologies built on the Common Industrial Protocol (CIP). These also currently include application extensions to CIP: CIP Safety, CIP Motion and CIP Sync. |
[링크 : https://en.m.wikipedia.org/wiki/Common_Industrial_Protocol]
| DeviceNet is a network protocol used in the automation industry to interconnect control devices for data exchange. It utilizes the Common Industrial Protocol over a Controller Area Network media layer and defines an application layer to cover a range of device profiles. Typical applications include information exchange, safety devices, and large I/O control networks.[1] |
| MCP2515 on rpi .. 2번째 (0) | 2026.07.24 |
|---|---|
| obd can (0) | 2026.07.23 |
| candump, cansend와 vcan (0) | 2025.02.19 |
| linux can 테스트(가상 CAN IF) (0) | 2025.02.18 |
| can-utils(cansend, candump) (0) | 2025.02.18 |
| $ modprobe vcan modprobe: ERROR: could not insert 'vcan': Operation not permitted $ sudo modprobe vcan $ sudo ip link add dev vcan0 type vcan $ ifconfig br-638c83b169eb: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255 ether 02:42:d5:e6:f1:21 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:40:63:97:cb txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 enxf8e43b9b776b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.220.108 netmask 255.255.0.0 broadcast 192.168.255.255 inet6 fe80::81f4:65ad:f7cc:2f2c prefixlen 64 scopeid 0x20<link> ether f8:e4:3b:9b:77:6b txqueuelen 1000 (Ethernet) RX packets 3619726 bytes 2156366501 (2.1 GB) RX errors 0 dropped 106170 overruns 0 frame 0 TX packets 1452518 bytes 317915291 (317.9 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 160829 bytes 14028478 (14.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 160829 bytes 14028478 (14.0 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.220.107 netmask 255.255.0.0 broadcast 192.168.255.255 inet6 fe80::104b:d69c:878f:cfaa prefixlen 64 scopeid 0x20<link> ether 8c:55:4a:28:25:bc txqueuelen 1000 (Ethernet) RX packets 809871 bytes 90255020 (90.2 MB) RX errors 0 dropped 99865 overruns 0 frame 0 TX packets 53067 bytes 6125665 (6.1 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 $ ifconfig -a br-638c83b169eb: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255 ether 02:42:d5:e6:f1:21 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:40:63:97:cb txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 enxf8e43b9b776b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.220.108 netmask 255.255.0.0 broadcast 192.168.255.255 inet6 fe80::81f4:65ad:f7cc:2f2c prefixlen 64 scopeid 0x20<link> ether f8:e4:3b:9b:77:6b txqueuelen 1000 (Ethernet) RX packets 3620125 bytes 2156544266 (2.1 GB) RX errors 0 dropped 106183 overruns 0 frame 0 TX packets 1452676 bytes 317938700 (317.9 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 160841 bytes 14030154 (14.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 160841 bytes 14030154 (14.0 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vcan0: flags=128<NOARP> mtu 72 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.220.107 netmask 255.255.0.0 broadcast 192.168.255.255 inet6 fe80::104b:d69c:878f:cfaa prefixlen 64 scopeid 0x20<link> ether 8c:55:4a:28:25:bc txqueuelen 1000 (Ethernet) RX packets 809990 bytes 90270371 (90.2 MB) RX errors 0 dropped 99877 overruns 0 frame 0 TX packets 53074 bytes 6126348 (6.1 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 $ sudo ifconfig vcan0 up $ ifconfig br-638c83b169eb: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255 ether 02:42:d5:e6:f1:21 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:40:63:97:cb txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 enxf8e43b9b776b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.220.108 netmask 255.255.0.0 broadcast 192.168.255.255 inet6 fe80::81f4:65ad:f7cc:2f2c prefixlen 64 scopeid 0x20<link> ether f8:e4:3b:9b:77:6b txqueuelen 1000 (Ethernet) RX packets 3620430 bytes 2156573250 (2.1 GB) RX errors 0 dropped 106197 overruns 0 frame 0 TX packets 1452764 bytes 317953427 (317.9 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 160841 bytes 14030154 (14.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 160841 bytes 14030154 (14.0 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vcan0: flags=193<UP,RUNNING,NOARP> mtu 72 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.220.107 netmask 255.255.0.0 broadcast 192.168.255.255 inet6 fe80::104b:d69c:878f:cfaa prefixlen 64 scopeid 0x20<link> ether 8c:55:4a:28:25:bc txqueuelen 1000 (Ethernet) RX packets 810099 bytes 90278671 (90.2 MB) RX errors 0 dropped 99889 overruns 0 frame 0 TX packets 53074 bytes 6126348 (6.1 MB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 |
[링크 : https://ola-page.tistory.com/66]
| $ candump candump - dump CAN bus traffic. Usage: candump [options] <CAN interface>+ (use CTRL-C to terminate candump) Options: -t <type> (timestamp: (a)bsolute/(d)elta/(z)ero/(A)bsolute w date) -H (read hardware timestamps instead of system timestamps) -c (increment color mode level) -i (binary output - may exceed 80 chars/line) -a (enable additional ASCII output) -S (swap byte order in printed CAN data[] - marked with '`' ) -s <level> (silent mode - 0: off (default) 1: animation 2: silent) -l (log CAN-frames into file. Sets '-s 2' by default) -L (use log file format on stdout) -n <count> (terminate after reception of <count> CAN frames) -r <size> (set socket receive buffer to <size>) -D (Don't exit if a "detected" can device goes down. -d (monitor dropped CAN frames) -e (dump CAN error frames in human-readable format) -x (print extra message infos, rx/tx brs esi) -T <msecs> (terminate after <msecs> without any reception) Up to 16 CAN interfaces with optional filter sets can be specified on the commandline in the form: <ifname>[,filter]* Filters: Comma separated filters can be specified for each given CAN interface: <can_id>:<can_mask> (matches when <received_can_id> & mask == can_id & mask) <can_id>~<can_mask> (matches when <received_can_id> & mask != can_id & mask) #<error_mask> (set error frame filter, see include/linux/can/error.h) [j|J] (join the given CAN filters - logical AND semantic) CAN IDs, masks and data content are given and expected in hexadecimal values. When the can_id is 8 digits long the CAN_EFF_FLAG is set for 29 bit EFF format. Without any given filter all data frames are received ('0:0' default filter). Use interface name 'any' to receive from all CAN interfaces. Examples: candump -c -c -ta can0,123:7FF,400:700,#000000FF can2,400~7F0 can3 can8 candump -l any,0~0,#FFFFFFFF (log only error frames but no(!) data frames) candump -l any,0:0,#FFFFFFFF (log error frames and also all data frames) candump vcan2,12345678:DFFFFFFF (match only for extended CAN ID 12345678) candump vcan2,123:7FF (matches CAN ID 123 - including EFF and RTR frames) candump vcan2,123:C00007FF (matches CAN ID 123 - only SFF and non-RTR frames) |
| $ cansend vcan0 cansend - send CAN-frames via CAN_RAW sockets. Usage: cansend <device> <can_frame>. <can_frame>: <can_id>#{data} for 'classic' CAN 2.0 data frames <can_id>#R{len} for 'classic' CAN 2.0 data frames <can_id>##<flags>{data} for CAN FD frames <can_id>: 3 (SFF) or 8 (EFF) hex chars {data}: 0..8 (0..64 CAN FD) ASCII hex-values (optionally separated by '.') {len}: an optional 0..8 value as RTR frames can contain a valid dlc field <flags>: a single ASCII Hex value (0 .. F) which defines canfd_frame.flags Examples: 5A1#11.2233.44556677.88 / 123#DEADBEEF / 5AA# / 123##1 / 213##311223344 / 1F334455#1122334455667788 / 123#R / 00000123#R3 |
아래는 데이터 출력 포맷 확인용
인터페이스 / CAN id / 길이 / 데이터(페이로드 길이)
| receive | send |
| $ candump vcan0 vcan0 111 [5] 01 02 03 04 05 |
$ cansend vcan0 111#010203.04.05 |
| vcan0 112 [5] 01 02 03 04 05 | $ cansend vcan0 112#010203.04.05 |
| vcan0 112 [0] | $ cansend vcan0 112# |
| vcan0 112 [00] | $ cansend vcan0 112##1 |
| vcan0 112 [01] 23 | $ cansend vcan0 112##123 |
| vcan0 112 [0] remote request | $ cansend vcan0 112#R |
| vcan0 112 [3] remote request | $ cansend vcan0 112#R3 |
받는 쪽에서 CAN id 제한할 경우, 112를 받도록 설정했기에 113은 무시된다.
| $ candump vcan0,112:FF | $ cansend vcan0 111#R3 |
| vcan0 112 [3] remote request | $ cansend vcan0 112#R3 |
| $ cansend vcan0 113#R3 | |
| vcan0 112 [5] 01 02 03 04 05 | $ cansend vcan0 112#010203.04.05 |
| vcan0 112 [6] 01 02 03 04 05 06 | $ cansend vcan0 112#010203.04.0506 |
| vcan0 112 [7] 01 02 03 04 05 06 07 | $ cansend vcan0 112#010203.04.0506.07 |
| vcan0 112 [0] remote request | $ cansend vcan0 112#R $ cansend vcan0 112#R10 $ cansend vcan0 112#R100 |
| vcan0 112 [1] remote request | $ cansend vcan0 112#R1 |
| vcan0 112 [2] remote request | $ cansend vcan0 112#R2 |
| vcan0 112 [8] remote request | $ cansend vcan0 112#R8 |
그나저나 mask 라는데 이해가 안되네..
123 = 0x7B & 0x7F0 하면 0x7B가 되어야 하니 16개에 대해서 받아들여야 할 거 같은데 왜 119에서 130 까지 12개 받아들여 질까?
| $ candump vcan0,123:7F0 vcan0 120 [0] remote request vcan0 121 [0] remote request vcan0 122 [0] remote request vcan0 123 [0] remote request vcan0 124 [0] remote request vcan0 125 [0] remote request vcan0 126 [0] remote request vcan0 127 [0] remote request vcan0 128 [0] remote request vcan0 129 [0] remote request |
$ cansend vcan0 119#R $ cansend vcan0 120#R $ cansend vcan0 121#R $ cansend vcan0 122#R $ cansend vcan0 123#R $ cansend vcan0 124#R $ cansend vcan0 125#R $ cansend vcan0 126#R $ cansend vcan0 127#R $ cansend vcan0 128#R $ cansend vcan0 129#R $ cansend vcan0 130#R |
| obd can (0) | 2026.07.23 |
|---|---|
| DeviceNet CAN (0) | 2025.04.01 |
| linux can 테스트(가상 CAN IF) (0) | 2025.02.18 |
| can-utils(cansend, candump) (0) | 2025.02.18 |
| can invader (0) | 2024.01.09 |
실 장비가 있으면 좋겠지만 없어도
가상 can(virtual can) 장치를 추가해서 테스트 할 수 있다.
| $ sudo ip link add dev vcan0 type vcan $ sudo ifconfig vcan0 up |
[링크 : https://ola-page.tistory.com/66] socket can
[링크 : https://hn-log.tistory.com/168] CANable
| DeviceNet CAN (0) | 2025.04.01 |
|---|---|
| candump, cansend와 vcan (0) | 2025.02.19 |
| can-utils(cansend, candump) (0) | 2025.02.18 |
| can invader (0) | 2024.01.09 |
| CAN(controller area network) (0) | 2023.10.31 |
|
