Gestione della dipendenza hardware durante il test dell'unità

Naviga le tue risposte
2

Sto scrivendo un driver per un sensore IMU usando un approccio di sviluppo basato su test. Il protocollo di comunicazione di scelta è SPI. Utilizzando il processore CubeMX e STM32F415, l'interfaccia SPI è implementata nel file stm32f4xx_hal_spi.h , che contiene molte e più dichiarazioni di funzioni. Nota che questa interfaccia SPI è specifica del processore e il driver IMU può anche essere implementato su piattaforme diverse, quindi anche la flessibilità è importante.

Per esigenze di sviluppo basate su test, devo prendere in giro le funzioni SPI che uso nel codice del driver. Ho trovato due opzioni possibili:

1) Il file di intestazione SPI originale stm32fxx_hal_spi.h è incluso direttamente nell'intestazione del driver. Il suo intero contenuto viene deriso, anche se solo poche funzioni vengono utilizzate acusticamente nel driver del sensore.

PRO

  • implementazione semplice

CON

  • i file dei driver SPI effettivi devono essere copiati nel progetto del driver del sensore
  • mocking fat interface


2) All'interno del progetto del driver, crea l'intestazione spi.h . Ripetizione delle funzioni utilizzate dal driver ma originariamente già dichiarate in stm32fxx_hal_spi.h . Il mocking spi.h dà ai mazzi solo le funzioni effettivamente utilizzate.

PRO

  • non è necessario copiare i file del driver SPI specifici del processore nel progetto del driver del sensore

  • simula solo le cose usate

CON

  • il test di guida sembra semplice ma non so come integrarsi con l'hardware e il file stm32fxx_hal_spi.h

Mi sembra che il secondo approccio faccia un lavoro migliore in termini di astrazione dell'implementazione spi in un singolo file di intestazione. Ma come detto, non sono sicuro di come collegare questo file ai file del driver spi durante l'integrazione del driver del sensore nell'intero progetto.

Qualcuno di questi è considerato un approccio valido? C'è un approccio generalmente accettato per questo durante lo sviluppo del driver?

    
posta hbrezak 09.08.2018 - 14:39
fonte

1 risposta

4

Suggerisco di utilizzare un approccio orientato agli oggetti convenzionale. Anche con un semplice codice C, questo è abbastanza facile. 

struct spiInterace {
   void* privateData;
   void (*eachFunctionInSPIInterface)();
};
typedef struct spiInterace  spiInterace ;

Quindi la tua vera interfaccia SPI fornisce una 'nuova funzione': 

spiInterace* mkstm32f4xx_hal_spi()
{
   // malloc object, add any needed private data pointer (like
   // to memory mapped or open file descriptor) and fill in
   // function pointers to APIs now moved to static functions
}

... Analogamente per il tuo driver di dispositivo SPI "simulato".

Cambia tutte le tue chiamate in indiretto tramite l'oggetto spiIntrface: 

   spiInterface* spiI = // call one mkFunction or the other for testing or real;
   // instead of earlier call to eachFunctionInSPIInterface(someSPIdesignator);
   spiI->eachFunctionInSPIInterface ();

Quindi testare è semplice: basta costruire uno o l'altro spiInterface.

Spero che ti aiuti!

    
risposta data 09.08.2018 - 15:59
fonte

Leggi altre domande sui tag

trie iteration dovrebbe includere root? Internazionalizzazione API