Come posso testare il codice Arduino?


187

Mi piacerebbe essere in grado di testare il mio codice Arduino. Idealmente, sarei in grado di eseguire qualsiasi test senza dover caricare il codice su Arduino. Quali strumenti o librerie possono aiutarmi in questo?

C'è un emulatore Arduino in fase di sviluppo che potrebbe essere utile, ma non sembra essere ancora pronto per l'uso.

AVR Studio di Atmel contiene un simulatore di chip che potrebbe essere utile, ma non riesco a vedere come lo userei insieme all'IDE di Arduino.


C'è un'altra discussione su questa domanda dal 2011 a arduino.cc/forum/index.php?action=printpage;topic=54356.0
Jakob

Grazie @Jakob. Un simulatore Arduino a cui si fa riferimento in quel thread (con altri collegamenti potenzialmente utili nella parte inferiore della pagina): arduino.com.au/Simulator-for-Arduino.html
Matthew Murdoch

5
Sfortunatamente è solo per Windows, mi piacerebbe vedere un modo per compilare ed eseguire semplicemente il codice Arduino dalla riga di comando senza alcuna sorgente chiusa o dipendenze hardware.
Jakob,

3
Un piccolo aggiornamento, 5 anni dopo: Simavr è ancora molto attivo e è molto migliorato da quando è stata posta la domanda, quindi ho pensato che meritasse di essere sbattuto più vicino alla cima. E potrebbe essere lo strumento giusto per test di regressione, test basati su scenari e perché non anche test unitari. In questo modo il codice testato è lo stesso di quello sull'hardware di destinazione.
zmo,

Per progetti importanti, prendere in considerazione un tester hardware; un altro MCU che può cronometrare e testare reazioni pulsante / interruttore, tempo di avvio, temp, utilizzo v / ma, permutazioni strane di opzioni, ecc. Sì, è più hardware da costruire, ma può aggiungere un livello di sicurezza durante la revisione. molti dispositivi pro usano jtag et al.
dandavis,

Risposte:


137

Non eseguire test di unità sul dispositivo o sull'emulatore Arduino

Il caso contro i test basati su dispositivo / emulatore / sim del microcontrollore

Ci sono molte discussioni su cosa significhi unit test e non sto davvero cercando di discutere su questo qui. Questo post non ti dice di evitare tutti i test pratici sul tuo hardware di destinazione finale. Sto cercando di chiarire come ottimizzare il ciclo di feedback sullo sviluppo eliminando l'hardware di destinazione dai test più banali e frequenti. Si presume che le unità in prova siano molto più piccole dell'intero progetto.

Lo scopo del test unitario è testare la qualità del proprio codice. I test unitari in genere non devono mai testare la funzionalità di fattori al di fuori del proprio controllo.

Pensaci in questo modo: anche se dovessi testare la funzionalità della libreria Arduino, l'hardware del microcontrollore o un emulatore, è assolutamente impossibile che tali risultati dei test ti diano qualcosa sulla qualità del tuo lavoro. Pertanto, è molto più prezioso ed efficiente scrivere unit test che non vengono eseguiti sul dispositivo di destinazione (o sull'emulatore).

I test frequenti sull'hardware di destinazione hanno un ciclo dolorosamente lento:

  1. Modifica il tuo codice
  2. Compila e carica sul dispositivo Arduino
  3. Osserva il comportamento e indovina se il tuo codice sta facendo quello che ti aspetti
  4. Ripetere

Il passaggio 3 è particolarmente brutto se si prevede di ricevere messaggi diagnostici tramite la porta seriale ma il progetto stesso deve utilizzare l'unica porta seriale hardware del proprio Arduino. Se pensavi che la libreria SoftwareSerial potesse essere d'aiuto, dovresti sapere che è probabile che ciò interrompa qualsiasi funzionalità che richiede un tempismo accurato come la generazione di altri segnali allo stesso tempo. Questo problema mi è successo.

Ancora una volta, se dovessi testare il tuo schizzo usando un emulatore e le tue routine critiche per il tempo funzionassero perfettamente fino a quando non le avessi caricate sull'Arduino vero e proprio, l'unica lezione che imparerai è che l'emulatore è difettoso - e sapendolo ancora non rivela nulla sulla qualità del tuo lavoro.

