Show page

Differences

This shows you the differences between two versions of the page.

--- si:teme2021:tema2 [2021/12/15 21:31]
florin.stancu
+++ si:teme2021:tema2 [2022/12/11 14:14] (current)
florin.stancu
@@ Line 1: / Line 1: @@
-====== Tema 2 - Yellow Submarine ======
+====== Tema 2 - Christmas LEDs ======
 * **Publicare**:
-  * **15 Decembrie 2021 //21:00//**
+  * **11 Decembrie 2022 //16:00//**
 * **Termen de predare**:
-  * <color red>**16 Ianuarie 2022 23:55** - deadline HARD</color>
+  * <color red>**14 Ianuarie 2023 23:55** - deadline HARD</color>
 * **Changelog:**
-  * //nothing yet//
+  * //nothing, yet//
 <note>
-**Obiective**
+**Obiective**:
-  * construirea unei distribuții Linux complete (cu aplicații)
+  * construirea unei distribuții Linux complete, build folosind Yocto;
-  * build workflow cu Yocto
+  * creare layere + pachete Yocto;
-  * folosirea layerelor, adăugarea de pachete necesare unei aplicații concrete
+  * configurări de bază Linux;
-  * configurări de bază pentru o rețea
+  * servicii de sistem Linux;
-  * scripting și folosirea utilitarelor dintr-un sistem Linux
+  * dezvoltare aplicații RESTful;
-  * optimizări de spațiu folosit (opțional)
+  * dezvoltare aplicații Terminal UI;
+  * interfață GPIO Linux;
+  * optimizări de spațiu;
 </note>
 <note important>
