Per qualsiasi dubbio contattateci, senza farvi problemi.

matr	RM come	predic	exec	sched	tot	prog	overall	finale
	test	     	EDF	RM	teor
827016  26	28	12	14	20.00	26	23.00	23
852002	32	24	30	32	29.50	24	26.75	27
852331	28	28	26	30	28.75	28	28.38	28
856608	32	33	27	30	30.50	29	29.75	30

commento su RM come test

  • 827016: insomma... 26
  • 852002: ok. 32
  • 852331: commenti ok, ma privi di critica all'intervento proposto. 28
  • 856608: buono. 32

aspetti che danno non - predicibilità

  • 827016: alcuni commenti ok, alcune inesattezze (minor). 28
  • 852002: insomma, davvero un po' scarno... 24
  • 852331: un po'scarno, ma ok. 28
  • 856608: ok. 33

exec schedule EDF

  • 827016: no, errore grave ripetuto. 12
  • 852002: ok. 30
  • 852331: arriva fino a 30 nella simulazione e quindi non scopre nella simulazione che non è schedulabile: la simulazione fatta è ok: in un altro pezzo di soluzione in risposta ad altro questito trova che non è schedulabile con test su fattore utilizzo. 26
  • 856608: spiegazione scarna, ma ok. 27

schedulabilità RM

  • 827016: no, usa test di EDF. 14
  • 852002: ok. 32
  • 852331: usa solo test liu-leylans, ma ok. 30
  • 856608: solo iperbolico, ok. 30

progettino

  • 827016: Buongiorno a tutti e scusate per il ritardo. Ho controllato i vostri elaborati, e dal momento che avete svolto insieme il lavoro, e che non mi sembra che ci siano differenze troppo significative in quello che avete consegnato, mi sentirei di dare lo stesso voto ad entrambi. Seguono un po’ di commenti sull’elaborato.
    La struttura dei task mi sembra buona, ed usate i lock al posto giusto. Sullo scheduling diversi task hanno le stesse frequenze/priorità, quindi non è proprio un rate monotonic da manuale (mi sembra che FreeRTOS usi round robin se ha più task con la stessa priorità, e non so come questo abbia impatto sulla schedulabilità). Non vedo inoltre come avete effettivamente calcolato i WCET dei task: dite che avete tenuto conto dei tempi di comunicazione, ma non trovo dei conti espliciti.
    Riguardo alla stesura codice ci sono dei punti in cui usate delle acquisizioni nidificate dei lock, che possono portare ai deadlock. Siete stati abbastanza accorti da non creare circolarità, quindi deadlock non ce ne sono, ma il codice poteva tranquillamente essere scritto acquisendo un lock alla volta.
    Riguardo al funzionamento, il codice compila senza errori e stampa dei valori sulla UART come deve fare, ma mentre le letture dell’accelerometro sembrano a posto quelle del giroscopio e del magnetometro non cambiano valore quando muovo il dispositivo (e non è un problema dello shield, ho provato con due shield diversi).
    In sintesi, il voto che mi sentirei di darvi è 26.
Ultime modifiche: venerdì, 15 dicembre 2023, 12:08