일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- can
- 토플
- GeorgiaTech
- 암호화폐
- AUTOSAR
- 백트레이더
- toefl writing
- 블록체인
- Bitcoin
- probability
- 백테스트
- 자동차sw
- 토플 라이팅
- 파이썬
- 비트코인
- 오토사
- backtrader
- 클라우드
- 아마존 웹 서비스
- 프로그래밍
- AWS
- 확률
- Cloud
- backtest
- python
- 자동매매
- 개발자
- it
- 퀀트
- TOEFL
- Today
- Total
Leo's Garage
Basic CAN vs Full CAN 본문
CAN 개발을 하다보면 Basic CAN과 Full CAN이라는 용어를 만나게 된다.
도대체 이 용어간의 차이는 무엇이며 유래가 무엇인지 궁금하다.
이 용어는 사실 CAN 개발의 초창기 시절에 유래된 것이다.
아주 오래전에 프로그래머에게 DPRAM 스타일의 interface를 제공하는 Intel 82526 CAN controller가 있었다.
Full CAN이라고 하며, 메시지 Buffer를 사용한다. 사용자에 따라서 크기와 개수를 지정할 수 있다. (Messge Object, Mail Box)
메시지의 종류에 따라 메시지 버퍼에 채워진다.
전용 버퍼 개념이기 때문에 각각 자신의 버퍼에 채우게 된다.
각각 Message Object, Mail box를 가지고 있기 때문에 수신된 메시지를 처리함에 있어서 HW에서 관리할 수 있다.
따라서 이 경우에는 많은 Msg를 높은 Baud Rate에서도 처리 가능하며 시스템과 버스 부하를 줄일 수 있다.
그 후에 필립스가 FIFO(Queue) 지향 프로그래밍 모델과 제한된 필터링 기능을 사용하는 82C200을 출시하였다.
이 방식은 Message Queue를 사용하며 FIFO 방식으로 수신되는 메시지의 종류에 관계없이 Queue에 채운다.
이 경우에는 메시지를 수신할 지 판단(Acceptance Filtering)하고 수신된 메시지를 처리하는건 MCU(SW)에 의해 수행된다.
따라서 CPU 부하가 늘어난다.
두 프로그래밍 모델을 구분하기 위해서 사람들은 Intel 방식을 Full CAN이라고 불렀고, 필립스 방식을 Basic CAN이라고 불렀다.
오늘날에 대부분은 CAN Controller는 두 가지 방식을 모두 허용하고 있다.
또한 이 두 방식의 컨트롤러는 서로 통신이 가능하며 호환성 문제는 없다.
다만, 용어 자체가 뭔가 직관적이지 않아서 와닿지는 않지만, 결국 CAN을 구현하는 방식의 차이일 뿐 프로토콜 자체에는 전혀 차이가 없다고 보는게 맞을 것 같다.
'자동차 및 자동차 SW > 자동차 SW 개발 일반' 카테고리의 다른 글
CAN Message Addressing and Identification (0) | 2023.06.25 |
---|---|
CAN Bus Arbitration 그리고 메시지 우선순위 (0) | 2023.06.25 |
Standard vs Extended CAN (0) | 2023.06.25 |
CAN 통신 Frame 종류와 구조 (0) | 2023.06.25 |
FMI(Functional Mock-up Interface), FMU(Functional Mock-up Unit) (0) | 2023.06.21 |