---
# System prepended metadata

title: TP_IOT2_AzkaNabihan_2306250541

---

---
title: TP_Modul 2_Task Management

---

# Tugas Pendahuluan Modul 2 - Task Management

```
Nama  : Azka Nabihan Hilmy
NPM   : 2306250541
```

> Note: Soal Programming tidak perlu dicantumkan referensi, hanya soal Teori saja yang perlu referensi minimal 2.

## Teori

### 1. Jelaskan **logika** mengapa *task scheduling* sangat penting dalam aplikasi IoT berbasis RTOS? Sertakan contoh konkrit dan rill yang dapat memberikan gambaran tentang apa yang akan terjadi jika *scheduling* tidak berjalan dengan baik. <span style="color:red;">(15 Poin)</span>

---

Task scheduling sangat penting dsalam IOT berbasis RTOS karena memastikan tugas berjalan tepat waktu dan efisien [1]. Scheduler bertindak sebagai manajer lalu lintas yang mengalokasikan sumber daya CPU secara adli dan teratur [2], ini memastikan bahwa tugas dengan priortias tinggi akan mendapatkan sumber daya CPU yang dibutuhkan untuk menyelesaikan tugasnya tepat waktu. 

Sebuah sistem smart farming menggunakan RTOS untuk mengontrol irigasi otomatis, memantau kelembaban tanah, dan mengirimkan notifikasi kepada petani[1]. Anggap saja ada tugas dengan prioritas rendah, akan mengirimdata kelembaban tanah ke server setiap 20 menit, tugas dengan prioritas sedang akan menyalakan pompa irigasi jika kelembapan di bawah ambang batas. Lalu ada prioritas tinggi mengirimkan peringatan darurat jika sensor mendeteksi kebakaran. Dengan scheduler yang baik, semua tugas dapat bejalan sesuai priortas dari rendah, sedang, tinggi. Jika scheduler tidask efektif atau jika scheduling mengalami gangguan, seperti tugas semuanya dilakukan untuk mengirim data lalu kurangnya task scheduling yang baik sehingga tugas menyalakan pompa tidak bisa dieksekusi tepat waktu, maka tanaman bisa kering dan mati. Lalu jika kedua hal tersebut tidak berjalan seharusnya, maka aplikasi dapat crash dan tidak menjalankan tugas apa apa. Lalu saat tugas dengan prioritas tinggi harus dijalankan, tugas tersebut tidak akan pernah dieksekusi dan membahayankan ladang.


### Referensi:
- [1] “The Importance of Task Scheduling in IoT,” https://www.google.com/search?q=Digilabdte.com, 2024. Available : https://learn.digilabdte.com/books/internet-of-things/page/the-importance-of-task-scheduling-in-iot. [Diakses: 10-September-2025]
- [2] “Categories of Task Scheduling Algorithms,” https://www.google.com/search?q=Digilabdte.com, 2024. Available : https://learn.digilabdte.com/books/internet-of-things/page/categories-of-task-scheduling-algorithms. [Diakses: 10-September-2025]

---

### 2. Bandingkan algoritma Run to Completion (RTC) dan Round Robin (RR) dalam RTOS. Dalam kondisi apakah algoritma RTC lebih cocok untuk diterapkan? Begitu pula sebaliknya. Jelaskan dengan komperhensif! <span style="color:red;">(15 Poin)</span>

---

#### Logika Penjadwalan
- RTC : Tugas yagn sedang berjalan akan terus dieksekusi hingga selesai, diblokir, atau berhenti. Tidak ada interupsi oleh tugas lain.
- RR : setiap tugas diberi alokasi waktu , jika tugas belum selesai dalam alokasi waktu tersebut, tugas akan diberhentikan sementara dan CPU dialihkan ke tugas berikutnya.

#### Responsivitas
- Jika ada tugas dengan durasi panjang yagn sedang berjalan, harus menunggu hingga tugas tersebut selesai. [1]
- Karena setiap tugas mendapatkan giliran secara adli, tidak ada tugas yang menunggu terlalu lama, memastikan responsivitas yagn konsisten untuk semua tugas.[2]

#### Overhead
- RTC : Rendah, tidak ada kebutuhan untuk menyimpan konteks tugas.
- RR : Tinggi, membutuhkan overhead untuk menyimpan dan memulihkan konteks tugas. [2]

#### Keadilan
- RTC : Tidak adil. Satu tugas dapat memonopoli CPU, membuat tugas lain kelaparan.
- RR : Adil, semua tugas dengna prioritas yagn saman mendapatkan waktu CPU yang setara. 

#### Kondisi Penerapan yang Sesuai
- Kondisi dimana RTC lebih cocok : 
    - RTC cocok untuk tugas berdurasi pendek dasn predictable sehingga tidak ada tugas yang memonopoli CPU terlalu lama. [1]
    - Dalam sistem di mana tidak ada tugas dengan prioritas yang jauh lebih tinggi dan kegagalan responsivitas bukan masalah utama, RTC bisa digunakan untuk menyederhanakan kode dan mengurangi overhead.

