Sto usando troppa RAM. Come può essere misurato?

Vorrei sapere quanta RAM sto usando nel mio progetto, per quanto ne so, non c'è modo di risolverlo (se non quello di attraversarlo e calcolarlo da solo). Sono arrivato a un palcoscenico in un progetto piuttosto ampio in cui ho determinato che sto esaurendo la RAM.

Ho deciso questo perché posso aggiungere una sezione e poi si scatena l'inferno da qualche altra parte nel mio codice senza una ragione apparente. Se ho #ifndefqualcos'altro, funziona di nuovo. Non c'è nulla di programmaticamente sbagliato nel nuovo codice.

Ho sospettato per un po 'che stavo arrivando alla fine della RAM disponibile. Non penso di usare troppi stack (anche se è possibile), qual è il modo migliore per determinare quanta RAM sto effettivamente usando?

Passando attraverso e cercando di risolverlo, ho problemi quando arrivo a enumerazioni e strutture; quanta memoria costano?

prima modifica: INOLTRE, ho modificato il mio sketch così tanto dall'inizio, questi non sono i risultati effettivi che ho ottenuto inizialmente, ma sono quello che sto ottenendo ora.

  text     data     bss     dec     hex filename
 17554      844     449   18847    499f HA15_20140317w.cpp.elf
 16316      694     409   17419    440b HA15_20140317w.cpp.elf
 17346      790     426   18562    4882 HA15_20140317w.cpp.elf

La prima riga (con testo 17554) non funzionava, dopo molte modifiche, la seconda riga (con testo 16316) funziona come dovrebbe.

modifica: la terza riga ha tutto funzionante, lettura seriale, nuove funzioni, ecc. Ho sostanzialmente rimosso alcune variabili globali e un codice duplicato. Ne parlo perché (come sospettato) non si tratta di questo codice per sae, ma di utilizzo della RAM. Il che mi riporta alla domanda originale, "come misurarla al meglio" Sto ancora verificando alcune risposte, grazie.

Come interpreto effettivamente le informazioni di cui sopra?

Finora la mia comprensione è:

`TEXT` is program instruction memory
`DATA` is variables (unitialised?) in program memory
`BSS`  is variables occupying RAM

poiché BSS è considerevolmente inferiore a 1024 byte, perché il secondo funziona, ma il primo no? Se è DATA+BSSallora occupano entrambi più di 1024.

ri-modifica: ho modificato la domanda per includere il codice, ma ora l'ho rimosso perché in realtà non aveva nulla a che fare con il problema (a parte forse pratiche di codifica scadenti, dichiarazioni di variabili e simili). Puoi rivedere il codice guardando indietro attraverso le modifiche se vuoi davvero vederlo. Volevo tornare alla domanda a portata di mano, che era più basata su: come misurare l'utilizzo della RAM.

È possibile utilizzare le funzioni fornite da AVRGCC: Monitoraggio dell'utilizzo dello stack

La funzione aveva lo scopo di verificare l'utilizzo dello stack ma ciò che riporta è la RAM effettiva che non è mai stata utilizzata (durante l'esecuzione). Lo fa "dipingendo" (riempiendo) la RAM con un valore noto (0xC5), e quindi controllando l'area RAM contando quanti byte hanno ancora lo stesso valore iniziale.
Il rapporto mostrerà la RAM che non è stata utilizzata (RAM libera minima) e pertanto è possibile calcolare la RAM massima che è stata utilizzata (RAM totale - RAM segnalata).

Ci sono due funzioni:

• StackPaint viene eseguito automaticamente durante l'inizializzazione e "dipinge" la RAM con il valore 0xC5 (può essere modificato se necessario).

• StackCount può essere chiamato in qualsiasi momento per contare la RAM che non è stata utilizzata.

Ecco un esempio di utilizzo. Non fa molto ma ha lo scopo di mostrare come utilizzare le funzioni.

// -----------------------------------------------------------------------------
extern uint8_t _end;
extern uint8_t __stack;

void StackPaint(void) __attribute__ ((naked)) __attribute__ ((section (".init1")));

void StackPaint(void)
{
#if 0
    uint8_t *p = &_end;

    while(p <= &__stack)
    {
        *p = 0xc5;
        p++;
    }
#else
    __asm volatile ("    ldi r30,lo8(_end)\n"
                    "    ldi r31,hi8(_end)\n"
                    "    ldi r24,lo8(0xc5)\n" /* STACK_CANARY = 0xc5 */
                    "    ldi r25,hi8(__stack)\n"
                    "    rjmp .cmp\n"
                    ".loop:\n"
                    "    st Z+,r24\n"
                    ".cmp:\n"
                    "    cpi r30,lo8(__stack)\n"
                    "    cpc r31,r25\n"
                    "    brlo .loop\n"
                    "    breq .loop"::);
#endif
} 


uint16_t StackCount(void)
{
    const uint8_t *p = &_end;
    uint16_t       c = 0;

    while(*p == 0xc5 && p <= &__stack)
    {
        p++;
        c++;
    }

    return c;
} 

// -----------------------------------------------------------------------------

void setup() {

Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
Serial.println(StackCount(), DEC);  // calls StackCount() to report the unused RAM
delay(1000);
}

I problemi principali che puoi avere con l'utilizzo della memoria in fase di esecuzione sono:

