De fleste Arduinos (som Uno eller Nano) har svært få RAM, så du må først sørge for at du aldri tildeler for mye minne. Også dynamisk tildeling av minne kan føre til haugfragmentering (heap er den delen av minnet, der dynamisk tildeling skjer).

I de fleste tilfeller vil du tildele minne av forskjellige størrelser (for eksempel matriser av forskjellige størrelser) eller bare forskjellige objekter (med hver sin størrelse) (!!! Dette er nøkkelpunktet her). Så skal du slette noen av disse objektene. Det vil skape hull inne i minnet. De kan fylles igjen med gjenstander med samme eller mindre størrelse. Etter hvert som tiden går og mer tildeling og sletting skjer, har disse hullene en tendens til å bli mindre, opp til det punktet, hvor ingen av dine nye som tildeler objekter kan passe der. Det minnet er da ubrukelig. Dette fenomenet kalles haugfragmentering.

Disse hullene vises naturlig, også på en PC. Men det er to viktige forskjeller:

1. Arduino har så lite RAM, at hullene kan fylle opp minnet veldig raskt.

2. Mens PC-en har et operativsystem som styrer RAM-en (defragmenterer den eller legger ubrukte ting bort i en personsøk / byttefil), har ikke Arduino et operativsystem. Så ingen holder øye med den virkelige tilgjengelige RAM-en, og ingen rydder opp i minnet en gang i blant.

Det betyr ikke at du ikke kan bruke dynamisk tildeling på en Arduino , men det er veldig risikabelt, avhengig av hva du gjør akkurat og hvor lenge programmet skal fungere uten å mislykkes.

Tatt i betraktning denne store advarselen, er du veldig begrenset med hvordan du bruker dynamisk tildeling. Å gjøre det for mye vil resultere i veldig ustabil kode. De gjenværende mulighetene, der det kan være trygt å bruke den, kan også enkelt gjøres med statisk tildeling. Ta for eksempel køen din, som i utgangspunktet er en koblet liste. Hvor er problemet med å tildele en rekke QueueItem s i starten. Hvert element får en måte å avgjøre om det er gyldig. Når du oppretter et nytt element, velger du bare det første elementet i matrisen, som har et ikke-gyldig element, og setter det til ønsket verdi. Du kan fortsatt bruke dataene via pekepinnene, akkurat som før. Men nå har du det med statisk tildeling.

Du kan finne ut at koden ser styggere ut på den måten, men du må tilpasse deg plattformen du bruker.

Merk, at dette ikke gjelder når du skal opprette bare objekter med samme størrelse . Deretter vil ethvert slettet objekt etterlate et hull der ethvert nytt objekt kan passe inn. Kompilatoren bruker det faktum. Så i så fall er du trygg. Akkurat hvert objekt, som du dynamisk oppretter i programmet ditt, må ha nøyaktig samme størrelse. Det inkluderer selvfølgelig også objekter som er opprettet i forskjellige biblioteker eller klasser. (Av denne grunn kan det fremdeles være et dårlig designvalg, ettersom du eller andre (hvis du vil publisere koden din) kanskje vil koble biblioteket ditt med en annen kode)

En annen måte å være trygg på er å bare opprette og slette objekter i lukkede sykluser, noe som betyr at et opprettet objekt må slettes før neste objekt opprettes. Selv om det ikke passer for applikasjonen din.

På større mikrokontrollere, for eksempel ikke-Arduino-kortene med ESP32, har mye mer minne. Dermed er ikke bruken av dynamisk tildeling så dårlig for dem. Selv om du fremdeles ikke har et operativsystem for å administrere RAM.

Dynamisk tildeling frarådes vanligvis i innebygde applikasjoner fordi du ikke kan garantere at du ikke overskrider (prøver å tildele mer enn) tilgjengelig minne. Statisk tildeling vil generelt ha denne garantien, selv om feil i minnet fremdeles kan være mulig.

I tillegg er det langt færre tjenester eller verktøy tilgjengelig for automatisk å administrere og passe på minnet for deg. Enhver tjeneste som gjør det, vil forbruke beregningsressurser.