-**TLDR:** Am pus pus la dispoziție o [[#helpers_masina_virtuala|mașină virtuală]] cu build-ul de Yocto finalizat pentru imaginea de bază.
+Pentru a rezolva tema, este recomandat să folosiți [[https://github.com/cs-pub-ro/SI-Lab-VM/releases/|mașina virtuală Yocto 2022 (~22GB)]] cu distribuția Yocto gata compilată și cache-uită, altfel timpul de compilare pe un laptop modest poate fi chiar și de 10 ore!
-Dimensiune arhivă de descărcat: ''~19GB''; dimensiune dezarhivată: ''32GB'' (țineți cont: unele utilitare de dezarhivare folosesc un director temporar pe partiția OS-ului!).
+Puteți lucra în paralel cu laboratorul pe aceiași mașină (veți folosi descriptori de ''kas (yml)'' din fișiere diferite + layere separate).
-De preferat ar fi să o descărcați cât mai curând, chiar dacă nu vă apucați acum de temă, deoarece va consuma timp ;)
 </note>
+<note important>
+Work in progress: enunțul / materialele temei sunt în curs de redactare ;)
+</note>
-===== Story / Enunț =====
+<ifauth @si>
-Suntem într-un submarin (galben, OFC) în căutarea unor [[https://adventofcode.com/2021|artefacte pierdute ale Elfilor lui Moș Crăciun]] (this year's Advent of Code :P ).
+<color red>CINE VEDE ASTA MAI JOS E ASISTENT:</color>
-Presupunem că acesta este dirijat de un sistem embedded ce rulează **Linux** ([[https://www.huffpost.com/archive/in/entry/bill-gates-best-secret-santa_a_21631414|sorry, Santa]]) ce primește comenzi de pe un dispozitiv mobil printr-o interfață RESTful și afișează date de la senzorii de locație / radar pe o consolă serială (pe bază de texte ASCII și codificări de terminal ANSI).
-Va trebui să realizați un sistem embedded Linux folosind Yocto ce va expune un server HTTP cu API REST-ful (detalii / specificație mai jos) pentru primirea de comenzi / date de la senzori și va afișa planșa cu starea curentă pe o consolă serială.
+===== Storyline / Enunț =====
-Pentru aceasta, dorim să creați o interfață cât mai prietenoasă care să permită afișarea unor grafice ASCII Art cu poziția submarinului și alte obiecte detectate (e.g., artefacte, pești, mine) de către senzorii interni (ipotetic).
+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** ([[https://www.huffpost.com/archive/in/entry/bill-gates-best-secret-santa_a_21631414|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 interfață și interacțiune prin HTTP poate fi văzut în captura de mai jos (asciinema):
 <html>
-<a href="https://asciinema.org/a/0X4OCmcTyjTCvvOd1kHDepGz7" target="_blank"><img style="max-width: 600px;" src="https://asciinema.org/a/0X4OCmcTyjTCvvOd1kHDepGz7.svg" /></a>
+<a href="https://asciinema.org/a/TODO" target="_blank"><img style="max-width: 600px;" src="https://asciinema.org/a/TODO.svg" /></a>
 </html>
 ===== Cerințe =====
@@ Line 45: / Line 56: @@
 === Imaginea Linux de bază: ===
-  * Imaginea sistemului trebuie generată cu Yocto, pornind de la instrucțiunile prezente în [[:si:laboratoare:08]];
+  * Imaginea sistemului trebuie generată cu Yocto, pornind de la instrucțiunile prezente în [[:si:laboratoare:06]];
-  * Sistemul trebuie să ruleze în QEMU, folosind [[:si:laboratoare:03|un kernel compatibil]] (ori obținut prin Yocto pentru machine type ''qemuarm'');
+  * Sistemul trebuie să ruleze în QEMU ARM, folosind un kernel Yocto pentru machine type ''qemuarm'';
-  * Sistemul trebuie să aibă un utilizator ''root'' cu parola ''labsi'' (obligatoriu!!);
+  * Sistemul trebuie să aibă un utilizator ''root'' cu parola ''tema2'' (obligatoriu!!);
   * Sistemul trebuie să aibă hostname-ul ''tema2'';
-  * Sistemul trebuie să își configureze automat IP-ul folosind DHCP pe singura interfață disponibilă;
+  * Sistemul trebuie să-și preia automat IP-ul folosind DHCP pe singura interfață disponibilă;
   * Sistemul trebuie să ruleze SSH pe portul 22;
   * Sistemul trebuie să ruleze daemon-ul Avahi/mDNS și să răspundă la numele ''tema2.local''.
 === RESTful HTTP endpoint: ===
-  * Sistemul va trebui să ruleze un server http (pachet la alegere) ce să asculte după cereri HTTP bine definite de manipulare a obiectelor lumii virtuale (specificate mai jos);
+  * Sistemul va trebui să ruleze un server http ce va asculta după cereri HTTP (pe portul 80) pentru controlul luminilor (definite mai jos);
   * Puteți folosi orice limbaj de programare / scripting / framework pentru a construi acest endpoint; exemple:
       * **Python**: [[https://flask.palletsprojects.com|flask]] / [[https://docs.cherrypy.dev|CherryPy]] / [[https://fastapi.tiangolo.com/|FastAPI]] (pick any);
       * **NodeJS**: [[https://expressjs.com/|ExpressJS]] / [[https://loopback.io/|Loopback]] / other 1000s of libraries;
-      * **PHP**: well... cam e făcut pentru așa ceva, dar va trebui să faceți URL rewriting pe serverul http :P;
+      * **PHP** (//+ Apache / Nginx / Lighttpd etc.//): well... cam e făcut pentru așa ceva, dar va trebui să configurați URL rewriting pe serverul http :P ;
       * **Golang**: [[https://pkg.go.dev/net/http|net/http]] (aici nu se justifică să descărcați altceva);
       * **Rust**: [[https://docs.rs/http/latest/http/|http]] (built in, baby!);
-      * **C (hardcore style)**: [[https://facil.io/|Facil]] / [[https://github.com/babelouest/ulfius|Ulfius]]
+      * **C (for hardcore developers)**: [[https://facil.io/|Facil]] / [[https://github.com/babelouest/ulfius|Ulfius]]
-  * Alegeți ceva ce doriți să învățați sau ce vă este cel mai familiar și căutați-i layerul / pachetul de Yocto pentru instalare facilă ;)
+  * **//Hint://** alegeți ori ceva ce doriți să învățați sau pe cel cu care sunteți familiar și căutați-i layer / pachet pentru Yocto ;)
+<note>
+Serverul trebuie să pornească automat la boot (ca daemon). În Yocto [[https://docs.yoctoproject.org/dev-manual/common-tasks.html#enabling-system-services|aveți două opțiuni de bază]]: **SysVInit** (aka ''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).
+</note>
-=== Display daemon: ===
+=== Terminal UI program: ===
-  * Pe lângă serviciul web, va trebui să dezvoltați un program responsabil să afișese textual pe o consolă serială conectată la ''tty0'' (emulată, conectată la stdout-ul qemu);
+  * Pe lângă serviciul web, va trebui să dezvoltați un program (numit ''christmas-tree'') rulabil ca ''root'' care să afișeze la stdout un ASCII ART (pe consolă, folosind [[https://chrisyeh96.github.io/2020/03/28/terminal-colors.html|secvențe escape ANSI]]);
-  * Programul va afișa în mod dinamic (timp real, însă e OK și la 1 fps) o artă ASCII de îndată ce aceasta este încărcată și să o afișeze în consola.
+  * Programul va afișa, în mod dinamic (actualizare timp real, cu latența de preferat de ordinul secundelor), un pom de Crăciun frumos luminat / colorat după ultima stare configurată prin API-ul RESTful (serverul HTTP).
   * La fel ca la serviciul web, puteți folosi orice limbaj + biblioteci de desenare pe consolă doriți, exemple:
-    * **Python**: [[https://docs.python.org/3/howto/curses.html|curses (built-in)]] / [[https://pypi.org/project/urwid/|urwid]];
+    * **Python**: [[https://docs.python.org/3/howto/curses.html|curses (built-in)]] / [[https://github.com/Textualize/rich|Rich]] / [[https://pypi.org/project/urwid/|urwid]];
     * **NodeJS**: [[https://github.com/chjj/blessed|blessed]] / [[https://github.com/cronvel/terminal-kit|Terminal Kit]];
     * **PHP**: [[https://climate.thephpleague.com/|Climate]];
@@ Line 75: / Line 91: @@
     * **Rust**: [[https://github.com/jeaye/ncurses-rs|ncurses-rs]] / [[https://github.com/gyscos/cursive|cursive]];
     * **C**: [[https://invisible-island.net/ncurses/|ncurses (the OG)]];
-  * Este recomandat ca programul de afișare să ruleze ca proces separat față de endpointul web (altfel vă veți confrunta cu probleme de sincronizare între threaduri în majoritatea limbajelor). Puteți face comunicarea între cele 2 procese prin orice mecanism vă pune Linux / limbajul la dispoziție (hint: tmp file system FTW);
+  * Puteți face comunicarea între cele 2 procese (program TUI + server HTTP) prin orice mecanism vă pune Linux / limbajul la dispoziție (unix pipes, sockeți, RPC framework al limbajului, sistem de fișiere -- însă aici veți avea de furcă la notificarea schimbărilor :P);
-  * Nu uitați să faceți acest program să pornească la startup (i.e., daemon sau serviciu de init) și să afișeze la consola ''tty0'' (e.g., să redirectați file descriptorii standard)!
+  * Acest program trebuie **OBLIGATORIU** să se numească ''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ă!
-  * Folosiți culori distincte pentru desenarea obiectelor pe planșă; și să scoateți cursorul...
+  * Cât despre design-ul pomului / elementelor afișate, aveți libertate deplină (cât timp se înțelege ce este și luminițele are câteva culori :D);
-  * Cât despre design-ul obiectelor, aveți libertate deplină (cât timp se înțelege ce este :D); fără obscenități, though (puteți să le faceți easter egg ;) )!
+=== Bonus task: GPIO ===
+Dorim să trimitem comenzile primite de serverul HTTP către instalația hardware de leduri.
+Astfel:
+  * Mașina de qemu dispune de un [[https://www.qemu.org/docs/master/system/arm/virt.html?highlight=pl061|controller de GPIO PL061]] pe care îl vom folosi să simulăm această interacțiune.
+  * Pe partea de Linux, aveți API de [[https://blog.lxsang.me/post/id/33|userspace pentru dispozitivele GPIO]] bazat pe sistemul de fișiere virtual ''/sys'' (API vechi) sau ''/dev'' + eventual, puteți găsi biblioteci în limbajul ales;
+  * Va trebui, însă, să [[https://docs.yoctoproject.org/kernel-dev/common.html|re-configurați kernelul Yocto]] și să activați driverul [[https://www.kernelconfig.io/config_gpio_pl061|PL061]] al dispozitivului GPIO emulat de qemu;
+  * Puteți folosi orice mapare grup / led la pini GPIO doriți, singura cerință este ca, la schimbarea stării (sau culorilor) acestora, și GPIO-urile asociate să-și modifice starea aferentă!
 === Contract (API) ===
-Sistemul va gestiona o serie de obiecte prezente pe planșa de detecție:
+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).
-  * 1 submarin (fix o instanță);
+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ă).
-  * animale acvatice (fish) - listă de maxim 5 obiecte;
-  * cel mult un artefact special (poate să lipsească, desigur);
+Fiecare grup are ca identificator unic (unde numerotarea începe de la ''1''!) este un vector de LED-uri (de dimensiune statică).
-Fiecare obiect are o poziție dată de ''x'' (coloana) și ''y'' (linia din terminal). Atenție: se folosește convenția lui ''ncurses'', adică sistemul de coordonate pornește cu ''(0, 0)'' din colțul stânga-sus al consolei!
+Valoarea fiecărui LED dintr-un grup va fi ID-ul numeric al culorii acestuia, folosind [[https://chrisyeh96.github.io/2020/03/28/terminal-colors.html|culorile clasice din terminal]]:
+  * ''0'' (//black//) (echivalent al LED-ului stins);
+  * ''1'' (<color red/black>//red//</color>);
+  * ''2'' (<color green/black>//green//</color>);
+  * ''3'' (<color yellow/black>//yellow//</color>);
+  * ''4'' (<color blue/black>//blue//</color>);
+  * ''5'' (<color magenta/black>//magenta//</color>);
+  * ''6'' (<color cyan/black>//cyan//</color>);
+  * ''7'' (<color white/black>//white//</color>);
 Astfel, se definesc următoarele endpointuri RESTful HTTP (atenție: API-ul este strict!):
-  * ''GET /api/submarine'': va returna un JSON cu poziția actuală a submarinului (e.g., ''{"x": 1, "y": 5}'');
+  * ''GET /api/groups'': va întoarce un obiect JSON cu proprietatea ''NG'' (numărul de grupuri disponibile), e.g.: ''{"NG": 3}'';
-  * ''POST /api/submarine/move'': va comanda submarinul să-și schimbe poziția cu un obiect delta. Formatul este JSON: ''{"x": deltaX, "y": deltaY}''); atenție: se pot primi și valori negative (e.g., ''{"x": -1}'' va muta submarinul la stânga 1 poziție);
+  * ''GET /api/group/<G>/leds'': va întoarce un obiect JSON cu lista actuală de culori ale LED-urilor grupului ''<G>'' (fără caracterele ''<>'', sunt doar pentru a denota o variabilă), e.g., ''[0, 0, 0, 1, 4, 2, 0, 0]'';
-  * ''GET /api/fish'': va returna un JSON cu lista actuală de pești detectați (e.g., ''[{"x": 10, "y": 3}, {"x": 20, "y": 10}]'');
+  * ''POST /api/group/<G>/static'': va primi o listă (''array JSON'') 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/fish/add'': va adăuga un nou pește la listă; format JSON: ''{"x": posX, "y": posY}''); atenție: dacă lista ajunge să aibe mai mult de 5 elemente, ștergeți-l pe cel mai vechi!
+  * ''POST /api/group/<G>/animate'': va primi o listă de liste 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: <code>
-  * ''GET /api/artifact'': va returna poziția artefactului curent (e.g., ''{"x": 10, "y": 3}'' sau ''{}'' dacă nu este definită);
+[
-  * ''POST /api/artifact/update'': înlocuiește poziția artefactului curent; format clasic: ''{"x": posX, "y": posY}'' sau ''{}'' (i.e., nici unul pe raza actuală de detecție);
+  [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],
+]
+</code>
 Toate cererile vor folosi formatul ''Content-Type: application/json'' atât la input (pentru cererile ''POST''), cât și la răspuns.
 <note important>
-Tema va fi testată în QEMU (v5.0+ sau v2.12+ pe Ubuntu 18.04) pentru placa ''versatilepb'' sau ''virt'' (pentru build-urile Yocto cu machine type ''qemuarm'').
+Tema va fi testată în QEMU (''v6.2+'' pe Ubuntu 22.04) pentru placa [[https://qemu.readthedocs.io/en/latest/system/arm/virt.html|virt]] (este deja tipul implicit pentru build-urile Yocto ale ''qemuarm'', cel folosit la laborator).
 </note>
-<note tip>
-Pentru ușurința navigării pachetelor puteți folosi interfața grafică //Toaster// pentru a construi imaginea. Puteți pleca de la imaginea de bază pentru RaspberryPi (''core-image-base'').
-</note>
 ===== Helpers + Mașină virtuală =====
-Ca și punct de pornire, puteți descărca un {{si:teme2021:si-tema2-skel.tar.gz|schelet inițial cu scripturi + structură recomandate}} (**v0.1**).
+Ca și punct de pornire, puteți descărca un {{si:teme2022:si-tema2-skel-TODO.tar.gz|schelet inițial cu scripturi + structură recomandată}} (**v0.1**).
 Aceasta conține:
   * script de make pentru generarea arhivelor cerute;
-  * script de rulare qemu recomandat;
+  * script de rulare qemu pe host (folosit pentru rularea directă a imaginii de distribuit, fără Yocto);
-  * script de configurat ''virbr0'' pentru qemu;
+  * un fișier descriptor pentru //kas// diferit de cel din laborator (numit ''tema2.yml'');
-  * un ''kas.yml'' de pornire;
+  * un script de testat endpointul RESTful (+ exemplu utilizare API) folosind python (''test.py'');
-  * un script de testat soluția folosind curl (''test.sh'');
+  * un README.skel pe care ar fi util să-l citiți ;)
-  * un README pe care ar fi util să-l citiți ;)
-  * un director gata creat ''tema2'' pentru layerul de Yocto custom, pentru a vă scuti de efortul unui ''mkdir'' în plus ;)
-  * alte fișiere ce trebuiesc completate și incluse în arhiva cu sursele!
   * **Important:** citiți codul sursă al scripturilor și verificați (e.g., căile) să fie adecvate setup-ului vostru!
-Dacă aveți setup-ul funcțional din cadrul laboratorului de Yocto, puteți să folosiți distribuția compilată de atunci. Atenție la ''kas.yml'' (dacă doriți să-l păstrați pe cel din laborator, să nu îl înlocuiți!).
+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).
-//Notă:// dacă optați pentru varianta cu VM-ul descărcat de mai jos, va trebui să adăugați manual scripturile și acolo (deoarece nu au fost incluse) + câteva ''apt install''-uri (//s-au uitat :D//).
+<note>
-<note>
-Pentru orice VM: dacă doriți să folosiți bridging cu interfața virtuală spre stația fizică, va trebui să activați Promiscuous Mode pentru adaptorul de rețea folosit (e.g., VMWare NAT / Bridge). Soluția pentru a face asta, din păcate, diferă în funcție de hipervizor / sistem de operare, deci Google-first apoi întrebați un asistent :D
 </note>
 <note>
-As always, se recomandă să folosiți ultima versiune de VMWare Workstation (dacă aveți nevoie de snapshot-uri) pe care îl puteți descărca cu [[https://vmware.pub.ro/|licență din partea facultății]] ;)
+Nu uitați să inspectați configurația de resurse a VM-ului (și să le ajustați pentru PC-ul vostru).
-</note>
+Compilarea unor pachete poate eșua dacă nu aveți suficient RAM (''8GB'' ar trebui să fie OK pentru majoritatea cazurilor).
-Dacă nu ați reușit să compilați Yocto la laborator, puteți folosi, ca punct de plecare, un **VM pus la dispoziție de noi (precizare: trebuie descărcat și rulat)**:
-  * [[http://rl-checker.root.sx/share/labsi-vm.zip|Link descărcare aici]] (''19GB'' arhiva, ''32GB'' decompresat!);
-  * spațiul ocupat în interiorul VM-ului este de ''25GB'', deci tot ce este ocupat acum ar fi suficient și în timpul compilării layere adiționale Yocto
-  * Autentificare pe VM: user ''student'', parolă ''student'';
-  * Fișierele Yocto (working directory-ul) le găsiți în ''/home/student/yocto''.
-  * Nu mai este necesar Docker, (aproape :D) toate utilitarele fiind instalate direct în VM!
-  * de asemenea, aveți creat un snapshot la VM cu starea lui inițială, folosiți dacă stricați ceva (NU UITAȚI să vă faceți backup la sursele soluției voastre înainte!).
-<note important>
-**Atenție**: unele utilitare de dezarhivare (mai ales pe Windows) folosesc director temporar pentru a decompresa imaginea mai întâi pe partiția unde e instalat OS-ul, așadar asigurați-vă că aveți suficient spațiu liber și acolo (apoi va fi mutat).
-Se recomandă folosirea unui SSD ca mediu de stocare al VM-ului (pentru viteză sporită).
 </note>
 ===== Trimitere =====
-Soluția temei va fi trimisă în două moduri:
+Soluția temei va fi trimisă în două moduri (vă rugăm să respectați convențiile de denumire cu exactitate!):
   * **arhivă cu codul sursă** + Readme + hash și alte metainformații (vedeți mai jos) -> pe Moodle
-  * **arhivă cu binarele rulabile** -> pe orice platformă de hosting doriți (ex: Dropbox, Google Drive, WeTransfer etc.)
+  * **arhivă cu binarele / imaginea rulabilă** -> le urcați pe [[https://ctipub-my.sharepoint.com|OneDrive / Sharepoint-ul UPB]] și dați share prin Link Public (pe care ni-l trimiteți doar nouă în fișierul ''url.txt'').
-    * link-ul trebuie să fie valid min. 5 zile din momentul expirării deadline-ului hard; dacă uploadați mai devreme de deadline și, vă rugăm, notificați-ne în acest sens (să descărcăm înainte să dispară);
 **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-*'': imaginile kernel-ului compatibil cu QEMU (scheletul îl folosește pe cel din Yocto);
+  * ''kernel-*'': binarul kernel-ului compatibil cu QEMU (scheletul îl copiază automat din cache-ul Yocto);
   * ''versatile-pb.dtb'' sau orice alt device tree blob (dacă sunt necesare pentru rulare în Qemu);
   * ''launch.sh'': script de pornire QEMU (vedeți scheletul dat);
-  * Dacă doriți să ne prezentați alt scenariu demonstrativ (decât cel inclus în schelet), includeți un script numit ''test.sh''.
+  * Dacă doriți să ne prezentați alt scenariu demonstrativ (decât cel inclus în schelet), includeți un script numit ''test.py''.
   * **NU INCLUDEȚI**: directorul build cache al yocto (yep, acela de > 20GB!);
   * Această arhivă nu ar trebui să depășească ''500MB'' (și asta în cazuri extreme).
 **Arhiva cu fișierele sursă** (''.zip'' pls) este OBLIGATORIU să conțină:
-  * scripturile proprii de Yocto (layer, rețete, configurații) + sursele aplicației (în orice limbaje ați ales);
+  * scripturile proprii de Yocto (layer, rețete, fișier ''yml'' pentru ''kas'') + sursele aplicației (în orice limbaje ați ales);
-  * fișier ''README'' cu explicații referitoare la funcționarea soluției, opțiuni speciale de configurare/optimizare folosite etc.
+  * fișier ''README.txt'' cu explicații referitoare la funcționarea soluției, configurații speciale de optimizare folosite etc.
-  * fișier ''URL'' (fără extensie!) cu URL către arhiva **.tar.gz** a binarelor;
+  * fișier ''url.txt'' (fără extensie!) cu URL către arhiva **.tar.gz** a binarelor;
-  * fișier ''CHECKSUM'' (fără extensie!) 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ă!
+  * fișier ''checksum.txt'' (fără extensie!) 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ă!
   * **NU INCLUDEȚI**: fișiere sursă ale Poky / alte layere Yocto / biblioteci / frameworkuri descărcabile de pe Internet (menționați în Readme ce ați folosit); puteți include bblayers.conf și local.conf dacă le-ați modificat manual (în afara ''kas'').
   * Această arhivă nu ar trebui să depășească ''1MB'' (aveți restricție pe Moodle).
 <note>
-Un Makefile pentru generarea arhivelor este prezent și în arhiva cu scheletul inițial recomandat al temei, însă se recomandă verificarea manuală a arhivelor!
+Folosiți Makefile-ul din scheletul temei pentru generarea acestor două arhive, însă este recomandată verificarea manuală a arhivelor după generare!
 </note>
 <note warning>
-Nu vor fi punctate temele care nu au hash-ul SHA256 al arhivei încărcat pe Moodle sau cele al căror hash nu corespunde cu arhiva downloadată de pe platforma de hosting la momentul corectării!
+Nu vor fi punctate temele care nu au hash-ul SHA256 al arhivei încărcat pe Moodle sau cele al căror hash nu corespunde cu arhiva downloadată de pe platforma de hosting la momentul corectării (este folosit și pentru a verifica upload-ul după deadline)!
 </note>
@@ Line 184: / Line 206: @@
   * (30p) Imaginea și funcționalitățile de bază (trebuie să ruleze în qemu!);
   * (30p) Endpoindul web RESTful așa cum este el descris mai sus (API-ul este strict!);
-  * (30p) Daemon-ul care randează ASCII art-ul cerut la consola tty;
+  * (30p) Programul care randează ASCII art-ul cerut la consolă;
   * (10p) Readme scris clar și care descrie complet arhitectura și implementarea funcționalităților cerute.
 Bonus:
-  * (10p) Optimizări deosebite de spațiu ale imaginii finale (cele mai mici 5 imagini primite, doar dintre cele care implementează toate funcționalitățile);
+  * (10p) GPIO writing (necesar să compilați driverul ''PL061'' în kernel);
-  * (5-10p) Extra features / good practice (design plăcut, eleganță în implementare etc.);
+  * (10p) Optimizări deosebite de spațiu ale imaginii finale (cele mai mici 10 imagini primite, însă doar dintre cele care implementează toate task-urile!);
+<note important>
+Soluțiile care nu au folosit Yocto sau nu rulează deloc (cu excepția unor greșeli minore) nu vor fi punctate!
+</note>
 ===== Precizări =====
   * Tema are deadline **HARD** (nu mai sunt admise soluții după expirare), așadar se recomandă să vă apucați din timp de rezolvarea acesteia!
-  * Compilarea unei imagini cu Yocto necesită 40GB+ spațiu liber pe disk;
-  * Prima compilare poate dura intre 0.5 si 10 ore în funcție de performanța calculatorului (procesor + I/O) + viteza rețelei (un SSD ajută enorm!);
-  * Compilările ulterioare vor refolosi majoritatea pachetelor generate (cache) și vor dura mult mai puțin (1 - 30min, depinde de ce layere noi se adaugă în plus);
   * :!: **ATENȚIE**: orice formă de plagiat nu va fi permisă și va duce la depunctare totală / restanță / //that which must not be named, the E-word//!
-  * Pe Moodle găsiți și [[https://curs.upb.ro/2021/mod/forum/view.php?id=128348|un forum]] ;) La fel pe Teams, avem un canal de discuții.
+  * Pe Moodle găsiți și [[TODO|un forum]] ;) La fel pe Teams, avem un canal de discuții.
 ===== Resurse =====
-  * [[:si:laboratoare:08]]
+  * [[:si:laboratoare:06]]
-  * [[:si:laboratoare:03]]
+  * [[:si:laboratoare:07]]
-  * [[https://asciinema.org/a/0X4OCmcTyjTCvvOd1kHDepGz7|Exemplu de interacțiune (asciinema)]]
+  * [[https://asciinema.org/a/TODO|Exemplu de interacțiune (asciinema)]]
+</ifauth>

Administrativ

Catalog

Cursuri

Laboratoare

Teme

Tema 2 - GPS Tracker (2024)

IoT Summer School

Resurse

Yocto extended content

Arhiva

si/teme2021/tema2.1639596669.txt.gz · Last modified: 2021/12/15 21:31 by florin.stancu

Show page Old revisions

Media Manager Back to top