Warning
This page is located in archive. Go to the latest version of this course pages. Go the latest version of this page.

Semestrální úloha

The English version of the semestral assignment is available in the English subject pages structure (there).

Link: Nápověda k práci s přípravkem MicroZed APO, Dokumentace přípravku MicroZed APO, MZAPO connection cookbook

Pokročilejší verze zadání zaměřená na řízení stejnosměrného motoru (emocon)

Deadline

  • Odevzdání úlohy je možné až do jednoho týdne po zápočtovém týdnu. Vzhledem k přechodu na distanční formu je v BRUTE zadaný termín 30.5.2021. Do tohoto termínu nebudeme strhávat body za zpoždění. Začněte ale na práci pracovat co nejdříve, většina kolegů externistů svolila k prodloužení své účasti na konzultacích do konce května. Vzhledem ke státním zkouškám, projektům, vedení DP a BP a dalšímu ani my z FEL (Pavel Píša a doktor Petr Štěpán) nemusíme mít v červnu na vás čas. 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ě.
  • Za každý další započatý týden -10 bodů.

Odevzdání

  • Úloha je určená pro dvojice studentů bez rozdílu pro studijní program OI i KyR, ale může ji řešit také samostatně.
  • Zdrojové kódy v archivu (zip) nahrajte na https://cw.felk.cvut.cz/brute/ (úkol SEMCODE)
  • Dokumentaci (uživatelský manuál a technickou zprávu) v archivu do SEMDOC na Brute.

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.

Zadání, úkoly práce

Vzhledem k přechodu na distanční formu je finální podoba v jednání a záleží i na názorech studentů. Většina požadavků je a bude volená tak, aby bylo možné práci odladit na simulátoru QtMips a i odevzdat ve verzi pouze pro QtMips (i ve verzi pro QtMips je možné získat plné bodové ohodnocení).

Limitní podmínky, které jsou již dané.

  • Výstup na RGB diody a řádku LED (podpora na QtMips i MZ_APO, lze i bez obtíží zkontrolovat kamerou, POVINNÉ)
  • Výstup textu na grafický display/frame-buffer (podpora na QtMips i MZ_APO, kontrola kamerou asi ne v plném rozlišení, POVINNÉ)
  • Výstup na sériový port nebo standardní výstup - spíš jen pro ladění (podpora na QtMips i MZ_APO obojího)
  • Vstup otočných voličů, při odevzdání z QtMips povinný, pro MZ_APO není možná fyzická interakce/ladění, takže nemá moc smysl
  • Audio výstup, komunikace CAN, TCP/IP atd… k dispozici na MZ_APO, ale spíš příliš náročné, v individuálních zadáních možné
  • Řízení DC motoru, dobrá náhrada inkrementálního vstupu otočných voličů (IRC), kdy řízením napětí lze mechanicky motorem točit a IRC nastavovat (zatím podpora jen na MZ_APO, ale uvažuji o doprogramování zobrazení a dynamiky DC motorku do QtMips)

Inspirace a příklady pro zadání

  • klasická hra hadi (viz Wikipedie EN, CZ) - QtMips nebo MZ_APO (zde při distanční formě dva hadi s umělou “inteligencí” v demo režimu plus režim ovládat alespoň jednoho znaky přes SSH), ve standardní variantě dva hadi, směr jedné hlavy ovládaný červeným voličem a znaky 'a' a 's' ve vstupu sériového portu, druhé hlavy modrým voličem a znaky 'k' a 'l'. Délka hada a čas bude zobrazeny ve formě výpisu textu (návěští + číslo) , levá a pravá RGB led informují o dobré kondici příslušného prvního a druhého hada, zelená, polknutí modrá a nárazu s důsledkem smrti červené. Na plný počet bodů i grafické menu s volbou parametrů - rychlosti atd.
  • zvětšovací lupa (xmag − magnify parts of the screen) - na display je vypsaný delší text na několik řádek (ideálně zadávaný ze souboru, i QtMips syscally umí, i když bez úpravy C knihovny je bude asi nutné volat ručně), dvěma voliči se bude nastavovat poloha okénka na obrazovce, jehož obsah se zvětší, buď nad vybraným místem nebo na pevné pozici, na MZ_APO v případě distanční formy bude vybíraná pozice postupně po řádcích odshora dolů přecházet tak, aby i na videu byl text alespoň trochu čitelný, LED diody budou například indikovat přecházení mezi řádky, v případě volitelného zvětšení pak například míru zvětšení
  • elektronická verze Grafo - při distanční formě jen pro QtMips, povinný textový výpis polohy a vybrané barvy, volba barvy z nabídky, vybraná barva i na jedné z RGB LED.
  • řízení a monitoring výrobní linky
  • řízení pohonu robota atd…
  • vlastní fantazie a nápady vítané.