Dette betyr at du iboende oppretter en mekanisme på enheten din som vil føre til et minne (heap) overløp og mulig udefinert oppførsel (UB). Dette gjelder selv om koden din er feilfri og ikke har minnelekkasjer.

I ikke-kritiske applikasjoner, leting, læring og prototype kan dette ikke være viktig.

Tenk at udefinert oppførsel uten nøye vurdering kan føre til maskinvarefeil og usikker ytelse, for eksempel hvis enheten konfigurerer GPIO på nytt gjennom en feilaktig skriving til de riktige registrene under et krasj.

For det første, fikse biblioteket ditt

Som bemerket av @crasic, anbefales dynamisk minnetildeling vanligvis ikke for innebygde systemer. Det kan være akseptabelt for innebygde enheter som har større mengde ledig minne - innebygd Linux brukes ofte, for eksempel, og alle Linux-apper / -tjenester vil ha en tendens til å bruke dynamisk minnetildeling - men på små enheter som en Arduino er det ganske enkelt ingen garanti for at dette vil fungere.

Biblioteket ditt illustrerer en vanlig årsak til at dette er et problem. Funksjonen enqueue () oppretter en ny QueueItem () , men kontrollerer ikke at tildelingen lyktes. Resultatet av mislykket tildeling kan enten være et C ++ bad_alloc unntak, eller det kan være å returnere en nullpeker, som når du refererer til det vil gi et unntak for systemminnetilgang (SIGSEGV-signal i Linux, for eksempel) . Det er nesten universelt i Linux- og Windows-programmering å ignorere minnetildelingsfeil (som oppmuntret av de fleste lærebøker), fordi den enorme mengden ledig RAM og eksistensen av virtuelt minne gjør dette veldig usannsynlig, men dette er uakseptabelt i innebygd programmering.

Mer generelt, som @crasic sier, kan minnefragmentering la selv ikke-buggy-kode ikke kunne allokere minne. Resultatet vil være en mislykket fordeling av minne, men koden vil i det minste vite at dette har skjedd og vil sannsynligvis kunne fortsette.

Men bedre, bruk en FIFO-kø i fast størrelse i stedet

Koden din er avhengig av dynamisk tildeling for å legge til og fjerne elementer i en kø. Det er fullt mulig (og like enkelt kodemessig) å opprette en matrise med fast størrelse for køen, så de forskjellige feilmodusene for dynamisk tildeling gjelder ganske enkelt ikke. Et element som skal settes i kø kopieres ganske enkelt til neste gratis kø-spor, og et kø-spor merkes gratis når det er brukt. (Ikke glem å bruke en mutex når du legger til og fjerner gjenstander fra køen, fordi det ofte blir ringt til å legge til og fjerne fra forskjellige steder.)

Køen kan lages uansett hvilken størrelse du føler er passende ( som tillater hvor mye RAM du har). Med en fast størrelse er du tvunget til å ta en designbeslutning om hva som skal skje hvis køen renner over - sletter du de eldste dataene for å gi plass til den nye verdien, eller ignorerer du den nye verdien? Dette kan virke som en uvelkommen ny funksjon, men det er en god ting, fordi det tredje alternativet du har for øyeblikket, er at koden din går "Aaaarrggghhh jeg ikke vet hva som skal gjøres!" og krasjer dødelig, og det ønsker vi ikke egentlig.

Jeg legger til dette ikke så mye å legge til svaret som å legge til noen virkelige verdensimplikasjoner for de som kan være nede i dette kaninhullet. Det er hyggelig å snakke om hva som kan skje teoretisk, men en ny programmerer kan fortsatt være fristet til å tenke at han kan tenke over disse begrensningene og fremdeles gjøre noe nyttig. Her er noen virkelige verdensprater om hvorfor det er tåpelig selv om du er i stand.

La oss si at vi utvikler kode på en Arduino UNO. Vi har 2K RAM å jobbe med. Vi har en klasse som laster inn en liste med navn, kanskje det er en bygningsadgangsenhet eller noe. Uansett, denne hypotetiske klassen har et navnefelt for å lagre noens navn. Og vi bestemmer oss for å bruke String-klassen til å holde navnet som en String.

