2013-06-17 10 views
5

Sono nuovo nello sviluppo su sistemi embedded e non sono abituato ad avere pochissima memoria di programma (16kB in questo caso) con cui giocare. Mi piacerebbe essere in grado di creare variabili globali, array e funzioni a cui posso accedere da qualsiasi punto del programma mentre esiste solo in una posizione in memoria. Il mio attuale approccio è quello di utilizzare membri di classi e metodi statici che posso utilizzare semplicemente includendo il file di intestazione (ad esempio #include "spi.h").Evita di creare più copie di codice nella memoria

Qual è l'approccio migliore per ciò che sto cercando di fare?

Ecco un esempio di classe. Da quanto ho capito, variabili come _callback e definizioni di funzioni come call() in .cpp verranno visualizzate solo in spi.o, quindi verranno visualizzate solo una volta in memoria, ma potrei essere confuso.

spi.h:

#ifndef SPI_H_ 
#define SPI_H_ 

#include "msp430g2553.h" 

class SPI { 
public: 
    typedef void (*voidCallback)(void); 

    static voidCallback _callback; 
    static char largeArray[1000]; 
    static __interrupt void USCIA0TX_ISR(); 
    static void call(); 

    static void configure(); 
    static void transmitByte(unsigned char byte, voidCallback callback); 
}; 

#endif /* SPI_H_ */ 

spi.cpp:

#include "spi.h" 

SPI::voidCallback SPI::_callback = 0; 
char SPI::largeArray[] = /* data */ ; 

void SPI::configure() { 
    UCA0MCTL = 0; 
    UCA0CTL1 &= ~UCSWRST;     
    IE2 |= UCA0TXIE; 

} 

void SPI::transmitByte(unsigned char byte, voidCallback callback) { 
    _callback = callback; 
    UCA0TXBUF = byte; 
} 

void SPI::call() { 
    SPI::_callback(); 
} 

#pragma vector=USCIAB0TX_VECTOR 
__interrupt void SPI::USCIA0TX_ISR() 
{ 
    volatile unsigned int i; 
    while (UCA0STAT & UCBUSY); 
    SPI::call(); 
} 
+0

per includere semplicemente l'intestazione e iniziare a utilizzare lo "SPI", basta usare [modello Singleton] (http://stackoverflow.com/questions/1008019/c-singleton-design-pattern), è un elemento comune incorporato che si ha una periferica e un solo oggetto per gestire l'hardware, non più oggetti consentiti. , inoltre è possibile utilizzare [factory pattern] (http://stackoverflow.com/questions/5120768/how-to-implement-the-factory-pattern-in-c-correctly) per consentire ad esempio un certo numero di oggetti (Canali SPI) – Abdurahman

risposta

10

I membri di dati e le funzioni membro della classe che hai scritto sarà definito solo una volta in memoria. E se sono non contrassegnati come statici, le funzioni membro saranno ancora definite solo una volta in memoria. I membri di dati non statici verranno creati in memoria una volta per ciascun oggetto creato, quindi se crei solo un oggetto SPI, ottieni solo una copia dei membri di dati non statici. Versione breve: stai risolvendo un problema.

1

Come per Pete, le interferenze statiche non influiscono sul raddoppio del codice, solo sui membri vars. Nel tuo esempio, c'è una differenza di 0 tra l'utilizzo della memoria statica non statica eccetto forse per la var _callback (che tu chiami come un errore). E quella variabile raddoppierebbe solo se la classe fosse stata creata più di una volta.

Se si desidera che il codice non esista in memoria quando non è in uso, esaminare gli overlay o una sorta di processo di collegamento dinamico. Il codice di tipo DLL sarà probabilmente un eccessivo overkill per 16K, ma gli overlay con codice compresso potrebbero aiutarti.

Inoltre, fare attenzione ai collegamenti aggiuntivi nel codice dalle librerie. Esamina attentamente i tuoi file .map per il codice gonfiato da chiamate di funzioni innocue. Ad esempio, una singola chiamata printf() collegherà tutti i tipi di roba di vargs se è l'unica cosa che lo usa. Lo stesso vale per il software in virgola mobile (se non si dispone di un'unità FP di default).

+0

Siamo spiacenti, il "richiamo come errore" era un residuo di un'altra domanda che ho chiesto. Ho aggiornato la domanda con un array di esempio di grandi dimensioni per illustrare di cosa sto parlando. – JustcallmeDrago

+0

Nel tuo nuovo caso, non c'è ancora alcun motivo per dichiararlo statico eccetto per renderlo un oggetto di tipo singleton per (dubbia) sicurezza. Ancora una volta, è meglio studiare il file della mappa per vedere da dove proviene il gonfiore e combattere le cose da lì. –

Problemi correlati