• nessuna memoria disponibile nell'heap per allocazioni dinamiche ( malloco new)
• non rimane spazio nello stack quando si chiama una funzione

Entrambi sono in realtà gli stessi dell'AVR SRAM (2K su Arduino) utilizzato per entrambi (oltre ai dati statici la cui dimensione non cambia mai durante l'esecuzione del programma).

Generalmente, l'allocazione dinamica della memoria viene raramente utilizzata sulle MCU, solo poche librerie la usano in genere (una di queste è la Stringclasse, che hai citato di non usare, e questo è un buon punto).

La pila e il mucchio sono visibili nell'immagine seguente (per gentile concessione di Adafruit ):

Quindi, il problema più atteso deriva dallo overflow dello stack (ovvero quando lo stack cresce verso l'heap e trabocca su di esso, e quindi, se l'heap non è stato utilizzato a tutti, overflow nell'area dati statici della SRAM. A quel tempo, hai un alto rischio di:

• corruzione dei dati (ad es. lo stack ovewrites dati heap o statici), offrendo un comportamento incomprensibile
• corruzione dello stack (ovvero l'heap o i dati statici sovrascrivono il contenuto dello stack), generando generalmente un arresto anomalo

Per conoscere la quantità di memoria rimasta tra la parte superiore dell'heap e la parte superiore dello stack (in realtà, potremmo chiamarlo il fondo se rappresentiamo sia l'heap che lo stack sulla stessa immagine mostrata di seguito), tu può usare la seguente funzione:

int freeRam () {
  extern int __heap_start, *__brkval; 
  int v; 
  return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval); 
}

Nel codice sopra, __brkvalpunta nella parte superiore dell'heap ma è 0quando l'heap non è stato utilizzato, nel qual caso utilizziamo &__heap_startquali punti __heap_start, la prima variabile che segna la parte inferiore dell'heap; &vpunta ovviamente in cima allo stack (questa è l'ultima variabile inserita nello stack), quindi la formula sopra restituisce la quantità di memoria disponibile per lo stack (o l'heap se lo usi) per crescere.

Puoi utilizzare questa funzione in varie posizioni del codice per provare a scoprire dove questa dimensione si sta riducendo drasticamente.

Naturalmente, se mai vedi questa funzione restituire un numero negativo, allora è troppo tardi: hai già superato lo stack!

Quando scopri come individuare il file .elf generato nella tua directory temporanea, puoi eseguire il comando seguente per scaricare un utilizzo SRAM, dove project.elfdeve essere sostituito con il .elffile generato . Il vantaggio di questo output è la capacità di controllare come viene utilizzata la SRAM. Tutte le variabili devono essere globali, sono davvero tutte necessarie?

avr-objdump -S -j .bss project.elf

project.elf:     file format elf32-avr


Disassembly of section .bss:

00800060 <__bss_start>:
        ...

00800070 <measurementReady>:
        ...

00800071 <cycles>:
        ...

00800073 <measurement>:
  800073:       00 00 00 00                                         ....

00800077 <measurementStart>:
  800077:       00 00 00 00                                         ....

0080007b <timerOverflows>:
  80007b:       00 00 00 00

Si noti che ciò non mostra l'utilizzo dello stack o della memoria dinamica, come osservato da Ignacio Vazquez-Abrams nei commenti seguenti.

Inoltre a avr-objdump -S -j .data project.elfpuò essere verificato, ma nessuno dei miei programmi produce nulla con quello, quindi non posso dire con certezza se sia utile. Si suppone che la lista 'inizializzato dati (non-zero)'.

Ho sospettato per un po 'che stavo arrivando alla fine della RAM disponibile. Non penso di usare troppi stack (anche se è possibile), qual è il modo migliore per determinare quanta RAM sto effettivamente usando?

Sarebbe meglio usare una combinazione di stima manuale e usando l' sizeofoperatore. Se tutte le tue dichiarazioni sono statiche, questo dovrebbe darti un quadro accurato.

Se si utilizzano allocazioni dinamiche, è possibile che si verifichi un problema quando si inizia a deallocare la memoria. Ciò è dovuto alla frammentazione della memoria sull'heap.

Passando attraverso e cercando di risolverlo, ho problemi quando arrivo a enumerazioni e strutture; quanta memoria costano?

Un enum occupa lo stesso spazio di un int. Quindi, se hai una serie di 10 elementi in una enumdichiarazione, sarebbe 10*sizeof(int). Inoltre, ogni variabile che utilizza un'enumerazione è semplicemente una int.

Per le strutture, sarebbe più facile da usare sizeofper scoprirlo. Le strutture occupano uno spazio (minimo) pari alla somma dei suoi membri. Se il compilatore struttura l'allineamento, potrebbe essere maggiore, tuttavia ciò è improbabile nel caso di avr-gcc.

Esiste un programma chiamato Arduino Builder che fornisce una visualizzazione accurata della quantità di flash, SRAM ed EEPROM utilizzata dal programma.

Il builder Arduino fa parte della soluzione IDE Arduino CodeBlocks . Può essere utilizzato come programma autonomo o tramite l'IDE Arduino CodeBlocks.

Sfortunatamente Arduino Builder è un po ' vecchio ma dovrebbe funzionare per la maggior parte dei programmi e la maggior parte degli Arduinos, come Uno.