La oss si at etter at programmet vårt er der og gjør hva det gjør, er det 500 byte igjen til denne listen over objekter, hver med et navnefelt som kan være av ulik lengde. Så vi løper fint sammen i årevis med et mannskap på 14 eller 15 personer med en gjennomsnittlig navnelengde på 30 tegn eller så.

Men en dag registrerer en ny fyr seg. Og navnet hans er veldig langt. La oss si at det tar 100 tegn. Selv om vi er smarte kodere og bare har en kopi av denne strengen i minnet, har vi den der og plutselig passer den ikke. Nå mislykkes et program som har fungert i årevis plutselig. Og ingen vet hvorfor.

Så løsningen er lett, ikke sant? Håndheve en maksimal grense for lengden på navnet. Noen enkle koder som sjekker navnelengden, og vi kan skrive et flott stykke som fremdeles tillater variabelnavnet og ikke lar deg opprette en ny bruker hvis det er mindre enn så mye igjen. Virker enkelt nok, men så gifter Becky i regnskap seg og hennes etternavn endres fra Smith til Wolfeschlegelsteinhausenbergerdorff, og plutselig bryter programmet vårt uten grunn.

Så løsningen er enkel, ikke sant? Vi håndhever en maksimal lengde, og vi vil sørge for å reservere nok minne til hvert objekt som det har råd til å ha navnet på maksimal lengde. Og det er noe vi gjør mest effektivt uten dynamisk tildeling siden vi allerede vet størrelsen på objektet.

Jeg hører hva du sier, "men Delta-G, hvis vi har alle de korte navnene i der, hvorfor skal vi kaste bort alt det minnet på dem når vi ikke trenger det. La oss bare spare plass i lang tid hvis vi har lenge. " Og jeg liker tankene dine, dette er god tenkning. Men det hjelper ikke noe å spare det minnet. Hvis du sparer noen, hva skal du gjøre med det? Hvis programmet ditt bruker det, er det ikke lenger plass til det lengre tilfellet, og plutselig må du håndheve en enda kortere maksimal lengde for å imøtekomme den bruken.

Si for eksempel at vi har 500 byte rom, og vi håndheve en maksimal lengde på 50 byte for 10 brukere. Og la oss si at når navnene er korte, vil vi la programmet bruke noe av den lagrede plassen. Hvis programmet kan angripe 100 byte i det rommet når navnene er korte, hvorfor skulle ikke den samme situasjonen skje med lange navn? Så egentlig siden programmet kan bruke alt bortsett fra 400 byte, er det egentlig bare 400 byte rom, og vi må håndheve et maksimum på 40 byte for 10 brukere eller 50 byte for 8.

Siden du skal må gjøre det offeret uansett, da er det bare fornuftig å fjerne arbeidet med dynamisk tildeling og bare gjøre ting faste størrelser eller bruke buffere med fast størrelse.

Hvis vi hadde en PC med gigabyte minne, ville vi ikke tenker ikke engang på dette. Men på en Arduino UNO med 2K byte minne kan det bli et stort problem veldig raskt.

Det andre problemet er at disse feilene er så lumske. Hvis feil uten minne bare forårsaket et enkelt krasj og tingen ikke lenger fungerte, ville det ikke være nesten så skummelt. Men det er ikke slik ut av minnefeil fungerer på en mikrokontroller. Alt kommer an på hvordan ting ordnes i minnet av kompilatoren.

Disse feilene manifesterer seg ofte som noe som ser ut til å fungere mesteparten av tiden, men har noen morsomme feil som ingen kan forklare. Kanskje det bare er et problem hvis noen har et navn som er nøyaktig 26 tegn langt og prøver å åpne døren på en onsdag. Eller kanskje problemet bare oppstår hvis Becky logger på umiddelbart etter Bob. Kanskje det bare gnister tre bokstaver på skjermen, men bortsett fra at alt fungerer. Kanskje med et annet navn endret som plutselig blir til at låsen vår åpner for alle. Det er ingen gjetting eller forklaring på grunn av minnefeil. Så vi må være veldig forsiktige med å unngå til og med den eksterne muligheten for å støte på en.

