Skip to content
Snippets Groups Projects

Changes

Page history
  • New page
  • Templates
    • Cleanup broken links, unused pages, outdated stuff authored by Alvise de'Faveri's avatar Alvise de'Faveri
    Show whitespace changes
    Inline Side-by-side
    Showing
    with 81 additions and 133 deletions
    Alain-Random-Stuff.md
    View page @ 0bccb1e7
    ### Debug
    Secondo me il modo migliore e fare una serie di macro in stile
    ```cpp
    #ifndef NDEBUG
    #define DEB(x) x
    #else
    #define DEB(x)
    #endif
    ```
    da usare con `DEB(printf("..."))`
    O comunque usare questo metodo per usare il logger (come scritto ieri su slack)
    oppure per le assert. Tra l'altro son quasi sicuro che le assert non vengono
    compilate se si usa -DNDEBUG.
    Il problema di questo approccio e' che bisogna ricordarsi di non fare mai
    init dentro le assert:
    ```cpp
    assert( init_blabla(...) == true ); // non viene invocata init_blabla
    // se NDEBUG e' definito.
    ```
    ----------------------------
    ### Logger
    Per il logger, date un'occhiata [Log.cpp](https://the.al/share/_/pqyewIt6b4r.txt) e [Log.h](https://the.al/share/_/pWoTjUhaN.txt).
    ......@@ -42,15 +13,15 @@ l'overload per altre classi... si può sempre creare un metodo toString() :P)
    Ultimo pro, LOG_DEBUG(), LOG_INFO(), ... son piu' veloce da scrivere rispetto a
    Logger::Logger::Antani\<Antani::lol::blabla\>().
    --------------------------------------------------------------
    ---
    ### Event scheduler
    L'event scheduler è per driver o cose da temporizzare.
    Alcune cose da ricordare a riguardo sono:
    1) Chi esegue il codice quando scatta l'evento? Attualmente il codice
    1. Chi esegue il codice quando scatta l'evento? Attualmente il codice
    viene eseguito (se non erro) nel thread dell'event scheduler.
    - Questo implica che se il codice va il loop o ci mette troppo, tutti
    ......@@ -61,13 +32,14 @@ Logger::Logger::Antani\<Antani::lol::blabla\>().
    modo che ogni task ha una proprietà che specifica dove essere
    eseguito.
    2) L'SPI/I2C/DMA è uno solo, facendo andare più event scheduler in
    2. L'SPI/I2C/DMA è uno solo, facendo andare più event scheduler in
    parallelo la gestione dell'hw inizia ad essere più tricky.
    In teoria dei mutex ben piazzati sistemano tutto, ma in caso di
    stallo di uno si rischia il blocco di tutti. Diciamo che è
    fattibile ma bisogna pensarci un po' su.
    ------------------------------------------------------------
    ---
    ### SBS Fault Headers
    Il generate fault header è perche volevamo dichiarare tutti i possibili
    ......@@ -76,7 +48,8 @@ terra. Poi da quelli generiamo il .h contenente la lista degli attuali.
    e.. a fare il lavoro 2 volte (ground e razzo) finiamo che ci dimentichiamo
    qualcosa e ci son inconsistenze
    ------------------------------------------------------------------------------
    ---
    ### Cos'è --gen-faults di sbs? Cos'e data/fault.csv?
    Per evitare inconsistenze, abbiamo fatto un csv con tutti i fault counters,
    ......@@ -89,8 +62,9 @@ che viene impostata e non viene piu toccata se è gia scritta, questo implica
    che se non vi piace un nome generato lo potete cambiare (todo: da verificare
    se ho fatto veramente cosi lol)
    ------------------------------------------------------------------------------
    ### Lincenza
    ---
    ### Licenza
    C'è un po' una battaglia interna (:P) sulla licenza da usare.
    Io tutt'ora spingo per usare MIT in ogni nostro file, in modo che se in futuro
    ......@@ -107,42 +81,8 @@ lì.
    Ditemi cosa ne pensate.
    ------------------------------------------------------------------------------
    ### Come funziona sbs e cos'e config/
    Per usare un progetto miosix (senza sbs e simili) serve prendere miosix/config
    metterla nella root assieme al makefile, decommentare alcune cose e poi lanciare
    'make'.
    ---
    Ora, dato che il miosix che usiamo noi ha qualche modifica in più, in passato
    avevamo anche modifiche alla cartella config/, e questa è stata messa nella
    root del nostro progetto, ma senza decommentare una board in particolare.
    Quello che fa sbs e di avere un Makefile.template, che è simile al Makefile
    di miosix (della root), sostituire le cose giuste al posto giusto (usando
    placeholders), mettere il makefile "compilato" dentro build e lanciarlo.
    Questo per ogni "board" definita in sbs.
    Ad oggi ci stiamo sempre più avvicinando ad usare miosix originale, quindi in
    futuro si potrebbe pensare di non mettere piu li config/ ma usare
    direttamente quella in libs/miosix-kernel/miosix/config.
    ------------------------------------------------------------------------------
    ### Cosa manca in miosix mainline?
    (Se non erro) Manca solo da mettere in mainline il fatto che per ogni board
    devo compilare i file oggetto in obj/$nomeboard/... e idem per i binari.
    (mi sa che per i binari manca tutt'oggi, e infatti e per questo che ogni
    volta che viene lanciato ./sbs -v anche con tutto compilato, si vede che fa
    ancora un briciolo di lavoro).
    Btw, il fatto che miosix mette obj/binari di board diverse dentro le stesse
    cartelle mi fa aver paura di bug strani che possono accadere dove per
    qualche errore (che spero non avvenga mai!) viene linkato un file compilato
    per un'arch nel binario di un'altra arch. O comunque, stessa architettura
    ma in un eseguibile ci son alcune "define" definite, in altri no. ecc.
    ------------------------------------------------------------------------------
    ### BusTemplate aka Il Demonio
    (scusate la confusione, l'ultima volta che ho letto BusTemplate e stato 1 anno fa)
    ......@@ -154,9 +94,11 @@ in una scheda diversa e magari attraverso i2c invece di spi.
    Vediamo se riesco a spiegarmi velocemente con un esempio inventato..
    Un driver viene inizializato così:
    ```C++
    DriverMAX12345<ProtocolSPI<BusSPI<1,..>>> blaa;
    ```
    dove DriverMax12345 chiama metodi WriteReg/ReadReg di ProtocolSPI
    e ProtocolSPI chiama metodi Write/Read di BusSPI1.
    ......@@ -174,6 +116,7 @@ a silvano/teo_piaz per più dettagli perche non li ricordo tutti.
    Un errore (+ soluzione) che ricordo è stato fatto (se non erro) è che
    ProtocolSPI si occupa di 2 cose:
    - Ordine di Pin da muovere
    - Differenze a livello di bit da mandare per read/write.
    ......@@ -184,6 +127,7 @@ vanificando completamente il 99% del codice di ProtocolSPI.
    Ricordo anche che ci sono "inconsistenze" di nomi in ProtocolSPI, dove c'erano
    alcuni punti in cui si leggeva cose tipo
    ```C++
    void Write()
    {
    ......@@ -193,7 +137,8 @@ void Write()
    }
    ```
    ------------------------------------------------------------------------------
    ---
    ### Perchè non vanno messi using namespace nei .h
    Semplicemente perchè includendo quei .h ti trovi cose non aspettate in `::`.
    ......@@ -212,7 +157,8 @@ void a()
    }
    ```
    ------------------------------------------------------------------------------
    ---
    ### Un'overview di scripts/
    Innanzitutto, questi script sono pensati per essere eseguiti avendo come working
    ......@@ -220,6 +166,7 @@ directory la root del repo (aka lanciateli con `./scripts/qualcosa` e non
    `cd scripts && ./qualcosa`)
    Lista:
    - anakin.sh: flashare la anakin via seriale
    - gen_fault_headers: (se non erro) chaimato da sbs --gen-qualcosa
    - linter.sh: il mio migliore amico
    ......@@ -233,7 +180,8 @@ Lista:
    sulla wiki di miosix (scusate, sono pigro
    e non avevo voglia di rifare tutto ogni volta).
    ------------------------------------------------------------------------------
    ---
    ### Serializzazione:
    Anche qua c'e stata una litig.. discussione animata interna su cosa usare
    ......@@ -242,30 +190,30 @@ Io voto per flatbuffers
    teo_piaz per mavlink
    fede terraneo per cereal
    * flatbuffers:
    - flatbuffers:
    permette di definire struct in un linguaggio suo e da quello genera header
    files e sorgenti per leggere e scrivere quelle struct.
    * pro: pensato per campo videogames, sviluppato da google, usato
    - pro: pensato per campo videogames, sviluppato da google, usato
    da facebook messenger o simili; veloce e leggero.
    * contro: non permette di imporre range di valori ammissibili per un campo.
    - contro: non permette di imporre range di valori ammissibili per un campo.
    cioe`, se dichiaro che una var e int16, posso mettere tutto int16,
    non solo i numeri da 15 a 28, per dire.
    * mavlink:
    - mavlink:
    teo_piaz dovrebbe star facendo roba con questo. a che punto e`?
    chiedeteglielo :)
    * pro: usato per i droni e permette di specificare range
    * contro: tutte le specifiche vanno fatte in XML.
    * cereal:
    - pro: usato per i droni e permette di specificare range
    - contro: tutte le specifiche vanno fatte in XML.
    - cereal:
    serializza classi intere di C++
    * pro: piu immediato da usare di altri
    * contro: vincola a fare la parte che riceve della ground station in c++
    - pro: piu immediato da usare di altri
    - contro: vincola a fare la parte che riceve della ground station in c++
    (non penso ma.. ci son problemi se le due architetture son diverse?)
    ------------------------------------------------------------------------------
    ---
    ### TODO:
    - spiegare come son fatte le classi dei sensori
    - spiegare math/
    - spiegare boards/
    - spiegare cpumeter/
    - esempio di uso di activeobject e singleton?
    - spiegare gotcha di singleton