Se è stupido test sul dispositivo o emulatore, che cosa dovrei fare?

Probabilmente stai usando un computer per lavorare al tuo progetto Arduino. Quel computer ha ordini di grandezza più veloci del microcontrollore. Scrivi i test per compilare ed eseguire sul tuo computer .

Ricorda, il comportamento della libreria Arduino e del microcontrollore dovrebbe essere considerato corretto o almeno costantemente errato .

Quando i tuoi test producono output in contrasto con le tue aspettative, allora probabilmente hai un difetto nel tuo codice che è stato testato. Se l'output del test corrisponde alle tue aspettative, ma il programma non si comporta correttamente quando lo carichi su Arduino, allora sai che i tuoi test erano basati su ipotesi errate e probabilmente hai un test errato. In entrambi i casi, ti verranno fornite informazioni reali su quali dovrebbero essere le tue successive modifiche al codice. La qualità del tuo feedback è migliorata da " qualcosa è rotto" a "questo codice specifico è rotto" .

Come compilare ed eseguire test sul PC

La prima cosa che devi fare è identificare i tuoi obiettivi di test . Pensa a quali parti del tuo codice vuoi testare, quindi assicurati di costruire il tuo programma in modo tale da poter isolare parti discrete per i test.

Se le parti che si desidera testare richiamano qualsiasi funzione Arduino, sarà necessario fornire sostituzioni del modello nel programma di test. Questo è molto meno lavoro di quanto sembri. I tuoi mock-up non devono fare altro che fornire input e output prevedibili per i tuoi test.

Qualsiasi tuo codice che intendi testare deve esistere in file di origine diversi dallo schizzo .pde. Non preoccuparti, il tuo schizzo verrà comunque compilato anche con un codice sorgente esterno allo schizzo. Quando si arriva davvero ad esso, nel file di schizzo dovrebbe essere definito poco più del normale punto di ingresso del programma.

Non resta che scrivere i test effettivi e quindi compilarlo utilizzando il compilatore C ++ preferito! Questo è probabilmente meglio illustrato con un esempio del mondo reale.

Un vero esempio funzionante

Uno dei miei progetti per animali domestici trovato qui ha alcuni semplici test eseguiti su PC. Per l'invio di questa risposta, esaminerò semplicemente come ho simulato alcune delle funzioni della libreria di Arduino e i test che ho scritto per testare quei modelli. Questo non è contrario a quello che ho detto prima di non testare il codice di altre persone perché sono stato io a scrivere i modelli. Volevo essere certo che i miei modelli fossero corretti.

Fonte di mock_arduino.cpp, che contiene codice che duplica alcune funzionalità di supporto fornite dalla libreria Arduino:

#include <sys/timeb.h>
#include "mock_arduino.h"

timeb t_start;
unsigned long millis() {
  timeb t_now;
  ftime(&t_now);
  return (t_now.time  - t_start.time) * 1000 + (t_now.millitm - t_start.millitm);
}

void delay( unsigned long ms ) {
  unsigned long start = millis();
  while(millis() - start < ms){}
}

void initialize_mock_arduino() {
  ftime(&t_start);
}

Uso il seguente mock-up per produrre output leggibili quando il mio codice scrive dati binari sul dispositivo seriale hardware.

fake_serial.h

#include <iostream>

class FakeSerial {
public:
  void begin(unsigned long);
  void end();
  size_t write(const unsigned char*, size_t);
};

extern FakeSerial Serial;

fake_serial.cpp

#include <cstring>
#include <iostream>
#include <iomanip>

#include "fake_serial.h"

void FakeSerial::begin(unsigned long speed) {
  return;
}

void FakeSerial::end() {
  return;
}

size_t FakeSerial::write( const unsigned char buf[], size_t size ) {
  using namespace std;
  ios_base::fmtflags oldFlags = cout.flags();
  streamsize oldPrec = cout.precision();
  char oldFill = cout.fill();

  cout << "Serial::write: ";
  cout << internal << setfill('0');

  for( unsigned int i = 0; i < size; i++ ){
    cout << setw(2) << hex << (unsigned int)buf[i] << " ";
  }
  cout << endl;

  cout.flags(oldFlags);
  cout.precision(oldPrec);
  cout.fill(oldFill);

  return size;
}