Og det er derfor vi unngår å bruke dynamisk tildeling på små mikrokontrollere. På slutten av dagen er det ingenting du kan spare med det, og selv om du kan konsekvensene av å få noe litt galt er veldig frustrerende. Med denne typen programmer må du nesten alltid ende opp med å håndheve en slags grense på alt, og når du først håndhever grenser, er det ikke lenger bruk for dynamisk tildeling.

Som noen som er interessert i hvordan maskinvare muliggjør databehandling, er det faktisk en rekke fascinerende fakta om hvorfor dyngen er farlig på innebygde systemer utover bare å ikke ha mye RAM. De fleste problemer du vil støte på med et Arduino eller lignende system, er ikke å overskride RAM-størrelsen med variabler, men fra minnefragmentering. Dette er en bivirkning av hvordan dyngen tildeler minne i innebygde systemer, som vanligvis ikke har en minnebehandler.

Haugen på enkle enheter som Arduino er det som er nærmest det som er kjent som et "base and bounds" -system (teknisk sett er det stack-allokert, som også kan slås opp hvis du er nysgjerrig). Minne tildeles et sted, og blir deretter merket med informasjon om hvor det er i minnet og hvor mye det har. Når den blir distribuert, blir denne regionen fri igjen. Problemer oppstår fordi dette rommet må være sammenhengende . Tenk på tildelt minne som en matrise (som det i utgangspunktet er); det er ingen logikk å si "oops, det er et annet objekt her, hopp over 37 byte og fortsett.

Hvis du foretar gjentatte tildelinger, deles minnestykker ut og beveger seg lenger opp i haugen, siden to deler av minnet kan tydeligvis ikke oppta samme plass. Minne kan bli tilgjengelig igjen hvis noe av det blir frigjort, men det gjør at resten av det "flyter" høyere opp på bunken, midt i minneplassen (hvis du noen gang har spilt et bestemt 3D-voxel-byggespill, tenk å bryte ut en del av en trestamme). Ytterligere tildelinger vil da fylle ut deler av de ryddede områdene i de delte delene (eller på toppen av den brukte haugen, hvis de ikke passer inn de ryddede områdene), men med mindre det nylig tildelte minnet er nøyaktig samme størrelse som det som ble fjernet, dannes hull der ledig minne er for liten til å passe til noe annet. Til slutt kan det være mye ledig minne, men ingenting av det kan brukes siden det ikke er sammenhengende seksjoner, selv om det er en haug med byte her og der.

Som nevnt er en løsning å sikre at alt allokert minne er av samme størrelse, men hjelper kanskje ikke når så mye av Arduino-systemet bruker dynamisk minne alene. Dette er hovedsakelig alt å gjøre med strenger (spesielt returnere ing dem, sammenkobling eller innstilling av hverandre), men det kan godt være andre verktøy som bruker det, noe som gjør feilsøking seg farlig. Alt som lar deg "registrere" en tilbakeringing, lytter eller brukerfunksjon, vil også mest sannsynlig bruke dynamisk minne, og jeg forestiller meg at et WiFi-bibliotek med "skann" -funksjonalitet eller et filsystembibliotek (for eksempel SD-kort) sannsynligvis også vil gjøre det.

Mange av de innebygde strengbibliotekene lager faktisk fullkopier av heapminne ved retur eller definisjon, så selv om den opprinnelige strengen deretter blir fordelt automatisk av String-biblioteket når variabelen går utenfor omfanget, var det kort to kopier av elementet på dyngen og forårsaket fragmentering (siden den andre ble støtet frem av den første, etterlot et hull når den første slettes, men den andre forblir).

Det ville sannsynligvis være trygt hvis du bruk dynamisk minnetildeling i svært små mengder og sjelden, så lenge det ikke er noen måter du kan tegne det maksimale tildelte minnet på en måte som vil forhindre tildeling av et nytt stykke, men dette er riktignok irriterende å teste.

