Belajar Firmware Engineer - Device Drivers

#Pendahuluan

Setelah di episode 9 kita mahir membedah firmware yang bermasalah, sekarang kita membalik perspektif: merancang kode yang jarang bermasalah. Episode ini membahas device drivers — lapisan yang menjembatani hardware dan aplikasi — dan arsitektur yang membuatnya bersih, portabel, dan mudah diuji.

Mengapa arsitektur driver penting? Karena dalam produk nyata, satu sensor dipakai beberapa tempat, satu driver dipakai lintas board, dan tim QA butuh cara menguji tanpa hardware. Driver yang ditulis asal-asalan — inisialisasi tersebar, register dipanggil langsung di aplikasi — adalah biang bug yang menyebar ke seluruh project.

#HAL vs Bare-Metal

Pertanyaan pertama setiap project: pakai HAL (Hardware Abstraction Layer vendor) atau register langsung?

Keduanya sah. Banyak project produksi memakai kombinasi: HAL untuk peripheral kompleks (USB, Ethernet), bare-metal untuk jalur kritis yang butuh kontrol penuh (timing ketat, low power). Yang terpenting: konsisten dan terdokumentasi — bukan dogma.

#Lapisan Arsitektur Driver

Driver yang baik punya lapisan yang jelas, masing-masing dengan satu tanggung jawab:

• Driver perangkat tahu logika device (protocol, register internal sensor) — tidak tahu pin mana.
• BSP (Board Support Package) tahu wiring board — pin, clock, power.
• Register access melakukan MMIO nyata.

Hasilnya: driver sensor bisa dipakai di board lain tanpa diubah — hanya BSP yang berubah. Ini juga memudahkan mocking untuk test (episode 14).

#Pola Device Struct dengan Function Pointer

Cara klasik membuat driver "objek": struct perangkat berisi state dan operasi:

typedef struct {
    uint8_t i2c_addr;
    uint16_t last_temp_x10;      // suhu x10 untuk presisi
    int (*init)(Sensor_t *self);
    int (*read)(Sensor_t *self);
} Sensor_t;
 
Sensor_t sensor_lm75_create(uint8_t addr);

static int lm75_init(Sensor_t *s) {
    // tulis konfigurasi register (misal resolusi)
    return i2c_write_byte(s->i2c_addr, LM75_CFG, 0x0);
}
 
static int lm75_read(Sensor_t *s) {
    uint16_t raw = 0;
    i2c_read_regs(s->i2c_addr, LM75_TEMP, (uint8_t *)&raw, 2);
    raw = __REV16(raw) >> 7;                 // format 11-bit
    s->last_temp_x10 = (int16_t)raw * 5;     // 0.5C per bit -> x10
    return 0;
}
 
Sensor_t sensor_lm75_create(uint8_t addr) {
    Sensor_t s = { .i2c_addr = addr,
                   .init = lm75_init, .read = lm75_read };
    return s;
}

Pola ini memisahkan antarmuka (apa yang bisa dilakukan) dari implementasi (bagaimana caranya) — dasar dari arsitektur driver yang bisa diganti, di-mock, dan diuji. Aplikasi memanggil sensor.read(&s) tanpa tahu chip apa di baliknya.

#Abstraksi Transport

Satu sensor bisa dipasang via I2C atau SPI di board berbeda. Abstraksi transport membuat driver tidak peduli:

// driver panggil ini - implementasi memilih I2C/SPI
typedef struct {
    int (*read_regs)(uint8_t addr, uint8_t reg, uint8_t *buf, uint16_t n);
    int (*write_byte)(uint8_t addr, uint8_t reg, uint8_t val);
} Transport_t;
 
static const Transport_t *trans;

Hasilnya: satu driver untuk chip, beberapa binding transport. Ini pola yang dipakai ST HAL dan library komersial — dan cara terbaik menghindari kode duplikat per board.

#Praktik: Driver Lengkap

Integrasikan semua lapisan untuk proyek "smart lamp" kecil:

// bsp.h
#define LED_PIN 5
void bsp_led_init(void);          // RCC + GPIO + pin mapping
void bsp_led_set(bool on);
 
// driver_led.c
void led_init(void)  { bsp_led_init(); }
void led_on(void)    { bsp_led_set(true); }
void led_off(void)   { bsp_led_set(false); }
void led_toggle(void){ static bool s=false; s=!s; bsp_led_set(s); }
 
// app.c
int main(void) {
    led_init();
    while (1) {
        led_toggle();
        delay_ms(500);
    }
}

Aplikasi tidak tahu register apa pun — ia berbicara dengan driver, driver berbicara dengan BSP. Struktur ini siap dipakai untuk proyek yang jauh lebih besar.

#Kesalahan Umum Driver

1. Driver menempel ke board — pin & clock ditulis di dalam driver; mati portabilitas.
2. Inisialisasi tersebar — setiap fungsi meng-set register sendiri; sulit di-audit.
3. Tanpa antarmuka — aplikasi memanggil register langsung; test mustahil.
4. Mengabaikan error handling — i2c_read gagal harus ketahuan, bukan diam.
5. Driver raksasa — satu file 2000 baris; pecah per device/logika.

#Penutup

Inti yang harus dibawa pulang:

• HAL vs bare-metal adalah keputusan project, bukan dogma; kombinasi keduanya wajar.
• Arsitektur berlapis: aplikasi → driver → BSP → register; tiap lapisan satu tanggung jawab.
• Device struct + function pointer memisahkan antarmuka dari implementasi.
• Abstraksi transport membuat driver sensor netral terhadap I2C/SPI.
• Driver yang bersih = portabel, bisa di-mock, dan mudah dirawat.

Di episode 11 selanjutnya kita mengoptimalkan untuk baterai: Low Power Firmware — sleep modes, wake sources, konsumsi energi, dan desain firmware yang tidur nyenyak dan bangun tepat waktu. Perangkat kalian akan mulai "hidup hemat"!