FakeSerial Serial;

e, infine, l'attuale programma di test:

#include "mock_arduino.h"

using namespace std;

void millis_test() {
  unsigned long start = millis();
  cout << "millis() test start: " << start << endl;
  while( millis() - start < 10000 ) {
    cout << millis() << endl;
    sleep(1);
  }
  unsigned long end = millis();
  cout << "End of test - duration: " << end - start << "ms" << endl;
}

void delay_test() {
  unsigned long start = millis();
  cout << "delay() test start: " << start << endl;
  while( millis() - start < 10000 ) {
    cout << millis() << endl;
    delay(250);
  }
  unsigned long end = millis();
  cout << "End of test - duration: " << end - start << "ms" << endl;
}

void run_tests() {
  millis_test();
  delay_test();
}

int main(int argc, char **argv){
  initialize_mock_arduino();
  run_tests();
}

Questo post è abbastanza lungo, quindi fai riferimento al mio progetto su GitHub per vedere altri casi di test in azione. Tengo i miei lavori in corso in rami diversi da quelli master, quindi controlla anche quei rami per ulteriori test.

Ho scelto di scrivere le mie routine di test leggere, ma sono disponibili anche framework di unit test più robusti come CppUnit.


1
Questa è un'ottima risposta! Grazie!
Jonathan Arkell,

5
@WarrenMacEvoy Ancora una volta, penso che tu abbia preso il mio consiglio e lo abbia trasformato in qualcosa che non lo è. Dovresti certamente testare il tuo codice nel suo ambiente reale A QUALUNQUE PUNTO. La mia tesi è che non dovresti farlo ogni giorno e certamente non dovresti chiamarlo un test unitario.
Salvatore di ferro,

1
@toasted_flakes Non sono sicuro di dove hai preso quella citazione, ma non è qualcosa che ho detto. I test unitari in esecuzione sul dispositivo presentano molti problemi: loop di feedback molto lento, potresti non avere porte seriali o altri mezzi di I / O da risparmiare sul tuo dispositivo di destinazione e hanno una capacità molto limitata che può influire sull'ambito di la tua suite di test.
Iron Savior,

1
@ChristianHujer Dovresti certamente testare su hardware reale - nessuno sta dicendo che non dovresti mai testare su hardware di destinazione. Il mio post riguarda l'ottimizzazione del ciclo di feedback giornaliero sullo sviluppo mediante test unitari sulla macchina di sviluppo. Il sovraccarico del test è ridotto al minimo in questo modo perché testerai sull'hardware di destinazione solo quando è necessario.
Salvatore di ferro,

1
I file di origine dello schizzo di @Benjohn Arduino avevano l'estensione "pde" anche se sono in C ++. arduino.cc/en/Guide/Environment#toc1
Iron Savior

63

In assenza di framework di unit test preesistenti per Arduino, ho creato ArduinoUnit . Ecco un semplice schizzo di Arduino che ne dimostra l'utilizzo:

#include <ArduinoUnit.h>

// Create test suite
TestSuite suite;

void setup() {
    Serial.begin(9600);    
}

// Create a test called 'addition' in the test suite
test(addition) {
    assertEquals(3, 1 + 2);
}

void loop() {
    // Run test suite, printing results to the serial port
    suite.run();
}

18
I test sembrano essere eseguiti solo su Arduino, quindi non è possibile eseguirli automaticamente sulla macchina di sviluppo. L'idea di base dei test unitari è di eseguirli automaticamente, quindi il progetto attuale sembra essere più uno strumento di debug ma nessun vero framework di test unitari.
Jakob,

1
Hai ragione. Per essere in grado di eseguirli su un PC, inoltre, richiederebbe un emulatore Arduino o AVR. Non esiste un vero livello di astrazione hardware nelle librerie di Arduino (al momento) e gli emulatori AVR quando ho guardato erano ancora in fase di sviluppo. Se le cose sono andate avanti ora, in linea di principio ciò potrebbe essere fatto.
Matthew Murdoch,