Det finnes en ikke så perfekt løsning der du bruker dyngen som noe som en bunke, og du tildeler alt ekstra stort riperom mens du kjører en oppgave, og deretter fordeler den før du gjør neste element eller på annen måte tildel minne igjen. Dette lar deg håndtere problemer som vil ta mer minne enn du ville hatt hvis du brukte et globalt for hver, men igjen kan dette også gjøres hvis du bare legger den delen av koden med krøllete parenteser og bruker en lokal matrise (som setter den på faktisk bunken). Merk at noen systemer (som ESP8266, som kan programmeres med Arduino-rammeverket, men absolutt ikke er en Arduino), kan ha begrensninger på stakkstørrelsen, så dynamisk minne kan faktisk være nødvendig i noen tilfeller.

Interessant, til tross for at bunken er stablet tildelt, er den faktiske bunken immun mot dette problemet. Dette er på grunn av hvordan returorientert programmering fungerer. Enhver funksjonssamtale eller minnetildeling på bunken (som, som du vet, gjøres ved å definere en variabel på vanlig måte) blir alltid plassert på toppen, og når den returnerer eller går utenfor omfanget, blir den slettet. Siden det ikke er noen måte å slette ting fra midten av bunken, er det aldri noen fragmentering, og dermed er ledig minne alltid tilgjengelig så lenge du ikke overskrider fysiske ressurser. Stableallokering mislykkes dermed bare når det tildelte minnet slutter å oppføre seg som en stabel (som dessverre ofte er).

Som et siste notat bruker moderne datamaskinoperativsystemer en mye mer avansert teknikk som kalles personsøk, som løsningen din nærmer seg (kjernen kan ha og bruker unntak fra denne regelen, siden det er tidskritisk og personsøk er litt tregere, men det er en grunn at koding av kjernen er så møysommelig). I personsøk er all minnet spesielt tildelt i like store blokker, og blokker kan deles ut for best mulig å møte minneforespørsler. Blokkene kan imidlertid ordnes i hvilken som helst rekkefølge og trenger ikke engang å være fysisk tilstøtende i minnet. Dette betyr at det ikke er noen måte at et minne ikke kan tildeles, ettersom biter alltid er like store (og dermed alltid passer inn i hullene). Det er minnehåndteringsenheten som utfører resten av magien ved å gjøre alle de små blokkene til det som virker som et større minneutvidelse (og også ved å håndtere minneeierskap, men det er ikke relevant her).

Dessverre krever personsøk maskinvarestøtte, mye mer minne for å holde sidetabellen og OS-støtte (eller i det minste en slags manager som med jevne mellomrom kan sparke inn og omorganisere ting for deg). Ingen av disse er til stede i en Arduino, og ville faktisk forårsake problemer for den slags sanntidskoden som opprinnelig var ment å kjøre på en Arduinos CPU. Husk at Arduino ble bygget rundt en liten, billig chip som tilfeldigvis hadde et åpen kildekode-programmeringsgrensesnitt og kompilator (og noen få andre prosjekter som hadde koden og IDE "lånt"), og var egentlig ikke designet for den slags bruker som vi ofte legger det til (det er grunnen til at dataprogrammering ikke er helt det samme som innebygd utvikling; koderen må tenke på en mye mer lavt nivå enn normalt, og det er grunnen til at C / C ++ ofte brukes - det er noe nærmere Assembly enn de fleste andre språk, selv om C ++ kommer vekk fra det). Selv arkitekturen til AVR-prosessoren er ganske fortellende om den faktiske brukssaken: Høyhastighets sanntidsbehandling. Minne- og databussene er uavhengige, slik at kode kan kjøres selv når den streamer data fra RAM, EEPROM eller en I / O-pinne.

Det er en nyttig gratis guide til operativsystemdesign kalt "Operating Systems: Three Easy Pieces, "som er kilden til noe av det jeg lærte og deretter skrev her. Siden forfatterne ikke vil ha kapitlene tilknyttet direkte, og destinasjonssiden har en rekke falske lenker til tilfeldige bøker, kan jeg ikke koble den direkte, men du kan alltid slå opp den hvis du er nysgjerrig. Du vil selvfølgelig ha emnene om minnestyring, og kapitlene i seg selv er lenket i delen med farget tabell.