Rámcové hodnocení práce

  • včasné zadání/založení týmu (1 bod v semassign)
  • základní funkce s HW, alespoň tři různé periferie (3 body)
    • výstup na RGB diody
    • výstup na řádku LED
    • Výstup na sériový port
    • Vstup otočných voličů
    • 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í (QtMips)
    • implementace systémového volání (obsluha/zpracování výjimky)
  • výstup textu na grafický display/frame-buffer
    • výpis fontu (1 bod)
    • výpis s proměnnou šířkou znaku (1 bod)
    • čárová grafika nebo menu (1 bod)
  • splnění zadání (5 bodů)
  • kvalita provedení (5 bodů)
    • konzistentní odsazování
    • 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)
    • rozdělení do souborů - C soubor by 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í (3 body)
  • dokumentace - povinná, bez ní nelze práci hodnotit jako splněnou
    • architektura aplikace - blokové schéma (1 bod)
    • dohledatelnost, která funkce patří do kterého bloku (1 bod)
    • manuál, který umožní plně použít i bez zaškolení (1 bod)
    • popis kompilace, instalace, spuštění (1 bod)
  • vedení projektu ve verzovacím systému git (nepovinné - za bonusové body)
    • repozitář existuje a nejsou v něm generované soubory, když projekt odevzdává dvojice, tak commity od obou (1 bonus bod)
    • smysluplně pojmenované commity (commit message odpovídá provedeným změnám) (1 bonus bod)
    • každý commit by také měl ideálně upravovat/přidávat pouze jednu ucelenou funkcionalitu
    • 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íce info v návodu. (1 bonus bod)

Pokračuje zadání z loňského roku pro inspiraci.

Distribuované řízení osvětlení

Úkol: Naprogramujte řídicí jednotku Microzed, viz následující obrázek, jako ovládací prvek dvou reflektorů.

Dvojice RGB LED diod, pojmenovaných jako LED1 a LED2, se nachází na obrázku v dolní čtvrtině a zastupuje oba reflektory. Zadávání vstupních parametrů provádějte pomocí tří otočných ovladačů označených na plošném spoji ENCODER1, ENCODER2 a ENCODER3.

Nutné podmínky zadání

  • Volba odstínu barvy světla reflektoru se vždy provádí v barevném modelu HSV/HSB, viz http://colorizer.org/. Vezměte přitom v úvahu, že RGB-LED nedokáže rozlišit plnou škálu barev jako displeje, ale v závislosti na svém jasu zobrazí od 256 (krajní úrovně) až do 1024 (střední jasové úrovně). Volte úměrně tomu kroky změn . Na webu pak najdete řadu C programů pro převod z HSV na RGB.
  • K řešení je také přiložený technický manuál, který popisuje ovládání. Stačí jedna stránka v PDF.

Bodované podmínky zadání

Řešení je rozdělené na bodované kategorie, jejichž hodnoty se sčítají.


2 až 8 bodů – Přehlednost ovládání a výstup na displej

3 - LCD displej ukazuje názorně vybraný režim a okamžité nastavení obou reflektorů. Volba se mění ovladači.

6 – LCD displej ukazuje nejen režim a nastavení, ale vypisuje i přehledné textové menu, v němž lze volit jednotlivé funkce.

8 – Totéž jako v předchozím bodě, ale na displeji lze nastavit nejen normální písmo, ale i dvojnásobně zvětšené, aby ho i osoby s horším zrakem dokázaly dobře číst. (Soubory s dalšími definicemi fontů v různé velkosti naleznete v adresáři /opt/apo/lcd/fonts)


1 až 7 bodů – světelné efekty