- Kondisi dimana RR lebih cocok : 
    - RR cock untuk aplikasi yang membutuhkan responsivitas yang cepat dan merata dari berbagai tugas. Contohnya adalah sistem smart home dengan banyak fitur yagn harus dijalankan secara responsif dan tidak ada satu pun tugas yang boleh memonopoli CPU. [2]
    - Aplikasi dengan Tugas yang Sulit Diprediksi Durasi Eksekusinya
    - Aplikasi Multi-Tugas dengan Kebutuhan Waktu yang Adil


### Referensi:
- [1]“Categories of Task Sch... | Digilab UI,” Digilabdte.com, 2025. [Online]. Available:  https://learn.digilabdte.com/books/internet-of-things/page/categories-of-task-scheduling-algorithms. [Diakses: 10-September-2025]
‌- [2]“Task scheduling with a real time operating system - Embedded Software,” Embedded Software, May 07, 2018. [Online]. Available: https://blogs.sw.siemens.com/embedded-software/2018/05/07/task-scheduling-with-a-real-time-operating-system/. [Diakses: 10-September-2025]
‌
---

### 3. Jelaskan mengapa Earliest Deadline First (EDF) sering dianggap lebih optimal? Lalu apa yang menjadi tantangan dalam penerapannya? Jelaskan! <span style="color:red;">(15 Poin)</span>