12
@MatthewMurdoch Temo che tu abbia sbagliato. Per definizione, i test unitari non vengono mai eseguiti nell'ambiente di destinazione. In effetti, l'idea alla base del test unitario è quella di eliminare completamente l'ambiente target dai test. Vengono sempre eseguiti in un ambiente simile a un laboratorio che prende in giro tutte le attività esterne all'unità da testare in modo da garantire che il successo o il fallimento del test si riflettano SOLO sull'unità sotto test. Questo è uno dei motivi principali per cui le persone usano il concetto di Inversione del controllo in progetti complessi.
Salvatore di ferro

2
@ marcv81 Le aree in cui esistono tali problemi di portabilità sono molto probabilmente soggetti poveri per i test unitari. Ricorda che i test unitari dovrebbero solo testare il TUO codice, quindi limitane di conseguenza il campo di applicazione. Con la grande disparità nell'hardware di cui stiamo parlando qui, posso accettare che alcune di queste circostanze possano essere inevitabili. In questi casi, un ingegnere dovrebbe rimanere consapevole e adottare misure attenuanti. Ciò potrebbe significare modificare il tuo design per migliorare la testabilità o anche qualcosa di semplice come documentare semplicemente i fatti rilevanti.
Iron Savior

2
@Iron Savior un test unitario verifica il tuo codice, ma il tuo codice viene eseguito da qualche parte. Se quel contesto è o emula un contesto Arduino; quindi ArdunoUnit ti aiuterà a scrivere unit test. Se si esamina il progetto ArduinoUnit, il meta-test del framework carica, esegue e verifica automaticamente i risultati del test sulla destinazione multipiattaforma. Proprio come faresti con altri obiettivi multipiattaforma. Il tuo punto di vista è una scusa per non testare il codice in un ambiente incorporato in cui la correttezza conta tanto, se non di più, rispetto ad altri contesti.
Warren MacEvoy,

21

Ho un notevole successo con l'unità che prova il mio codice PIC estraendo l'accesso hardware e deridendolo nei miei test.

Ad esempio, astraggo PORTA con

#define SetPortA(v) {PORTA = v;}

Quindi SetPortA può essere facilmente deriso, senza aggiungere il codice ambientale nella versione PIC.

Una volta che l'astrazione dell'hardware è stata testata per un po ', presto scopro che generalmente il codice va dall'apparecchiatura di prova al PIC e funziona la prima volta.

Aggiornare:

Uso una cucitura #include per il codice dell'unità, #include il codice dell'unità in un file C ++ per il banco di prova e un file C per il codice di destinazione.

Ad esempio, voglio multiplexare quattro display a 7 segmenti, una porta che guida i segmenti e un secondo selezionando il display. Il codice display si interfaccia con i display tramite SetSegmentData(char)e SetDisplay(char). Posso deriderli nel mio banco di prova C ++ e controllare che ottenga i dati che mi aspetto. Per il target che uso in #definemodo da ottenere un'assegnazione diretta senza l'overhead di una chiamata di funzione

#define SetSegmentData(x) {PORTA = x;}

In linea di principio, posso vedere come posso usare la 'cucitura' del preprocessore per i test unitari. Tuttavia non sono sicuro di come posso farlo senza avere un emulatore su cui eseguire i test o un compilatore compatibile avr-gcc che emetta (nel mio caso) binari di Windows ...
Matthew Murdoch,

Grazie per l'aggiornamento. Eseguite i test unitari sul PIC o sul PC?
Matthew Murdoch,

I test unitari vengono eseguiti su un Mac utilizzando Xcode. Per eseguirli su Pic probabilmente sarebbe necessario un emulatore di qualche tipo. L'astrazione in modo che funzioni sul Mac rende molto più semplice il passaggio dei processori
David Sykes,

L'ambiente Arduino usa il compilatore avr-gcc che ha alcune idiosincrasie che significano che la compilazione con gcc (o altri compilatori C ++) e l'esecuzione su un PC potrebbero non significare che il codice verrà compilato anche su avr-gcc.
Matthew Murdoch,

Di che tipo di differenza stai parlando? Sono cose che non possono essere gestite con alcune direttive del preprocessore?
Joseph Lisee,


