Belajar Firmware Engineer - Automotive & CAN

#Pendahuluan

Setelah di episode 22 firmware kita mengolah sinyal, pada episode ini kita masuk ke salah satu domain tertua dan paling ketat: otomotif. Sebuah mobil modern berisi puluhan ECU (Electronic Control Unit) — mesin, rem, transmisi, body — yang harus berkomunikasi dengan keandalan tinggi dan determinisme ketat. Tulang punggung komunikasi itu adalah CAN bus.

Mengapa topik ini penting? Karena otomotif adalah lapangan kerja besar bagi firmware engineer, dan CAN adalah keterampilan yang wajib di sana. Memahami CAN juga membuka pintu ke industri lain yang memakai bus fieldbus serupa (industri, medis, marine). Ditambah ISO 26262 (episode 20), kombinasi ini membuat profil kalian sangat berharga.

#CAN Bus: Komunikasi Differential

CAN (Controller Area Network) dirancang Bosch untuk mobil: dua kabel (CAN_H, CAN_L) dengan sinyal differential — tahan noise elektromagnetik yang parah di ruang mesin. Karakteristik inti:

Aspek	CAN
Sinyal	Differential (CAN_H − CAN_L)
Kecepatan	125 kbps – 1 Mbps (CAN); lebih tinggi (CAN-FD)
Terminasi	120 ohm di kedua ujung
Topologi	Bus multi-node
Basis	Event-driven, broadcast
Prioritas	Arbitrasi berbasis identifier

Semua node mendengar semua frame (broadcast) — tidak ada alamat tujuan seperti I2C. Identitas frame ada di identifier, dan identifier inilah yang menentukan prioritas.

#Frame CAN

Struktur frame data CAN 2.0:

Frame CAN standard (11-bit identifier)

SOF | Identifier (11 bit) | RTR | IDE | DLC (4 bit) | Data (0-8 B) | CRC | ACK | EOF

Identifier: prioritas; angka lebih kecil = prioritas lebih tinggi.
DLC: jumlah byte data (0–8).
Data: payload bebas (pengertiannya bergantung desain — baca DBC).
CRC + ACK: deteksi error dan konfirmasi penerima.

Arbitrasi: saat dua node mengirim bersamaan, node dengan identifier lebih kecil (lebih dominan) otomatis menang tanpa konflik — keunggulan yang membuat CAN sangat deterministik.

#CAN-FD

CAN-FD (Flexible Data-rate) memperbaiki dua keterbatasan CAN 2.0:

Data hingga 64 byte per frame (vs 8).
Bit rate tinggi pada fase data (hingga beberapa Mbps), tetap kompatibel dengan CAN 2.0 untuk fase arbitrasi.

Bagi firmware, CAN-FD berarti payload lebih besar dan latency lebih rendah — penting untuk update firmware (UDS) dan aplikasi berdata banyak.

#Lapisan Atas: OBD-II dan UDS

CAN adalah lapisan fisik + data link. Di atasnya ada protokol aplikasi:

Protokol	Fungsi
OBD-II	Diagnostik emisi standar; port OBD mobil
UDS (ISO 14229)	Diagnostik umum: baca/komando ECU, flash ECU (bootloader!)
CANopen	Profil aplikasi industri di atas CAN

UDS - contoh layanan

0x22  ReadDataByIdentifier : baca VIN, sensor, dsb.
0x2E  WriteDataByIdentifier: tulis data kalibrasi
0x34  RequestDownload      : mulai transfer firmware baru
0x36  TransferData         : kirim blok firmware
0x37  TransferExit         : selesaikan transfer, reboot ECU

UDS RequestDownload/TransferData adalah dasar OTA di otomotif — dan prinsipnya sama dengan yang kita bangun di episode 13/19: unduh, verifikasi, tulis slot, boot.

#AUTOSAR

AUTOSAR adalah standar arsitektur software otomotif yang memisahkan aplikasi dari hardware:

100%

Classic AUTOSAR untuk ECU kontrol real-time (rem, mesin).
Adaptive AUTOSAR untuk ECU kaya (ADAS, gateway) — berbasis Linux/Posix.

Firmware engineer di otomotif sering bekerja di lapisan BSW/MCAL (driver CAN, timer, NVM) atau aplikasi di atas RTE. Memahami lapisan ini — abstraksi aplikasi dari hardware — adalah kunci bekerja di industri.

Note

Di dunia otomotif, DBC file adalah "kamus" frame CAN: mendefinisikan message, signal, dan scaling (misal rpm_signal: 14 bit @ 6, 0.5 rpm/bit). Sebelum menulis kode CAN apa pun, mintalah DBC dan pahami makna tiap bit — frame tanpa DBC hanyalah byte tanpa arti.

#Praktik: Firmware CAN

Gunakan MCU dengan CAN controller (misal STM32 + CAN transceiver). Inti firmware:

CAN - inisialisasi dan kirim frame

#include "stm32f1xx_hal_can.h"
 
CAN_HandleTypeDef hcan;
static uint8_t tx_data[8];
 
void can_init(void) {
    hcan.Instance = CAN1;
    hcan.Init.Prescaler = 4;             // bit timing
    hcan.Init.BS1 = CAN_BS1_9TQ;
    hcan.Init.BS2 = CAN_BS2_6TQ;
    hcan.Init.Mode = CAN_MODE_NORMAL;
    HAL_CAN_Init(&hcan);
    HAL_CAN_Start(&hcan);
}
 
int can_send(uint32_t id, const uint8_t *data, uint8_t len) {
    CAN_TxHeaderTypeDef h = {0};
    h.StdId = id;                        // identifier = prioritas
    h.IDE = CAN_ID_STD;
    h.DLC = len;
    return HAL_CAN_AddTxMessage(&hcan, &h, data, 0);  // TX
}

Penerimaan memakai interrupt + FIFO (bukan polling): RX interrupt menyalin frame ke buffer, lalu task RTOS memproses — pola ISR→queue dari episode 6–7.

#Kesalahan Umum Automotive/CAN

Lupa terminasi 120 ohm — bus error, komunikasi tidak stabil.
Bit timing salah — frame "kacau"; gunakan kalkulator bit timing.
Mengabaikan DBC — signal salah interpretasi (scale/offset).
Polling untuk RX — frame terlewat; pakai interrupt + buffer.
Identifier tidak direncanakan — prioritas kacau saat beban penuh.
Tidak memvalidasi payload — frame ber-format salah diterima.

#Penutup

Inti yang harus dibawa pulang:

CAN = bus differential broadcast; identifier kecil = prioritas tinggi; frame punya CRC+ACK.
CAN-FD = payload 64 byte + bit rate tinggi, kompatibel CAN 2.0.
UDS/OBD-II di atas CAN untuk diagnostik dan flashing ECU; CANopen untuk industri.
AUTOSAR memisahkan aplikasi dari hardware via RTE dan BSW.
Praktik: inisialisasi bit timing benar, kirim via AddTxMessage, terima via interrupt.

Di episode 24 selanjutnya kita masuk era multi-prosesor: Multi-Core & Heterogeneous — MCU multi-core, mode AMP/SMP, komunikasi antar-core, dan desain firmware untuk sistem dengan beberapa inti. Perangkat kalian akan berpikir paralel!