Ke svícení se přidávají efekty, jejichž bodové hodnocení se sčítá. Jednotka si musí pamatovat předchozí efekty, tj. po nastavení jiného efektu se lze vrátit k předchozím, aniž by se znovu musely zadávat jeho hodnoty. Pokud efekt běží, lze měnit jeho hodnoty bez nutnosti ho přerušit, takže je okamžitě vidět výsledek.

1 – základní bod - statické svícení, jehož barva se volí ve třech režimech. Každý reflektor lze nastavit:

  a) Individuálně – nastavuje se jen vybraný reflektor a druhý se nemění.
  b) Společně – mění se oba současně.
  c) Kopie – reflektor převezme nastavení od toho druhého.
  

+2 – soustavná plynulá proměna barev – reflektor plynule přechází mezi dvojicí barev po dráze v HSV modelu. Opět lze navolit tento efekt jen „Individuálně“ u jednoho reflektoru, či „Společný“ u obou, nebo u obou v protifázi. Doba změny se dá nastavit stejně jako koncové barvy.

+2 – svícení o nastavené statické či proměnlivé barvě lze přerušovat s třemi nezávisle volitelnými časy doby trvalého svícení, doby zhasnutí a fázového posunu jednoho reflektoru vůči druhému.

  a) Individuálně – blikání se nastavuje jen u vybraného reflektoru a druhý se nemění.
  b) Společně – u obou reflektorů se nastavuje současně.
  c) Posun fáze – u jednoho reflektoru lze časově posunout fázi nastaveného blikání.
  

+2 - Nastavení světelného hada na řádce LED diod


4 body – Ovládání reflektorů přes Ethernet

Poslední bod bude velmi náročný a není nutné ho řešit pro pouhé získání zápočtu.

Zadání: Jednotka je nejen schopná řídit své reflektory, ale také se napojit na další jednotku a ovládat ji. Musí si tedy zjistit její IP adresu a té posílat povely přes síťové pakety. Navrhněte si vhodné protokoly a i způsob komunikace. Měli byste detekovat existenci druhé jednotky a pak se na ni kdykoliv napojit a poté se zase odpojit. Chcete-li A bez zkoušky, dokažte nám, že jste C-znalci a APO-písemka by Vás jedině zdržovala od učení na jiné zkoušky.


5 bodů – Kvalita provedení

Logické pojmenování funkcí, lokálních a globálních funkcí na základě anglické terminologie. Odsazování, rozdělení do souborů podle příslušnosti k subsystémům a další.

Počáteční šablona pro tvorbu aplikace

Šablonu aplikace najdete na počítačích v laboratoři v adresáři

/opt/apo/mzapo_template

Další šablony, pro další platformy např. QtMips, naleznete na https://gitlab.fel.cvut.cz/b35apo/stud-support v adresari seminaries/binrep

Výhodnější je však šablonu nahrát z verzovacího systému a založit si poté pro projekt vlastní repozitář (viz stránka z dokumentace)

git clone https://gitlab.fel.cvut.cz/b35apo/mzapo_template.git

Součástí šablony jsou následující soubory

  • Makefile - pravidla pro sestavení a vzdálené spouštění aplikace
  • change_me.c - zdrojový kód s hlavní funkcí main - šablona určená k přejmenování
  • font_prop14x16.c - proporcionální font s maximální šířkou 14 a výškou 16 bodu
  • font_rom8x16.c - font s fixní šířkou
  • font_types.h - definice typu použitého pro popis fontu
  • mzapo_parlcd.h - deklarace funkcí pro nízkoúrovňový přístup k LCD display
  • mzapo_parlcd.c - implementace funkcí pro nízkoúrovňový přístup k LCD display
  • mzapo_phys.h - deklarace funkce pro mapování fyzického rozsahu adres do aplikačního procesu
  • mzapo_phys.c - implementace funkce pro mapování fyzického rozsahu adres do aplikačního procesu
  • mzapo_regs.h - definice bázových adres a registrů výukového návrhu MZ_APO

Podrobnější popis registrů návrhu lze nalézt v dokumentaci desky MZ_APO.

Pravidla Makefile pro sestavovací program je potřeba upravit pro vlastní aplikaci. Aplikace se bude skládat z jednoho nebo více zdrojových souborů v jazyce C (soubory s příponou *.c) a nebo v jazyce C++ (soubory s příponou *.cpp). Příkladem s hlavní funkci main je vzorový soubor change_me.c, který by měl být nahrazen, přejmenován za soubor specifický pro danou aplikaci.