12

simavr è un simulatore AVR che utilizza avr-gcc.

Supporta già alcuni microcontrollori ATTiny e ATMega e - secondo l'autore - è facile aggiungerne altri.

Negli esempi si trova simduino, un emulatore di Arduino. Supporta l'esecuzione del bootloader Arduino e può essere programmato con avrdude tramite Socat (un Netcat modificato ).


9

Puoi testare l'unità in Python con il mio progetto, PySimAVR . Arscons è utilizzato per la costruzione e simavr per la simulazione.

Esempio:

from pysimavr.sim import ArduinoSim    
def test_atmega88():
    mcu = 'atmega88'
    snippet = 'Serial.print("hello");'

    output = ArduinoSim(snippet=snippet, mcu=mcu, timespan=0.01).get_serial()
    assert output == 'hello'

Inizia il test:

$ nosetests pysimavr/examples/test_example.py
pysimavr.examples.test_example.test_atmega88 ... ok

6

Non sono a conoscenza di alcuna piattaforma in grado di testare il codice Arduino.

Tuttavia, esiste la piattaforma Fritzing , che è possibile utilizzare per modellare l'hardware e successivamente esportare diagrammi PCB e altro.

Vale la pena controllare.


6

Stiamo usando le schede Arduino per l'acquisizione dei dati in un grande esperimento scientifico. Successivamente, dobbiamo supportare diverse schede Arduino con diverse implementazioni. Ho scritto programmi di utilità Python per caricare dinamicamente immagini esadecimali Arduino durante i test delle unità. Il codice trovato sul link seguente supporta Windows e Mac OS X tramite un file di configurazione. Per scoprire dove sono posizionate le tue immagini esadecimali dall'IDE di Arduino, premi il tasto Maiusc prima di premere il pulsante build (play). Premi il tasto Maiusc mentre premi il caricamento per scoprire dove si trova il tuo avrdude (utility di caricamento da riga di comando) sul tuo sistema / versione di Arduino. In alternativa, puoi guardare i file di configurazione inclusi e utilizzare il percorso di installazione (attualmente su Arduino 0020).

http://github.com/toddstavish/Python-Arduino-Unit-Testing


+1 Roba fantastica! Hai delle informazioni su come hai eseguito il test dell'unità una volta caricate le immagini?
Matthew Murdoch,

Abbiamo usato i nosetest per eseguire i nostri test unitari sul lato pitone. L'impostazione per ciascun test carica l'immagine esadecimale corretta per quel test. Iniziamo in piccolo e poi lavoriamo su test più completi. Assicurati che la comunicazione seriale funzioni, assicurati che l'integrazione seriale con l'interfaccia utente funzioni, controlla l'integrazione seriale-DB, ecc. Analog_read_speed pde e py mostrano le basi di questo (vedi link github sopra). Alla fine, apriremo l'intero progetto, quindi per favore rimanete sintonizzati. :)
toddstavish,

6

