* Publicare:
* Termen de predare:
* Changelog:
url.txt
+ checksum.txt
(CU extensie).
kas
(în format yml
) din fișiere diferite + layere separate).
A venit Crăciunul! Ca viitori ingineri ai unei facultăți de renume din țară (*ahem*), dorim să impresionăm familia / rudele / pisica / vecinii construind o instalație de pom controlabilă din Internet of Things!
Așadar, ne apucăm de treabă: luăm o bandă cu LED-uri și începem prin dezvoltarea unei aplicații care să le poată controla de la distanță, printr-o interfață RESTful HTTP. Însă intervine problema: pe ce o rulăm? Ne amintim ce am studiat la cursul și laboratoarele de S.I și ne dăm seama că avem un Raspberry PI mai vechi aruncat într-o cutie, deci mai rămâne doar de construit / configurat o distribuție lightweight de Linux (sorry, Santa) ce se va interfața cu hardware-ul instalației de lumini și va oferi suport pentru rularea aplicației și conectarea la Internet.
Ca și cerință principală, va trebui să realizați o imagine incorporabilă Linux folosind Yocto ce va expune pe rețea un server HTTP cu API REST-ful (detalii / specificație mai jos) pentru primirea de comenzi de control al LED-urilor.
De asemenea, dorim să vedem, în consolă, o simulare grafică (ASCII Art) a bradului de Crăciun cu luminițele aprinse în starea actuală. Un exemplu de pom luminat poate fi văzut în captura de mai jos (asciinema):
qemuarm
;root
cu parola tema2
(obligatoriu!!);tema2
;tema2.local
.
rc.d
/runlevels
, instalat implicit – nu trebuie să mai compilați nimic) și SystemD (mai ușor de definit serviciile, însă trebuie compilat și poate dura ~1h, depinde de puterea de calcul a sistemului).
christmas-tree
) rulabil ca root
care să afișeze la stdout un ASCII ART (pe consolă, folosind secvențe escape ANSI);christmas-tree
și să fie în PATH
(rulabil direct prin acest nume într-un terminal)! Acesta va fi pornit automat, prin ssh
, pentru testare facilă!Dorim să trimitem comenzile primite de serverul HTTP către instalația hardware de leduri. Astfel:
/sys
(API vechi) sau /dev
+ eventual, puteți găsi biblioteci în limbajul ales;
Sistemul va reprezenta un pom de Crăciun cu o serie de luminițe organizate în NG
grupuri de câte 1..n
LED-uri fiecare (fiecare grup poate conține număr diferit de luminițe).
Parametrii aceștia puteți să-i alegeți la liber și să-i hardcodați (în funcție de câte luminițe aveți loc să reprezentați în ASCII Art-ul din terminal), însă ar fi drăguț să aveți minim 3 grupuri (e.g., pentru fiecare etaj al bradului sau pe diagonală).
Fiecare grup are ca identificator unic (unde numerotarea începe de la 1
!) este un vector de LED-uri (de dimensiune statică).
Valoarea fiecărui LED dintr-un grup va fi ID-ul numeric al culorii acestuia, folosind culorile clasice din terminal:
0
(black) (echivalent al LED-ului stins);1
(red);2
(green);3
(yellow);4
(blue);5
(magenta);6
(cyan);7
(white);Astfel, se definesc următoarele endpointuri RESTful HTTP (atenție: API-ul este strict!):
GET /api/groups
: va întoarce un obiect JSON cu proprietatea NG
(numărul de grupuri disponibile), e.g.: {“NG”: 3}
;GET /api/group/<G>/state
: va întoarce un obiect JSON cu cheila NL
: numărul de leduri din grupul curent, și LC
: lista actuală de culori ale LED-urilor grupului <G>
(fără caracterele <>
, sunt doar pentru a denota o variabilă), e.g., {“NL”: 8, “LC”: [0, 0, 0, 1, 4, 2, 0, 0]}
;POST /api/group/<G>/static
: va primi un obiect JSON cu o singură cheie: LC
cu valoarea: o listă (JSON Array) de culori pentru fiecare LED din grupul <G>
, și va întoarce OK (HTTP 200); desigur, aceste noi setări trebuiesc propagate către aplicația de terminal ce redă ASCII Art-ul;POST /api/group/<G>/animate
[BONUS]: va primi un obiect cu o cheie, MC
care conține o matrice de culori pentru fiecare pas al animației, apoi pentru fiecare LED din grupul <G>
și va întoarce OK (HTTP 200); tranzițiile vor fi făcute la fiecare secundă și va fi repetată automat până la revenirea la cazul simplu (cererea de mai sus); exemplu de mutare a culorilor asupra tuturor pozițiilor dintr-un grup: [ [1, 2, 3, 0, 0, 0, 0, 0], [0, 1, 2, 3, 0, 0, 0, 0], [0, 0, 1, 2, 3, 0, 0, 0], [0, 0, 0, 1, 2, 3, 0, 0], [0, 0, 0, 0, 1, 2, 3, 0], [0, 0, 0, 0, 0, 1, 2, 3], [3, 0, 0, 0, 0, 0, 1, 2], [2, 3, 0, 0, 0, 0, 0, 1], ]
Toate cererile vor folosi formatul Content-Type: application/json
atât la input (pentru cererile POST
), cât și la răspuns.
Vedeți exemple de utilizare în fișierul test.py
din schelet.
v6.2+
pe Ubuntu 22.04) pentru placa virt (este deja tipul implicit pentru build-urile Yocto ale qemuarm
, cel folosit la laborator).
Ca și punct de pornire, puteți descărca un schelet inițial cu scripturi + structură recomandată (v0.1). Aceasta conține:
tema2.yml
);test.py
);
Recomandarea de co-existență pentru tema2 + laborator folosind același VM cu Yocto: fișierele kas cu denumiri diferite (tema2.yml
vs kas.yml
) ce vor importa seturi diferite de layere (desigur, cele de bază vor rămâne, însă se recomandă crearea unui layer numit meta-tema2
și să creați în interiorul lui configurațiile / pachetele necesare tuturor task-urilor).
8GB
ar trebui să fie OK pentru majoritatea cazurilor).
Soluția temei va fi trimisă în două moduri (vă rugăm să respectați convențiile de denumire cu exactitate!):
url.txt
).
Arhiva cu binarele (.tar.gz
pls) trebuie să conțină (de preferat să folosiți strict aceste denumiri de fișiere):
rootfs.img
: imaginea partiției rootfs în format RAW utilizabil de qemu (ori partiția ext4, ori disk image);kernel
: binarul kernel-ului compatibil cu QEMU (scheletul îl copiază automat din cache-ul Yocto);launch_bin.sh
: script de pornire QEMU (vedeți scheletul dat);test.py
.500MB
(și asta în cazuri extreme).
Arhiva cu fișierele sursă (.zip
pls) este OBLIGATORIU să conțină:
yml
pentru kas
) + sursele aplicației (în orice limbaje ați ales);README.txt
cu explicații referitoare la funcționarea soluției, configurații speciale de optimizare folosite etc.url.txt
cu URL către arhiva .tar.gz a binarelor;checksum.txt
care să conțină hash-ul SHA256 al arhivei cu binarele (obținut cu sha256sum
); ATENȚIE: verificați și re-verificați (de încă 2 ori) conținutul fișierului la încărcare pe Moodle cu hash-ul real deoarece tema nu va fi punctată dacă diferă!kas
).make source_archive
, pur și simplu copiați-l pe rădăcină (sau într-un director care nu este ignorat – verificați Makefile-ul din schelet)!1MB
(aveți restricție pe Moodle).
Din 100p total, aveți:
Bonus:
PL061
în kernel);