르네사스 타겟 보드를 이용한 CAN통신(4)

4. CAN 모듈 시험

CAN 모듈을 시험하기 위해서 우리는 르네사스 사의 타겟 보드 2개를 준비하여 각각 다른 프로그램을 탑재하여 버스 구성을 하고 시험하였으며, PC와 통신 시험을 하기 위해 Seeed Studio 사의 USB-CAN 분석기를 USB 포트를 통해 PC에 연결하였다. 시험을 위한 CAN 버스의 구성은 그림 24와 같다.

그림 24. 시험 구성

4.1 CAN 분석기

CAN 분석기는 Seeed Atudio 사의 USB-CAN 분석기 V8.0을 사용하였으며 구동 소프트웨어의 GUI는 그림 25에 나타내었다.[5]
그림 25의 GUI에서 COM Configuration 창에서 COM port 설정 및 연결이 가능하며, CAN Configuration 창에서 CAN 모드, 통신 속도등을 설정할 수 있다. 그리고, 메시지를 편집하여 메시지를 전송할 수 있으며 메시지 수신 창을 통해 수신되는 메시지를 모니터링 할 수 있다.
CAN 버스의 종단 저항 120Ω의 저항도 연결되어 있어서 단말 들을 버스에 연결하면 별도의 종단 저항 없이 데이터를 송 수신 할 수 있다.

그림 25. USB-CAN Analyzer 구동 소프트웨어

4.2 CANtest1
CANtest1은 MCU의 RTC(Real Time Clock) 기능을 활성화하고, 0.5초 간격으로 인터럽트가 발생하게 하여 현재 시각을 메시지로 CAN 버스를 통해 전달하게 하고, CAN 버스로부터 Remote 메세지를 수신하면 다시 그때의 현재 시각을 전송하게 하고, CAN 버스로부터 Data 메시지를 수신하면 RTC의 시간을 설정하는 함수를 구동하여 RTC 시간을 설정하도록 하였다.

4.2.1 RTC 설정
RTC 설정은 CS+의 Code Generator의 Real-time Clock을 클릭하여 그림 26과 같이 설정한다. 인터럽트는 0.5초 간격으로 발생하게 설정하고, 우선순위는 Low로 설정한다.
Code Generator에서 “Generate Code” 버튼을 클릭하면 r_cg_rtc.c와 r_cg_rtc_user.c 파일이 활성화되는데, r_cg_user.c 파일을 열어 인터럽트 서비스 루틴에 서비스 처리 코드를 다음과 같이 추가한다. 그러면 RTC 모듈에서 0.5초마다 TX_rtc_value() 함수를 호출하게 된다.

그림 26. Code Generator의 RTC 설정



4.2.2 TX_rtc_value 함수
TX_rtc_value 함수는 다음과 같이 작성하여 추가한다.
TX_rtc_value 함수에서는 현재의 RTC 값을 읽어와서 년, 월, 일, 요일, 시각, 분, 초 값을 데이터에 입력한 뒤 4절에서 설명한 메시지 송신 함수를 호출한다.
호출할 때 ID는 0x123, 메시지 크기는 7로 호출한다.
시험을 해보면 CAN 분석기의 메시지 창에 그림 27과 같이 메시지가 수신됨을 확인 할 수 있다.
그림 27. CANtest1 시험 결과

4.2.3 RX_data_process 함수
RX_data_process를 다음과 같이 작성하여 추가한다.

위 코드를 살펴보면 2가지 메시지를 수신하여 처리하는데 그중 하나는 ID가 0x10인 Remote 프레임을 수신하여 현재의 시간을 다시 읽어서 그 값을 다시 전송하는 것으로 되어 있고, 나머지 하나는 ID가 0x15인 데이터 프레임을 수신하여 현재의 시간을 설정하는 함수로 되어 있다. 그림 28에는 시간 설정 시험 결과를 나타내었다. 그림 28을 보면 ID가 0x15인 메시지를 전달하기 전에서는 23시 24분 39초 였는데, 이후에는 23시 45분 0초 인 것을 확인할 수 있다. 여기서 23시는 RTC가 12시간 단위로 설정 되어 있을 때 오후 3시를 의미하는 BCD 코드 이다.

그림 28. 시간 설정 시험 결과

그림 29에는 Remote 프레임 시험 결과를 나타내었다. 그림 29를 보면 ID가 0x10인 Remote 프레임이 전달되면 단말에서 ID가 0x10인 Data 프레임으로 응답하는 것을 확인 할 수 있다.

그림 29. Remote Frame 시험 결과

이 2개의 메시지를 수신하기 위해서는 4장에서 설명한 수신 규칙 등록 함수에서 다음과 같이 설정하여야 한다.


4.3 CANtest2
CANtest2는 별도로 제작한 온습도계를 이용하여 온습도 센서에서 읽은 온도/습도를 지속적으로 CAN 버스에 전송하는데 온도와 습도의 상한값과 하한값을 설정하여 하한값 이하이면 상태가 1, 하한값과 상한값 사이이면 2, 상한값 이상이면 상태를 3으로 전송하고, Remote 프레임을 수신하면 현재의 상한값과 하한값을 전송하고, Data 프레임을 수신하면 상한값과 하한값을 변경하도록 구성하였다.