Questo programma consente l'esecuzione automatica di numerosi test unitari di Arduino. Il processo di test viene avviato sul PC ma i test vengono eseguiti sull'hardware Arduino effettivo. Un set di unit test viene generalmente utilizzato per testare una libreria Arduino. (Questo

Forum di Arduino: http://arduino.cc/forum/index.php?topic=140027.0

Pagina del progetto GitHub: http://jeroendoggen.github.com/Arduino-TestSuite

Pagina nell'indice del pacchetto Python: http://pypi.python.org/pypi/arduino_testsuite

I test unitari sono scritti con "Arduino Unit Testing Library": http://code.google.com/p/arduinounit

I seguenti passaggi vengono eseguiti per ciascun set di test unitari:

  • Leggi il file di configurazione per scoprire quali test eseguire
  • Lo script compila e carica uno schizzo di Arduino che contiene il codice di test dell'unità.
  • I test unitari vengono eseguiti sulla scheda Arduino.
  • I risultati del test vengono stampati sulla porta seriale e analizzati dallo script Python.
  • Lo script avvia il test successivo, ripetendo i passaggi precedenti per tutti i test richiesti nel file di configurazione.
  • Lo script stampa un riepilogo che mostra una panoramica di tutti i test falliti / superati nella suite di test completa.

5

Tieni il codice specifico dell'hardware separato o sottratto al resto in modo da poter testare ed eseguire il debug di quel "resto" più grande su qualsiasi piattaforma per la quale hai buoni strumenti e con cui hai più familiarità.

Fondamentalmente, prova a costruire il maggior numero di codice finale da quanti più blocchi noti possibili. Il restante lavoro specifico dell'hardware sarà quindi molto più semplice e veloce. Puoi finirlo usando emulatori e / o dispositivi di emulazione esistenti da solo. E poi, ovviamente, dovrai testare la cosa reale in qualche modo. A seconda delle circostanze, ciò può essere o non essere molto ben automatizzabile (ovvero chi o cosa premerà i pulsanti e fornirà altri input? Chi o cosa osserverà e interpreterà vari indicatori e output?).



5

Sto usando Searduino quando scrivo il codice Arduino. Searduino è un simulatore Arduino e un ambiente di sviluppo (Makefile, codice C ...) che semplifica l'hacking in C / C ++ usando il tuo editor preferito. Puoi importare gli schizzi di Arduino ed eseguirli nel simulatore.

Schermata di Searduino 0.8: http://searduino.files.wordpress.com/2014/01/jearduino-0-8.png

Searduino 0.9 verrà rilasciato e un video verrà registrato non appena verranno eseguiti gli ultimi test .... tra un giorno o due.

I test sul simulatore non devono essere considerati test reali, ma sicuramente mi hanno aiutato molto a trovare errori stupidi / logici (dimenticare di fare pinMode(xx, OUTPUT), ecc.).

A proposito: sono una delle persone che sviluppano Searduino.


5

Ho costruito arduino_ciper questo scopo. Sebbene sia limitato al test delle librerie di Arduino (e non di schizzi autonomi), consente l'esecuzione di test unitari localmente o su un sistema CI (come Travis CI o Appveyor).

Considera una libreria molto semplice nella directory della tua libreria Arduino, chiamata DoSomething, con do-something.cpp:

#include <Arduino.h>
#include "do-something.h"

int doSomething(void) {
  return 4;
};

Lo testeresti come segue (con un file di test chiamato test/is_four.cppo alcuni di questi):

#include <ArduinoUnitTests.h>
#include "../do-something.h"

unittest(library_does_something)
{
  assertEqual(4, doSomething());
}

unittest_main()  // this is a macro for main().  just go with it.

È tutto. Se la assertEqualsintassi e la struttura del test sembrano familiari, è perché ho adottato alcune delle librerie ArduinoUnit di Matthew Murdoch a cui ha fatto riferimento nella sua risposta .

Vedere Reference.md per ulteriori informazioni sui pin I / O di unit test, il clock, le porte seriali, ecc.

Questi test unitari vengono compilati ed eseguiti utilizzando uno script contenuto in una gemma rubino. Per esempi su come configurarlo, vedere README.md o semplicemente copiare da uno di questi esempi:


Sembra interessante, ma non sono sicuro che stia testando correttamente il codice Arduino. Dall'output che hai pubblicato, viene compilato in architettura x86_64, che ovviamente non viene utilizzato per Arduino. Ciò potrebbe introdurre bug causati da conflitti tra implementazioni di tipo.
Cerin,

Questo tipo di bug è certamente possibile. Hai un esempio che potrei usare per un caso di test?
Ian,

3

Esiste un progetto chiamato ncore , che fornisce core nativo per Arduino. E ti permette di scrivere test per il codice Arduino.

Dalla descrizione del progetto

Il core nativo consente di compilare ed eseguire schizzi Arduino sul PC, generalmente senza modifiche. Fornisce versioni native di funzioni Arduino standard e un interprete da riga di comando per fornire input al tuo schizzo che normalmente verrebbero dall'hardware stesso.

Anche nella sezione "cosa serve per usarlo"

Se vuoi compilare i test, avrai bisogno di cxxtest da http://cxxtest.tigris.org . NCORE è stato testato con cxxtest 3.10.1.


Questo è un progetto interessante Sfortunatamente, sembra che ora sia morto, poiché non ha avuto progressi per 6 anni.
Cerin,

2

Se vuoi testare l'unità di codice fuori dall'MCU (sul desktop), controlla libcheck: https://libcheck.github.io/check/

L'ho usato per testare il mio codice incorporato alcune volte. È un framework piuttosto robusto.


L'unico aspetto negativo è che questo non supporta g ++, il che lo rende inutile per testare la maggior parte delle librerie Arduino che utilizzano le funzionalità C ++.
Cerin,

1

Puoi usare emulare : puoi trascinare e rilasciare un microcontrollore su un diagramma ed eseguire il codice in Eclipse. La documentazione sul sito Web spiega come configurarlo.


1

Utilizzare Proteus VSM con una libreria Arduino per eseguire il debug del codice o per testarlo.

È una procedura consigliata prima di inserire il codice, ma accertati dei tempi poiché la simulazione non viene eseguita in tempo reale mentre vengono eseguiti sulla scheda.


1

Prova il simulatore di circuiti Autodesk . Permette di testare il codice e i circuiti Arduino con molti altri componenti hardware.


0

In Arduino di base è scritto con C e C ++, anche le librerie di Arduino sono scritte in C e C ++. Quindi, in termini semplici, basta gestire il codice come C e C ++ e provare a fare il test unitario. Qui, con la parola "handle" intendo che cambi tutta la sintassi di base come serial.println in sysout, pinmode in varaibles, void loop in while () loop che si interrompe nel keytock o dopo qualche iterazione.

So che questo è un processo un po 'lungo e non così diretto. Sulla mia esperienza personale, una volta che hai a che fare con questo, questo diventa più affidabile.

-Nandha_Frost


0

Se sei interessato a eseguire uno schizzo INO e verificare l'output seriale, ne ho un'implementazione funzionante nel mio progetto di checksum NMEA di Arduino .

Lo script seguente prende il file e utilizza l'interfaccia della riga di comando di Arduino per compilarlo in un file HEX che viene quindi caricato in SimAVR che lo valuta e stampa l'output seriale. Dato che tutti i programmi Arduino funzionano per sempre senza avere davvero la possibilità di uccidersi ( exit(0)non funziona), lascio che lo schizzo venga eseguito per alcuni secondi e quindi diffido l'output catturato con l'output previsto.

Scarica ed estrai l'interfaccia della riga di comando di Arduino (in questo caso la versione 0.5.0 - la più recente al momento della stesura):

curl -L https://github.com/arduino/arduino-cli/releases/download/0.5.0/arduino-cli_0.5.0_Linux_64bit.tar.gz -o arduino-cli.tar.gz
tar -xvzf arduino-cli.tar.gz

Ora puoi aggiornare l'indice e installare il core appropriato:

./arduino-cli core update-index
./arduino-cli core install arduino:avr

Supponendo che il tuo schizzo sia chiamato nmea-checksum.ino, per ottenere ELF e HEX, esegui:

./arduino-cli compile -b arduino:avr:uno nmea-checksum.ino

Successivamente, SimAVR per eseguire HEX (o ELF) - costruisco dal sorgente perché l'ultima versione non ha funzionato per me:

sudo apt-get update
sudo apt-get install -y build-essential libelf-dev avr-libc gcc-avr freeglut3-dev libncurses5-dev pkg-config
git clone https://github.com/buserror/simavr.git
cd simavr
make

La compilazione simavr/run_avrcorretta ti darà ciò che puoi usare per eseguire lo schizzo. Come ho detto, timeoutaltrimenti non terminerà mai:

cd simavr
timeout 10 ./run_avr -m atmega168 -f 16000000 ../../nmea-checksum.ino.arduino.avr.uno.elf &> nmea-checksum.ino.clog || true

Il file generato avrà caratteri di controllo del codice colore ANSI che avvolgono l'output seriale, per sbarazzarsi di quelli:

cat nmea-checksum.ino.clog | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g" > nmea-checksum.ino.log
cat nmea-checksum.ino.log

Ora tutto ciò che devi fare è confrontare questo file con un file valido noto:

diff nmea-checksum.ino.log ../../nmea-checksum.ino.test

Se non ci sono differenze, diffuscirà con il codice 0, altrimenti lo script fallirà.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.