Phish&Chips

Periodic Task Layer (PTL) per FreeRTOS

Progetto universitario – Scheduler periodico con periodi, deadline e gestione degli overruns

---

📌 Obiettivo del progetto

FreeRTOS fornisce uno scheduler preemptive basato sulle priorità, ma non garantisce periodicità né rispetto delle deadline.

Questo progetto implementa un Periodic Task Layer (PTL) sopra FreeRTOS che:

• permette di dichiarare task periodici con periodo, deadline, priorità, stack, nome, entry, arg
• rilascia le job ai tempi corretti
• rileva deadline miss
• rileva period overrun
• applica una policy di gestione degli overrun: SKIP, KILL, CATCH_UP
• mantiene invariato lo scheduler nativo di FreeRTOS (preemptive a priorità)

Il PTL deve essere minimale, portabile e integrato con FreeRTOS con intrusività minima.

---

🧠 Terminologia essenziale

• Periodo (T) – Intervallo tra due rilasci consecutivi.
• Deadline (D) – Deadline relativa alla job; se non specificata vale D = T.
• Release time (Rₖ) – Tempo di attivazione della job k.
• Finish time (Fₖ) – Tempo in cui la job k termina.
• Deadline miss – Quando Fₖ > Rₖ + D.
• Period overrun – Quando la job k non è terminata all’arrivo di Rₖ₊₁.

---

📁 Struttura del repository

freertos-periodic-scheduler-ptl/ │ ├── README.md │ ├── docs/ │ ├── spec.md # Riassunto specifica + dubbi │ ├── design.md # Architettura PTL, API, strutture dati │ └── tests-plan.md # Piano di test (miss, overrun, policy, ecc.) │ ├── src/ │ ├── ptl/ # Codice del Periodic Task Layer │ ├── app/ # Applicazione dimostrativa con task A/B/C │ └── freertos/ # Eventuali file FreeRTOS richiesti dal porting │ ├── config/ │ └── board/ # Configurazioni della board / emulatore │ └── tools/ └── scripts/ # Script build, log, analisi

(Le cartelle vuote contengono un .gitkeep per essere versionate.)

---

🔧 Workflow Git del team

Per evitare conflitti e mantenere main stabile, usiamo questo workflow:

🌿 Branch principali

• main → codice stabile, protetto
• dev → integrazione del lavoro di gruppo

🌱 Branch di sviluppo (feature)

Ogni funzionalità si implementa in un branch dedicato:

Esempi:

• feature/ptl-config-interface
• feature/deadline-checks
• feature/overrun-policy
• feature/logging

---

🔄 Regole del workflow Git (da seguire SEMPRE)

1. Non si lavora mai direttamente su main o dev.

2. Ogni sviluppatore crea la propria feature branch:

   git checkout dev
   git pull
   git checkout -b feature/nome-feature
   

git add . git commit -m "Implementazione ..." git push --set-upstream origin feature/nome-feature

4. Aprire una Pull Request → da feature/xyz verso dev.
5. Almeno un membro del team deve approvare la PR.
6. Solo quando dev è stabile si apre una PR verso main.