Do proměnné SOURCES je nastaven seznam zdrojových souborů, viz následující část souboru Makefile

SOURCES = change_me.c mzapo_phys.c mzapo_parlcd.c
#SOURCES += font_prop14x16.c font_rom8x16.c

V první řádce je potřeba upravit jméno hlavního souboru aplikace. Pokud jsou využité fonty, je potřeba druhou řádku odkomentovat. Do seznamu je možné na těchto dvou řádkách nebo opakováním řádku s plus-rovná-se přidat i další potřebné soubory. Hlavičkové soubory (*.h) se do seznamu neuvádí.

Jméno žádaného binárního spustitelného souboru je nastavené v do proměnné TARGET_EXE.

Překlad je proveden prostým zavoláním sestavovacího programu

make

kdy je vyvoláno první nalezené pravidlo all.

Pro smazání generovaných souborů (objektové soubory, binární kód aplikace a automaticky generované závislosti) slouží cíl clean. Cíle lze i kombinovat

make clean all

Případná kompilace při změně a spuštění aplikace na vzdálené jednotce je provedeno při vyvolání cíle run

make TARGET_IP=192.168.202.xx run

Automatické přihlášení, přenos dat a spuštění aplikace na cílovém zařízení s danou IP adresou vyžaduje již zavedený privátní klíč v SSH agentovi pro dané sezení

ssh-add /opt/apo/zynq/ssh-connect/mzapo-root-key

Aplikace je nejdříve překopírovaná do podadresáře /tmp vytvořeného podle přihlašovacího jména uživatele a poté je aplikace spuštěné s tím, že standardní vstup i výstup je k dispozici na straně vývojářského počítače přes SSH spojení.

Aplikaci je možné na cílové platformě i ladit s využitím grafického ladícího programu Data Display Debugger

make TARGET_IP=192.168.202.xx debug

Soubory jsou dostupné i v GitLab FEL přes ssh (nutný nahraný public key):
git@gitlab.fel.cvut.cz:b35apo/mzapo_template.git

Případně přes https:

https://gitlab.fel.cvut.cz/b35apo/mzapo_template.git

Klíč pro přístup k vývojovému kitu je možné v prostředí Xfce aktivovat automaticky po přihlášení v nastavení automaticky spouštěných aplikací Setting manager > Session and startup > Application Autostart (Nastavení > Správce nastavení > Relace a spouštění > Automatický start aplikace). Přidejte položku, název vyplňte například na ssh-mz_apo, přidejte popis a příkaz
ssh-add /opt/zynq/ssh-connect/mzapo-root-key

Požadavky na odevzdání semestrální práce

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.

Před odevzdáním si zkontrolujte, že program lze kompletně sestavit z připraveného archivu.

change_me

Odevzdání projektu, který generuje spustitelný soubor se jménem change_me bude u zákazníka/cvičícího vyvolávat zásadní nedůvěru v kvalitu projektu. 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.

Příloha: Nespojovaná/datagramová komunikace v síti s protokolem IP (Internet Protokol)

V současné době je protokol IP (Internet Protokol) nejrozšířenějším standardem pro komunikaci mezi počítači a zařízeními. Protokol je protokolem vyšší vrstvy na úrovni paketů, datagramů a spojení. Pro realizaci vlastního přenosu rámců po lokálních sítích se používá řada technologií, asi nejrozšířenější je technologie ETHERNET, která ve své základní podobě rámců ale neřeší přenos rámců mezi více sítěmi.

Obě technologie se tedy velmi dobře doplňují. Protokol IP existuje ve dvou verzích IPv4, který používá pro identifikaci rozhraní každého počítače ve světové síti 32-bitovou adresu. Postupně se pak přechází na novou verzi protokolu IPv6, který používá 128-bitové adresy s lépe propracovanými pravidly pro přiřazování a komunikaci.

