Úloha je určená pro dvojice studentů, ale může ji řešit také samostatně.
Na plný počet bodů je nutné práci odevzdat na reálném hardware, MZ_APO nebo jiný vestavný systém. Část práce s periferií lze odladit i simulátoru QtRVSim a je možné práci i odevzdat ve verzi pouze pro QtRVSim, ale s bodovým hodnocením sníženým o 10 bodů.
Odevzdání úlohy je možné až do jednoho týdne po zápočtovém týdnu. Za každý další započatý týden -10 bodů. Začněte ale na práci pracovat co nejdříve. Pokud se pustíte naopak do většího projektu, předvedete dosažení dílčích cílů včas, tak se můžete se cvičícími dohodnout na termínu i individuálně.
Kategorie | Body | Poznámka |
---|---|---|
Specifikace zadání | 1b | V BRUTE semassign . |
- včasné zadání/založení týmu | 1b | |
Splnění specifikace | 2b | |
Komplexnost zadání | 3b | Komplexnost zadání bude ohodnocena ohodnocena předem, podle specifikace zadání. Po ohodnocení je možno dohodnout možnosti rozšíření práce za více bodů. |
Práce s HW | 3b | Alespoň tři různé periferie. RGB diody, řádka LED, sériový port, otočné voliče, standardní vstup (např. přes SSH) bez čekání na novou řádku (raw), četní polohy a nastavení PWM pro DC motor, zpracování externí události v přerušení (QtRvSim), implementace systémového volání (obsluha/zpracování výjimky)… |
Výstup na grafický display | 3b | |
- výpis fontu | 1b | |
- výpis s proměnnou šířkou znaku | 1b | |
- čárová grafika nebo menu | 1b | |
Kvalita provedení (kódu) | 5b | |
- formátování kódu | konzistentní odsazování, mezery | |
- dekompozice do funkcí, souborů a “modulů” | Maximální délka funkce by neměla přesáhnout desítky řádek - “jedna funkce dělá jednu věc” (a podle toho se jmenuje). C soubor by typicky neměl mít více než 150/200 řádek | |
- obecně si zvolit coding style a ten pak držet | Inspirovat se PEP20 a např. Linux kernel coding style | |
Ergonomie a grafické zpracování | 3b | |
- víceúrovňové menu, využití bitmapové nebo vektorové grafiky | ||
- vhodné využití vstupních ovladačů | ||
- preciznost a ošetření zákmitu při snímaní vstupu (deadband, ošetření zákmitů, reakce na hranu) | ||
Dokumentace | 4b | Povinná, bez ní nelze práci hodnotit jako splněnou. |
- uživatelský manuál | 1b | Umožní plně použít i bez zaškolení. Examples |
- popis kompilace, instalace, spuštění | 1b | Ideálně jako součást zdrojového kódu (např. Doxygen formát). |
- architektura aplikace | 1b | Schéma fungování aplikace, dokumentace struktury projektu (kde jsou jednotlivé hlavní komponenty). |
- programátorská dokumentace | 1b | Dokumentace použití funkcí a struktur. |
*Git | +3b | Bonusové body za správné vedení projektu. Návod |
- vedení projektu ve verzovacím systému git | +1b | Repozitář existuje a nejsou v něm generované soubory, když projekt odevzdává dvojice, tak commity od obou. |
- smysluplně pojmenované commity | +1b | Commit message odpovídá provedeným změnám. Každý commit by také měl ideálně upravovat/přidávat pouze jednu ucelenou funkcionalitu. |
- merge request | +1b | Vývoj je veden v samostatné větvi (např. “dev”) a ještě před odevzdáním úlohy do brute je vytvořen v gitlabu (nebo githubu) Merge request pro zamergování vývojové větve to větve “master” a je přiřazen na review cvičícímu. |
V případě individuálního zadání, které nezapadá do těchto kategorií, může cvičící rozložení bodů upravit.
Pro odevzdání je potřeba založit tým a bude to platit i pro jednotlivce. Vytváření týmu je nastavené pro umožnění práce ve dvojicích. V případě nesprávného založení týmu kontaktujte svého cvičícího, který tým odstraní.
Archiv odevzdaný do systému by neměl obsahovat objektové a zálohové soubory. Finální spustitelný soubor obsahovat může, ale použitý bude jen ve výjimečných případech. Program musí být možné přeložit. Instrukce by mely být specifikované v technické části dokumentace. Preferované je použití sestavovacího programu “make”. Kontrolovat bude program cvičící za účasti studenta (v případě práce ve dvojici obou studentů) kód odevzdaný do systému. Především při kontrole po termínu odevzdání bude testování zaměřené na verzi nahranou do systému. Nutné úpravy na místě budou znamenat snížení hodnocení podle pravidel odevzdání v čase odpovídajícím testování. Kromě kontroly funkce můžete očekávat dotazy na implementaci a koncepci odevzdaného kódu. V případě odevzdání v týmu budou otázky směrované libovolně na členy týmu a nedostatky znalosti funkce kódu mohou snížit hodnocení projektu pro oba členy.
I hlavní soubor aplikace by měl být přejmenovaný.
Zároveň by v záhlaví vámi vytvářených souborů měla být vyplněna jména skutečných autorů a licence díla. Soubor change_me.c berte jako vzor a hlavičku přepište.