4.3.1 TX_sensor_value 함수
기제작된 온습도계 프로그램에서 LCD에 온습도 그래프를 그리는 함수에 TX_sensor_value 함수를 호출하도록 추가하고 TX_sensor_value 함수를 다음과 같이 추가한다.
TX_sensor_value 함수를 살펴보면 메시지의 일련번호를 메시지에 추가하기 위해 데이터에 tcnt 값을 입력하고, 온도와 습도, 또한 상태 값을 데이터에 입력하고 4장에서 설명한 메시지 전송 함수를 호출한다. 이때 메시지의 ID는 0x128이고 메시지 길이는 6인 것을 알 수 있다.


온습도 전송 시험 결과를 그림 30에 나타내었다. 결과를 보면 4.3절에서 설명한 시간 데이터 사이에 메시지 ID가 0x128인 메시지가 들어가 있으며 메시지 일련 번호는 0x004e, 온도는 0x1b(27°C), 온도 상태는 2, 습도는 0x42(66%), 습도의 상태는 2인 것을 알 수 있다.

그림 30. 온습도 데이터 전송 시험 결과

4.3.2 RX_data_process 함수
RX_data_process 함수를 다음과 같이 작성하여 추가한다.


위 코드를 살펴보면 2가지 메시지를 수신하여 처리하는데 그중 하나는 ID가 0x20인 Remote 프레임을 수신하여 온습도의 상한값과 하한값을 전송하는 것으로 되어 있고, 나머지 하나는 ID가 0x25인 데이터 프레임을 수신하여 온습도의 상한값과 하한값을 설정하는 함수로 되어 있다. 그림 31에는 Remote 프레임 수신시험을 수행한 결과를 나나내었다. 그림을 보면 중간에 메시지 ID가 0x20인 Remote 프레임을 수신하여 역시 ID가 0x20인 데이터 프레임으로 응답하는 것을 볼 수 있으며, 현재의 온도 상한값은 0x64(100°C), 하한값은 0x0a(10°C)로 설정되어 있고, 습도 상한값은 0x50)(80%), 하한값은 0x0a(10%)로 설정되어 있음을 볼 수 있다.

그림 31. Remote Frame 수신 시험

그림 32에는 온습도 상하한값 변경 시험 결과를 나타내었다. 그림의 중간에 메시지 ID가 0x25인 메시지가 전송되었음을 알 수 있는데 여기서 데이터를 보면 온도 상한값을 0x55(85°C), 하한값을 0x20(32°C)로 변경하라는 것이고, 습도의 상한값을 0x30)(48%), 하한값을 0x0a(10%)로 변경하라는 것이다.

그림 32. 상하한값 변경 시험

이 메시지가 전송된 후에 수신된 ID 0x128 메시지를 보면 온도와 습도는 그림 30에 나타낸 값과 같지만, 상태가 온도는 하한값 이하이기 때문에 0x01, 습도는 상한값 이상이기 때문에 상태가 0x03으로 변경되었음을 확인할 수 있다.

이 2개의 메시지를 수신하기 위해서는 4장에서 설명한 수신 규칙 등록 함수와 같이 설정하면 된다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

이미지
 FPGA 실습(5) 5. Manchester Code  맨체스터 코드는 앞절에서 설명한 SDLC의 NRZ 모드에서 별도의 클럭을 사용하지 않고 데이터에서 클럭을 추출하기 위해 사용하며, 멘체스터 코드의 코딩 방식은 다음 그림과 같다. 5.1. 송신부(Encoder) 송신부는 앞의 그림에서 살펴본 바와 같이 CLK과 NRZ를 XOR을 취해서 출력하면 된다. 그런데 CLK과 NRZ를 XOR을 취하면 서로의 위상차로 인해 glitch가 발생할 수 있으므로 전송 속도보다 아주 빠른 클럭으로 래치해서 출력하는 것이 좋다. 5.2. 수신부(Decoder) 수신부는 입력되는 맨체스터 코드로부터 데이터와 클럭을 추출하여 출력하여야 한다. 먼저 전송속도보다 아주 빠른 클럭을 이용하여 전송속도에 맞는 클럭을 생성하기 위한 카운터를 구동하여 기본적인 클럭을 생성한다. 예를 들어 전송 속도가 1Mbps인데 회로에서 사용하는 클럭이 128MHz 클럭이라고 한다면 카운터 값이 63이 된뒤 다시 0으로 돌아가도록 구성하여 카운 터값이 0일 때 반전이 일어나도록 하여 1MHz의 클럭을 생성한다. 그리고 입력되는 데이터를 전송속도 보다 아주 빠른 클럭(예: 128MHz)으로 래치를 해서 rising edge와 falling edge를 검출하고 rinsing edge나 falling edge에서 앞에서 언급한 카운터를 0으로 셋팅하여 주기를 맞춘다. 그리고 클럭 주기의 1/2되는 지점에서 sample 클럭을 생성하여 sample 클럭에서 입력되는 데이터를 래치하여 이전데이터와 비교한다. sample 데이터가 b’01이면 1로 디코딩하고 데이터가 b’10이면 0으로 디코딩하며 출력 클럭을 반전시킨다. 만일 데이터가 b’00이거나 b’11이면 디코딩하지 않으며 출력 클럭을 그대로 유지 한다. 이렇게 하면 입력되는 데이터로부터 데이터와 클럭을 추출하여 NRZ 데이터를 출력할 수 있다. 다음 그림은 Loopback되는 맨체스터코드로부터 NRZ 데이터와 출력 클럭을 시험 한 결과이다...
