소프트웨어 공장

1. CiA 301 규격 기반 CANOpen 상위 계층 프로토콜 도입 배경 및 개요임베디드 시스템 및 산업용 제어 네트워크에서 CAN(Controller Area Network) 프로토콜은 데이터 링크 계층(Data Link Layer) 및 물리 계층(Physical Layer) 규격만을 정의합니다. 기본 CAN 프레임만으로는 노드 간의 데이터 의미 구조화, 네트워크 상태 통제, 정교한 설정 파라미터 동기화를 수행하는 데 한계가 있습니다.이러한 제약을 극복하기 위해 CAN i Automation(CiA) 단체는 CAN 레이어를 기반으로 한 상위 응용 계층(Application Layer) 규격인 CANOpen(CiA 301)을 정의했습니다. CANOpen은 객체 사전(Object Dictionary, O..

1. ISO 11898 기반 CAN 버스 통신 프로토콜 도입 배경 및 개요현대 임베디드 시스템 및 차량용 마이크로컨트롤러 환경에서는 다수의 ECU(Electronic Control Unit) 간의 실시간 데이터 교환이 필수적입니다. 기존의 점대점(Point-to-Point) 배선 방식은 차량 내 하네스(Harness)의 무게와 복잡도를 대폭 증가시켜 생산 비용 상승 및 신뢰성 저하 문제를 유발합니다.Bosch가 개발하고 ISO 11898로 표준화된 CAN(Controller Area Network) 프로토콜은 이러한 하네스 복잡도를 해결하기 위해 등장한 2선식(Twisted Pair) 멀티마스터 직렬 통신 규격입니다. 각 노드는 물리적 주소가 아닌 11비트(Standard) 또는 29비트(Extended..

1. ISO 11898 기반 CAN 버스 통신 프로토콜 도입 배경 및 개요현대 임베디드 시스템 및 차량용 마이크로컨트롤러 환경에서는 다수의 ECU(Electronic Control Unit) 간의 실시간 데이터 교환이 필수적입니다. 기존의 점대점(Point-to-Point) 배선 방식은 차량 내 하네스(Harness)의 무게와 복잡도를 대폭 증가시켜 생산 비용 상승 및 신뢰성 저하 문제를 유발합니다.Bosch가 개발하고 ISO 11898로 표준화된 CAN(Controller Area Network) 프로토콜은 이러한 하네스 복잡도를 해결하기 위해 등장한 2선식(Twisted Pair) 멀티마스터 직렬 통신 규격입니다. 각 노드는 물리적 주소가 아닌 11비트(Standard) 또는 29비트(Extended..

1. Linux Kernel SocketCAN 드라이버 및 iproute2 기반 인터페이스 설정 배경 (작성 배경 및 취지)Embedded Linux 환경에서 CAN(Controller Area Network) 버스 통신을 구현할 때, 전용 서드파티 라이브러리 대신 Linux 커널 내장 드라이버인 SocketCAN을 사용하는 것이 표준 방식입니다. SocketCAN은 CAN 인터페이스를 이더넷(Ethernet)과 동일한 네트워크 장치(Network Device)로 추상화하여 socket(PF_CAN, SOCK_RAW, CAN_RAW) 표준 POSIX 소켓 API를 통해 데이터 프레임을 제어할 수 있도록 지원합니다. 본 가이드에서는 iproute2 CLI 명령어(ip link)를 활용한 CAN Bitrat..

1. STM32 및 SocketCAN 기반 차량 CAN 버스 리버스 엔지니어링 배경 (작성 배경 및 취지)차량 제어 네트워크 및 산업용 자동화 시스템 분야에서 CAN(Controller Area Network) 버스 프레임 분석은 독자적인 커스텀 프로토콜을 파악하는 핵심 프로세스입니다. 자동차 제조사는 CAN 프레임의 DBC(Data Base CAN) 정의서를 외부에 공개하지 않는 경우가 많으므로, 특정 ECU 간의 통신 사양이나 차량 상태 데이터를 해석하기 위해서는 리버스 엔지니어링이 필수적입니다.본 포스팅에서는 SocketCAN 및 candump 툴을 활용한 CAN 버스 스니핑 기법, Unknown CAN ID 데이터 페이로드 역설계 패턴, 그리고 STM32F4 마이크로컨트롤러(HAL 드라이버) 환경..

1. STM32 bxCAN/FDCAN 디버깅 및 분석 도구 개요 (작성 배경 및 취지)자동차 및 산업용 현장에서 STM32 마이크로컨트롤러(MCU) 기반 CAN(Controller Area Network) 통신을 구현할 때 데이터 송수신 실패, Bus-Off 상태 전환, 프레임 유실 등의 문제가 자주 발생합니다. STM32의 bxCAN(Basic Extended CAN) 및 FDCAN 외장 트랜시버 회로 구성 문제, Baud Rate mismatch, 종단 저항 미설치 등은 물리 계층과 프로토콜 계층 전반에 걸쳐 예외를 유발합니다.이 가이드는 STM32 개발 환경(STM32CubeIDE, HAL Library)에서 발생할 수 있는 CAN 통신 오류를 신속하게 추적하기 위해 작성되었습니다. PCAN-Vie..

1. STM32 bxCAN 컨트롤러 및 SN65HVD230 기반 다중 노드 통신 구축 배경 (작성 배경 및 취지)임베디드 시스템 및 차량용 네트워크에서 CAN(Controller Area Network) 통신은 노이즈 차단력과 비동기식 멀티마스터(Multi-Master) 제어 특성 덕분에 핵심 프로토콜로 사용됩니다. ESP32의 TWAI 드라이버 환경에서 STM32 마이크로컨트롤러 환경으로 전환하는 과정에서, STM32의 bxCAN(Basic Extended CAN) 페리페럴 제어 방식과 ST HAL 라이브러리의 구조적 차이로 인해 통신 불능 상태가 빈번하게 발생합니다.본 포스팅에서는 STM32F4/F1 시리즈의 bxCAN IP를 활용하여 다중 노드 CAN 버스 네트워크를 하드웨어 레벨에서 구축하고, S..

1. STM32 bxCAN 컨트롤러 및 CAN Bus 드라이버 구현 배경 (작성 배경 및 취지)임베디드 시스템 및 임베디드 안드로이드 기기 개발 시 STM32 MCU와 외부 장치 간 신뢰성 높은 커뮤니케이션을 위해 CAN(Controller Area Network) 프로토콜이 광범위하게 사용됩니다. STM32의 bxCAN(Basic Extended CAN) 페리페럴은 멀티 마스터(Multi-Master) 차동 신호 방식을 지원하여 노이즈 내성이 뛰어나지만, HAL 라이브러리를 활용한 드라이버 초기화 및 필터 설정 과정에서 미세한 설정 오류로 인해 통신 데이터 수신 실패나 Bus-Off 상태 진입 문제가 빈번하게 발생합니다.본 글에서는 ESP32 TWAI 드라이버 기반 코드의 한계를 극복하고, STM32 ..

1. STM32 bxCAN 통신 하드웨어 제어 및 HAL 드라이버 구현 배경STM32 마이크로컨트롤러 시리즈의 bxCAN(Basic Extended CAN) 페리페럴은 임베디드 시스템, 차량용 제어기 및 산업용 제어망에서 신뢰성 높은 CAN 2.0A/B 통신 환경을 제공합니다. 그러나 ESP32의 TWAI 드라이버와 달리 STM32 bxCAN 하드웨어는 Power-On Reset 시 모든 수신 필터 은행(Filter Bank)이 비활성화(Disabled) 상태로 진입하므로, 올바른 필터 설정 없이 데이터 수신이 불가능합니다.또한 APB1 버스 클록을 기반으로 한 Bit Timing 설정 미흡은 Sample Point 오차를 유발하여 비트 동기화 실패 및 TEC(Transmit Error Counter) ..

1. STM32 bxCAN 드라이버 및 임베디드 CAN 소프트웨어 스택 설계 배경임베디드 시스템 및 전장 시스템 개발에서 CAN(Controller Area Network) 통신은 신뢰성 높은 차량용 및 산업용 데이터 전송을 위한 표준 프로토콜입니다. CAN 드라이버는 Microcontroller Unit(MCU)의 CAN 컨트롤러 하드웨어와 상위 레이어 애플리케이션 간 인터페이스를 제공하는 최하위 저수준(Low-Level) 소프트웨어 계층입니다.실무 개발 환경에서 CAN 드라이버를 올바르게 구현하지 않으면 메시지 유실, 버스 오프(Bus-Off) 상태에 따른 시스템 정지, 인터럽트 교착 상태(Deadlock) 등 치명적인 결함이 발생할 수 있습니다. 본 문서에서는 ESP32 및 Zephyr 환경을 제외..