Pro práci na semestrální úloze se předpokládá použití jednodušší verze IPv4. Nad základní síťovou vrstvou je definované množství dalších protokolů specializovaných pro rozdílné potřeby komunikace různých aplikací a druhů přenosu. Asi nejznámější je protokol TCP, který slouží pro zajištění zabezpečeného spojení s kompletním mechanizmem potvrzování přijetí dat. Proud dat je v případě ztráty paketu pozastavený a je zajištěné opětovné poslání nedoručených dat. protokol se používá například pro nejrozšířenější transportní aplikační protokoly a služby HTTP, HTTPS a SSH. Protokol TCP však není vhodný pro paralelní doručování zpráv se všeobecnou cílovou adresou všem účastníkům v rámci lokální sítě (Broadcast).

Aby bylo možné jednoduše vytvářet seznam všech připojených jednotek, bude se v rámci semstrální aplikace používat nezabezpečený, nespojovaný, datagramový protokol UDP. Tato volba umožňuje vysílat informaci o stavu jednotky do lokální sítě bez definování adresy určení. Takovéto zprávy pak mohou přijímat všechny jednotky na lokální síti.

Příklad jednoduchého programu v roli serveru a druhého v klienta lze nalézt například v návodu Beej's Guide to Network Programming.

Podrobnější how-to pro práci se sockety naleznete na stránkách bývalého předmětu X35POS v cvičení 4.

Hlavičkové soubory pro programy v jazyce C, které zpřístupňují soketové služby na systémech splňujících normu POSIX

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <unistd.h>
#include <sys/select.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

Program, který přistupuje k těmto službám, musí nejdříve založit síťový socket

   int sockfd;

   if ((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
        perror("socket");
        exit(1);
    }

Volba AF_INET specifikuje adresní rodinu IPv4, SOCK_DGRAM pak volí nespojovanou službu UDP. Více o volání socket v Beej's Guide nebo v dokumentaci GNU C knihovny použité na systému GNU/Linux.

Volba lokálního portu, na kterém poté aplikace naslouchá a který je použitý spolu s IP adresou odchozího rozhraní počítače/jednotky se volí voláním bind (GNU).

Příklad jednoduchého zavázání IPv4 socketu na všechna lokální rozhraní. Port MY_PORT je 16-ti bitové číslo v rozsahu 0 až 65535. Síťové adresy jsou ukládané v paměťových strukturách již v síťovém pořadí bajtů, proto je potřeba převést interní (h = host) pořadí na síťové (n = network) pořadí bajtů. Porty v rozsahu 1 až 1000 jsou pak rezervované pro privilegované služby, mohou je používat jen programy s právy administrátora nebo přímého přístupu k síti.

  struct sockaddr_in bindaddr;

  memset(&bindaddr, 0, sizeof(bindaddr));
  bindaddr.sin_family = AF_INET;
  bindaddr.sin_port = htons(MY_PORT);
  bindaddr.sin_addr.s_addr = INADDR_ANY;

  if (bind(sockfd, (struct sockaddr *)&bindaddr, sizeof(bindaddr)) == -1) {
    perror("bind");
    exit(1);
  }

Systém však po ukončení služby na určitém portu ještě po určitou dobu znovuvyužití portu rezervuje/blokuje, aby zpožděné, nezpracované příchozí pakety nekolidovaly s nově spuštěnou službou/programem. Proto je vhodné před voláním bind() odmítnout tuto blokaci pro službu, která musí běžet na pevném čísle portu.

  int yes=1;

  if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &yes,
                sizeof(yes)) == -1) {
    perror("setsockopt (SO_REUSEADDR)");
    exit(1);
  }

Protože by mohlo dojít k rozesílání datagramům všem jednotkám na lokální síti omylem, musí být tato volba povolena

    int broadcast = 1;

    if (setsockopt(sockfd, SOL_SOCKET, SO_BROADCAST, &broadcast,
        sizeof broadcast) == -1) {
        perror("setsockopt (SO_BROADCAST)");
        exit(1);
    }

Dále je již možné k zasílání zpráv využít volání sendto a recvfrom.

IPv4 adresu pro hromadné rozeslání zprávy na všechny uzly v lokální síti je možné nastavit

  struct sockaddr_in braddr;

  memset(&braddr, 0, sizeof(braddr));
  braddr.sin_family = AF_INET;
  braddr.sin_port = htons(HELLO_SERVICE_PORT);
  braddr.sin_addr.s_addr = INADDR_BROADCAST;

courses/b35apo/semestral/start.txt · Last modified: 2021/05/24 21:50 by stepan