자세한 내용 보기
이미지
 FPGA 실습(4) 4. SDLC 구현 SDLC(Synchronous Data Link Control)를 구현하여 본다 SDLC를 구현하기 위해 SDLC의 프레임의 구조를 먼저 살펴보고 SDLC 프로토콜을 구현하기 위한 IP를 제작하는 과정과 통합하여 시험하는 과정을 기술한다. 4.1 SDLC 프로토콜 개요 4.1.1 SDLC 프레임 - Flag : b’0111110의 값으로 구성되면 프레임의 시작과 끝을 나타낸다. 데이터가 없는 구간은 All High로 구성되거나 b’01111111이 반복될 수 있다. - 규격 확인이 필요한 부분임. HW 구현 관점에서는 b’01111111이 반복되는 구조가 구현을 간단히 할 수 있다. 또한 Flag이외에 필드에 b’01111110 값이 들어가면 프레임 오류가 발생할 수 있기 때문에 송신측에서는 1이 5번 반복되면 ‘0’을 하나 삽입한다. 이를 bit stuffing이라고 하며, 수신측에서는 Flag이외의 필드에서 1이 5번 반복되는 것을 발견하면 뒤에 따라오는 ‘0’을 제거하고 데이터를 처리하여야 한다. - Address/Control 부분은 당초 SDLC 규격을 만들 때 각종 토폴로지와 통신 프로토콜을 정의하기 위해 삽입된 부분으로 생각되며 우리가 흔히 사용하는 Point-to-point의 토폴로지에서는 Source Address(1byte), Destination Address(1 byte), Message ID(1byte), Data Length(2 byte)등으로 흔히 구성되며, 이는 프로토콜 정의할 때 결정하면 된다. - Data : 데이터는 사용자가 전송하고자 하는 데이터를 바이트 크기단위로 전송하는 구간이다. 데이터의 크기는 control 필드에 송수신 프로토콜을 정의하는 부분에서 정의하여야 한다.(Link 계층의 SW에서 필요한 정보 임) - FCS : Foward Control Sequence는 전송된 프레임의 오류 여부를 판별하기 위한 것으로 흔히 CCITT CRC-16을 사용하는 것으로 표시한다...
자세한 내용 보기
이미지
 FPGA실습(2) 2. UART 구현 이전 글에 이어서 이번에는 UART를 구현하여 DMA를 통해 데이터를 전송하고 수신하는 부분에 대해 다룬다. 2.1 요구사항 - AXIS Stream FIFO와 연동되는 UART 구성 - UART 회로에 공급되는 클럭에 따라 BAUD Rate 결정 2.2 UART 개요 위키백과에 나오는 UART의 소개자료는 다음과 같다. UART(범용 비동기화 송수신기: Universal asynchronous receiver/transmitter)는 병렬 데이터의 형태를 직렬 방식으로 전환하여 데이터를 전송하는 컴퓨터 하드웨어의 일종이다. UART는 일반적으로 EIA RS-232, RS-422, RS-485와 같은 통신 표준과 함께 사용한다. UART의 U는 범용을 가리키는데 이는 자료 형태나 전송 속도를 직접 구성할 수 있고 실제 전기 신호 수준과 방식(이를테면 차분 신호)이 일반적으로 UART 바깥의 특정한 드라이버 회로를 통해 관리를 받는다는 뜻이다. 즉 동기 신호는 전달하지 않고 약정된 통신 속도로 8비트의 데이터를 직렬로 전송한다는 뜻이고 실제 PC 등과 통신을 수행하기 위해서는 선로 인터페이스 소자가 따로 있어야 한다. 여기서 설계한 것은 Zynq에서 선로 인터페이스 소자로 출력하는 송신신호, 선로 인터페이스 소자로부터 수신하는 수신 신호를 생성하거나 수신하여 데이터를 처리하는 과정을 설계하고 시험하는 것이다. UART의 코딩 규격은 다음과 같다. STOP 앞에 패리티 비트를 추가하기도 하는데 여기서는 패리티 비트를 사용하지 않는 UART를 사용한다. 2.3 AXI4 Stream Bus AXI4 Stream Bus의 프로토콜은 다음 그림과 같다. 즉 VALID 신호를 송신측에서 전달하면 수신 측에서 READY 신호를 출력하여 데이터를 수신하는 방식으로 데이터를 전달 받는다. 그리고 데이터의 마지막임을 알리는 TLAST 신호는 마지막 워드(32 bit의 데이터)일 때 HIGH가 되고 그 외에는 LOW를 유지한다. 또한 ...
자세한 내용 보기