Come si può testare automaticamente il codice sorgente di Arduino (integrazione continua)?

Vorrei gestire il mio codice sorgente Arduino (progetti e librerie) sotto il controllo del codice sorgente con test continui. Come posso compilare automaticamente il codice con strumenti di integrazione continua, per assicurarmi che ogni versione si compili in modo pulito? Nel migliore dei casi si dovrebbe essere in grado di configurare build per più processori, facoltativamente eseguire unit test e verificare la massima dimensione binaria.

La versione più recente di Arduino ide ha un'interfaccia a riga di comando per compilare e caricare codice. Ma puoi ovviamente farlo con makefile e avrdude. Ora hai compilato il tuo codice MA devi testarlo. Poiché i simulatori sono complessi, incompleti, espansivi e ... Solo una simulazione e poiché i chip sono relativamente economici, la costruzione di una strega da tavolo renderà l'interazione HW E verificherà che i risultati siano il modo più rapido e semplice. Su quella scheda "speciale" puoi caricare qualcosa come una strega interprete che fa un test dal PC ed eseguilo, qualcosa di simile a firmata per Arduino. Almeno è così che lo costruirò. E per quanto ne so non esiste alcuna implementazione nota di questo, anche se sono abbastanza sicuro che molti settori dovrebbero e probabilmente lo faranno.

Come creatore di PlatformIO, ti consiglio di esaminarlo. È un generatore di codice multipiattaforma e gestore di librerie mancanti. Può creare lo stesso codice per le piattaforme e le schede di sviluppo embedded più diffuse.

PlatformIO può essere integrato con molti sistemi di integrazione continua (CI) popolari (o propri). Vedi la documentazione con esempi .

Diamo un'occhiata a .travis.ymlconfig / template per Travis CI:

language: python
python:
    - "2.7"

env:
    - PLATFORMIO_CI_SRC=path/to/source/file.c
    - PLATFORMIO_CI_SRC=path/to/source/file.ino
    - PLATFORMIO_CI_SRC=path/to/source/directory

install:
    - python -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)"

script:
    - platformio ci --board=TYPE_1 --board=TYPE_2 --board=TYPE_N

Esempio

Integrazione per il USB_Host_Shield_2.0progetto. Il .travis.ymlfile di configurazione:

language: python
python:
    - "2.7"

env:
    - PLATFORMIO_CI_SRC=examples/acm/acm_terminal
    - PLATFORMIO_CI_SRC=examples/Bluetooth/WiiIRCamera PLATFORMIO_BUILD_FLAGS="-DWIICAMERA"
    - PLATFORMIO_CI_SRC=examples/ftdi/USBFTDILoopback
    - PLATFORMIO_CI_SRC=examples/Xbox/XBOXUSB
    # - ...

install:
    - python -c "$(curl -fsSL https://raw.githubusercontent.com/platformio/platformio/master/scripts/get-platformio.py)"

    # Libraries from PlatformIO Library Registry
    # http://platformio.org/#!/lib/show/416/TinyGPS
    # http://platformio.org/#!/lib/show/417/SPI4Teensy3
    - platformio lib install 416 417

script:
    - platformio ci --board=uno --board=teensy31 --board=due --lib="."

• File di configurazione: https://github.com/felis/USB_Host_Shield_2.0/blob/master/.travis.yml
• Cronologia build: https://travis-ci.org/felis/USB_Host_Shield_2.0

Un esempio di impostazione dell'integrazione continua di Jenkins per il progetto Arduino può essere trovato qui: Integrazione continua per sistemi embedded

L'esempio mostra come creare e caricare immagini su Arduino ed eseguire test Web Selenium (il sistema in prova è un web server basato su Arduino).

Ho scritto questo test unittest framework per Arduino, dal momento che non riuscivo a trovare il giusto esistente. Anche se non l'ho scritto per CI, sarebbe adatto per il lavoro CI, poiché non richiede hardware ma può essere eseguito su PC.

L'esecuzione dei lavori CI senza l'hardware ha lati positivi e lati negativi, lati positivi che lo sono

• Nessun lampeggio, nessun hardware necessario -> può essere eseguito in parallelo -> veloce per verificare ad esempio ogni commit
• Nessun problema hardware che influenza i test -> non c'è bisogno di preoccuparsi se questo test ha fallito perché il mio componente hardware XYZ non è stabile

Sul lato negativo c'è:

• Non sta testando il vero codice target, ad esempio il tuo 'int' è 32 bit nel tuo PC e 16 bit in AVR.

Ho appena messo insieme un articolo di dimensioni decenti come risposta a questa domanda correlata su un framework di test CI / unità Arduino che ho scritto che è finalmente abbastanza maturo per iniziare a parlare pubblicamente.

La arduino_cigemma ruby ​​supporta sia i test locali che l'integrazione Travis CI (ad esempio questo lavoro di compilazione per la libreria FONA di Adafruit ).

Alcuni esempi di come si integra:

• La libreria di esempi DoSomething mostrata sopra, usata per testare arduino_ci stesso
• Un esempio pratico, testare un'implementazione della coda
• Un esempio complesso, che simula una libreria che controlla un dispositivo interattivo tramite una connessione SoftwareSerial come parte della libreria Adafruit FONA

Ho creato un problema per riportare le dimensioni dello schizzo ma non è stato fatto alcun lavoro su questo. È anche possibile che un giorno potrei parallelizzare le build, ma al momento non sono sicuro di come lo farei. In questo momento, il passaggio di build su Travis CI che richiede più tempo è il download dell'IDE di Arduino ... i test paralleli non daranno molto fastidio se tutti i lavori devono eseguire quel passaggio.

Consiglierei di usare il plug-in eclissi arduino chiamato sloeber sloeber.io di cui sono il responsabile del progetto.
Si integra con il controllo della versione e consente di costruire su più piattaforme in quanto supporta più configurazioni.
Anche se non è ancora una prova idiota, ho documentato e dimostrato usando test unitari del codice arduino sul PC locale usando il framework di test di Google.
Ecco un link a un blog contenente una presentazione di come puoi farlo. http://blog.baeyens.it/#post25