Du kan bruke funksjonene som følger med AVRGCC: Overvåking av stabelbruk

Funksjonen var ment å kontrollere stakkbruken, men det den rapporterer er faktisk RAM som aldri har blitt brukt (under henrettelse). Det gjøres ved å "male" (fylle) RAM-en med en kjent verdi (0xC5), og deretter sjekke RAM-området og telle hvor mange byte som fremdeles har samme opprinnelige verdi.
Rapporten viser RAM som ikke har vært brukt (minimum ledig RAM) og derfor kan du beregne maks RAM som er brukt (Total RAM - rapportert RAM).

Det er to funksjoner:

• StackPaint utføres automatisk under initialisering og "maler" RAM-en med verdien 0xC5 (kan endres om nødvendig).

• StackCount kan ringes når som helst for å telle RAM som ikke har blitt brukt.

Her er et eksempel på bruk. Gjør ikke mye, men er ment å vise hvordan du bruker funksjonene.

  // ------------ -------------------------------------------------- --------------- ekstern uint8_t _end; ekstern uint8_t __stack; ugyldig StackPaint (ugyldig) __attribute__ ((naken)) __attribute__ ((seksjon (".init1"))); ugyldig StackPaint ( ugyldig) {# if 0 uint8_t * p = &_end; mens (p < = &__stack) {* p = 0xc5; p ++; } #else __asm ​​flyktig ("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;
mens (* p == 0xc5 && p < = &__stack) {p ++; c ++; } returner c;} // ------------------------------------------- ---------------------------------- ugyldig oppsett () {Serial.begin (9600);} ugyldig sløyfe ( ) {// legg hovedkoden din her for å kjøre gjentatte ganger: Serial.println (StackCount (), DEC); // kaller StackCount () for å rapportere ubenyttet RAMdelay (1000);}  

Hovedproblemene du kan ha med minnebruk ved kjøretid er:

• intet tilgjengelig minne i haugen for dynamiske tildelinger ( malloc eller ny)
• ingen plass igjen på stacken når du ringer til en funksjon

Begge er faktisk samme som AVR SRAM (2K på Arduino) brukes til begge deler (i tillegg til statiske data som størrelsen aldri endres under gjennomføring av programmet).

Generelt brukes dynamisk minnetildeling sjelden på MCU-er, bare noen få biblioteker bruker den vanligvis (en av dem er String -klassen, som du nevnte at du ikke bruker, og det er et godt poeng).

Stakken og dyngen kan sees på bildet nedenfor (med tillatelse fra Adafruit):

Derfor kommer det mest forventede problemet fra stack overløp (dvs. når bunken vokser mot dyngen og renner over den, og deretter - hvis bunken ikke ble brukt i det hele tatt - overflyter på den statiske datasonen til SRAM. tiden har du høy risiko for enten:

• datakorrupsjon (dvs. stack ovewrites bunken eller statiske data), noe som gir deg uforståelig oppførsel For å vite hvor mye minne som er igjen mellom toppen av bunken og toppen av bunken (faktisk kan vi kalle det bunnen hvis vi representerer både bunken og bunken på det samme bildet som vist nedenfor), kan bruke følgende funksjon:

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

  I koden ovenfor peker __brkval til toppen av bunken, men er 0 når bunken ikke har blitt brukt, i så fall bruker vi &__heap_start som peker til __heap_start , den første variabelen som markerer bunnen av bunken; &v peker selvfølgelig til toppen av bunken (dette er den siste variabelen som ble presset på bunken), og derfor returnerer formelen ovenfor mengden minne som er tilgjengelig for stakken (eller bunken hvis du bruker den ) for å vokse.

  Du kan bruke denne funksjonen på forskjellige steder i koden din for å prøve å finne ut hvor denne størrelsen blir dramatisk redusert.

  Selvfølgelig, hvis du noen gang ser dette funksjon returnerer et negativt tall så er det for sent: du har allerede overfylt bunken!

Når du finner ut hvordan du finner den genererte .elf-filen i den midlertidige katalogen din, kan du utføre kommandoen nedenfor for å dumpe en SRAM-bruk, der project.elf skal erstattes med den genererte . selv fil. Fordelen med denne utgangen er muligheten til å inspisere hvordan SRAM-en din blir brukt. Må alle variablene være globale, er de egentlig alle nødvendige?

  avr-objdump -S -j .bss project.elfproject.elf: filformat elf32-avrDemontering av seksjon .bss: 00800060 <__bss_start>: ... 00800070 <measurementReady>: ... 00800071 <cycles>: ... 00800073 <measurement>: 800 073: 00 00 00 00 .... 00800077 <measurementStart>: 800 077: 00 00 00 00 .... 0080007b <timerOverflows>: 80007b: 00 00 00 00  

Legg merke til at dette ikke viser bruk av stakk eller dynamisk minne, slik Ignacio Vazquez-Abrams bemerket i kommentarene nedenfor.

I tillegg en avr -objdump -S -j .data project.elf kan sjekkes, men ingen av programmene mine sender ut noe med det, så jeg kan ikke vite helt sikkert om det er nyttig. Den skal liste '' initialiserte (ikke-null) data ''.

Jeg mistenkte en stund at jeg kom til slutten av tilgjengelig RAM. Jeg tror ikke jeg bruker for mye stack (selv om det er mulig). Hva er den beste måten å bestemme hvor mye RAM jeg faktisk bruker?

Det er best å bruke en kombinasjon av manuell estimering og ved å bruke operatøren sizeof . Hvis alle erklæringene dine er statiske, bør dette gi deg et nøyaktig bilde.

Hvis du bruker dynamiske tildelinger, kan det hende du får et problem når du begynner å distribuere minnet. Dette skyldes minnefragmentering på dyngen.

Når jeg går gjennom og prøver å finne ut av det, har jeg problemer når jeg kommer til enums og strukturer; hvor mye minne koster de?

En enum tar like mye plass som en int . Så hvis du har et sett med 10 elementer i en enum -erklæring, vil det være 10 * sizeof (int) . Dessuten er hver variabel som bruker en oppregning ganske enkelt en int.

For strukturer ville det være enklest å bruke sizeof for å finne ut av det. Strukturer opptar et (minimum) rom som tilsvarer summen av medlemmene. Hvis kompilatoren strukturerer justering, kan det være mer, men dette er lite sannsynlig i tilfelle avr-gcc .

Det er et program som heter Arduino Builder som gir en fin visualisering av mengden flash, SRAM og EEPROM som programmet ditt bruker.

Arduino-byggherren utgjør en del av CodeBlocks Arduino IDE -løsningen. Den kan brukes som enten et frittstående program eller gjennom CodeBlocks Arduino IDE.

Dessverre er Arduino Builder litt gammel, men den skal fungere for de fleste programmer og de fleste Arduinos, som f.eks. Uno.