---
![image](https://hackmd.io/_uploads/Hym4GnRclg.png)

EDF adlaah algoritma scheduling prioritas dinamis, di mana prioritas tugas tidak ditentukan secara statis, tetapi berubah seiring waktu berdasarkan deadline[1]. EDF dapat menjamin bahwa semua tugas yang periodik dan independen akan memenuhi deadline selama pemanfaatan CPU total tidak melebihin 100%, ini bernama Teorema EDF. Teorema EDF adalah jika sistem dapat dijadwalkan , maka EDF dapat melakukannya. Karena EDF fokus pada deadline daripada periode tugas, maka lebih fleksibel dalam menangani tugas-tugas non periodik sehingga EDF lebih efisien dalam penggunaan sumber daya secara keseluruhan.

Tantangan dalam penerapan EDF : 
- Membutuhkan sumber daya komputasi yang besar dan bisa menjadi tidak efisien jika sistem memiliki banyak tugas yang seringkali beralih status [1].
- Jika pemanfaatan CPU melebihi 100%, meskipun hanya untuk sementara, EDF tidak memiliki mekanisme yang jelas untuk menentukan tugas mana yang akan gagal memenuhi deadline, semua tugas bisa gagal, sistem dapat menjadi tidak stabil dan sulit untuk memprediksi tugas yang akan terlambat[2].
- Memiliki kompleksitas perhitungan yang lebih tinggi.


### Referensi:

- [1]“Categories of Task Sch... | Digilab UI,” Digilabdte.com, 2025.[Online]. Available: https://learn.digilabdte.com/books/internet-of-things/page/categories-of-task-scheduling-algorithms. [Diakses: 10-September-2025]
‌- [2]GeeksforGeeks, “Earliest Deadline First (EDF) CPU scheduling algorithm,” GeeksforGeeks, Jan. 30, 2020. [Online]. Available: https://www.geeksforgeeks.org/operating-systems/earliest-deadline-first-edf-cpu-scheduling-algorithm/. [Diakses: 10-September-2025]
‌
- ---


### 4. Sebuah sistem IoT dapat memiliki sejumlah *task* dengan kebutuhan yang berbeda. Pertanyaannya, mengapa penting memberi prioritas berbeda pada tiap *task*? Apa risiko yang dapat terjadi jika seluruh *task* diberi prioritas yang sama? <span style="color:red;">(20 Poin)</span>

---

Pada sistem IoT, tugas-tugas memiliki tingkat prioritas yang berbea. Tugas dengan prioritas tinggi seperti yang berhubungan dengan keselamatan atau kontrol feedback loop, akan dieksekusi terlebih dahulu sehingga menjami respons real-time. Prioritas memungkinkan sistem untuk fokus pada tugas yang paling kritis, sehingga meningkatkan efisiensi dan keandalan sistem secara keseluruhan[1].

Jika semua task diberi prioritas sama, terdapat kondisi dimana satu atau lebih task tidak pernah mendapatkan giliran untuk dieksekusi karena task lain yang berjalan. Jika semua tugas diperlakukan sama, dan tugas yang membutuhkan eksekusi cepat mungkin tidak pernah mendapat kesempatan [2].


### Referensi:

- [1]“The Importance of Task... | Digilab UI,” Digilabdte.com, 2025. [Online]. Available:  https://learn.digilabdte.com/books/internet-of-things/page/the-importance-of-task-scheduling-in-iot. [Diakses: 10-September-2025]
‌- [2]GeeksforGeeks, “Scheduling in Real Time Systems,” GeeksforGeeks, Mar. 30, 2020. [Online]. Available: https://www.geeksforgeeks.org/operating-systems/scheduling-in-real-time-systems/. [Diakses: 10-September-2025]
‌

---

## Programming

### 5. Buatlah program berikut ini pada ESP-32 dan lakukan analisis (berupa penjelasan logikanya): <span style="color:red;">(35 Poin)</span>

Buat proyek ESP-32 dengan 2 *tasks*:
1. `LedTask` (prioritas lebih rendah), yaitu untuk menyalakan/mematikan LED_BUILTIN setiap 500 ms secara periodik (*stable*).
2. `PrintTask` (prioritas lebih tinggi), yaitu untuk mencetak ke serial: "[tick] PrintTask : message" setiap 1000 ms secara periodik (*stable*).

---
*Acceptance Criteria*:
1. ***Hint***: Harus berlangsung secara periodik (***stable***).
2. Menampilkan *tick* di log Serial.

---
Contoh *Output*:

![Output Example](https://ik.imagekit.io/livxgezjhg/Example_Output.png?updatedAt=1756830622631)

---
    Code Kalian :

```cpp
#include <Arduino.h>
#include <freertos/FreeRTOS.h>
#include <freertos/task.h>

// Task handle
TaskHandle_t LedTaskHandle = NULL;
TaskHandle_t PrintTaskHandle = NULL;

// Fungsi untuk task LED (toggle setiap 500 ms)
void LedTask(void *parameter) {
    bool ledState = false;
    TickType_t lastWakeTime = xTaskGetTickCount();

    while (true) {
        ledState = !ledState;
        digitalWrite(2, ledState);

        uint32_t currentTime = millis();
        Serial.printf("[%u] LedTask: LED Toggling\n", currentTime);

        vTaskDelayUntil(&lastWakeTime, pdMS_TO_TICKS(500));
    }
}

// Fungsi untuk task print (setiap 1000 ms)
void PrintTask(void *parameter) {
    TickType_t lastWakeTime = xTaskGetTickCount();

    while (true) {
        uint32_t currentTime = millis();
        Serial.printf("[%u] PrintTask: Print Task Succeed\n", currentTime);

        vTaskDelayUntil(&lastWakeTime, pdMS_TO_TICKS(1000));
    }
}

void setup() {
    Serial.begin(115200);

    // ⚠️ TUNDA 500ms agar sistem stabil sebelum membuat task
    delay(500); 

    pinMode(2, OUTPUT);

    // Buat task di core yang berbeda
    xTaskCreatePinnedToCore(
        LedTask,
        "LedTask",
        2048,
        NULL,
        1,                    // Prioritas rendah
        &LedTaskHandle,
        0                     // Core 0
    );

    xTaskCreatePinnedToCore(
        PrintTask,
        "PrintTask",
        2048,
        NULL,
        2,                    // Prioritas tinggi
        &PrintTaskHandle,
        1                     // Core 1
    );
}

void loop() {
    // Kosong
}
```


**Analisa** : 
Program ini memanfaatkan FreeRTOS untuk menjalankan dua task independen yaitu, LedTask (toggle LED tiap 500 ms, prioritas rendah) dan PrintTask (cetak log tiap 1000 ms, prioritas tinggi). Kedua task menggunakan vTaskDelayUntil() eksekusi tetap periodik dan tidak mengalami drift, karena vTaskDelayUntil() menghitung delay relatif terhadap waktu wake sebelumnya, bukan waktu pemanggilan fungsi. Variabel lastWakeTime diinisialisasi saat task dimulai dengan xTaskGetTickCount(), lalu diperbarui otomatis oleh vTaskDelayUntil() agar interval tetap presisi. Dengan memisahkan task di dua core berbeda (Core 0 dan Core 1) dan memberi prioritas lebih tinggi ke PrintTask, sistem memastikan bahwa saat terjadi bentrokan waktu (misal di 1000 ms), PrintTask akan dieksekusi lebih dulu sesuai prioritas, meskipun dalam praktik output serial bisa membuat urutan cetak terlihat berbeda karena buffering atau kecepatan I/O.

Namun karena melakukan simulasi di Wokwi, penggunaan FreeRTOS dengan vTaskDelayUntil() tidak menghasilkan output yang sesuai karena simulasi Wokwi tidak sepenuhnya mendukung real-time behavior FreeRTOS. Di hardware asli, FreeRTOS mengandalkan interrupt timer hardware untuk mengatur tick setiap 1 ms, sehingga vTaskDelayUntil() bisa menjamin eksekusi task secara periodik dan presisi. Namun, di Wokwi, mekanisme tick timer ini tidak disimulasikan secara akurat, sehingga xTaskGetTickCount() dan millis() bisa berjalan tidak sinkron, menyebabkan drift waktu besar dan task dieksekusi terlalu cepat atau terlambat. Akibatnya, alih-alih dimulai dari 500 ms, log pertama muncul di sekitar 1992 ms.


**Output** : 
![image](https://hackmd.io/_uploads/rJfqRLejxg.png)

