Förutom hastigheten & andra funktioner som andra redan har nämnt, kan köra kod från RAM vara användbart i bootloaders där du behöver omprogrammera din mikros blixt - du kan inte köra kod från flash som du är i mittenatt radera omprogrammering av &.

Jag tittade inte på databladet för det mikroet.Det är emellertid ofta fallet i denna situation att hämtning från RAM är snabbare än att hämta från blixten som programminnet implementeras från.

Fördelen med blixt är att stora mängder kan vara relativt billiga.Microcontroller-tillverkare lägger därför ibland mycket flash på ett chip och ger sedan ett mer begränsat RAM-utrymme som koden kan köras från.Detta gör det möjligt att kopiera tidskritiska rutiner till RAM och sedan köra dem därifrån.

Kompilatoromkopplaren som du refererar till fungerar antagligen med länkaren och flaggar den delen av blixt som ska kopieras till RAM av kompilatorn körtidskod som körs från återställning.Olika implementeringar varierar beroende på detaljerna.

När du vill köra i RAM eftersom det är snabbare beror det vanligtvis på att RAM är SRAM på chipet.Detta är en knapp resurs som du förmodligen vill ha för data som kräver läs- / skrivåtkomst.

Att använda den för kod när du redan har koden i ROM / flash innebär att du behöver X-mängd flash och ytterligare X-minne RAM.

Det kräver också en extra kopieringsfas vid start eller när du vill köra den, även om den mestadels är obetydlig.

Traditionellt löses detta med en instruktionscache, men i en mikrokontroller kan det vara meningsfullt att behålla den interna SRAM-generiken, eftersom du inte använder en mikrokontroller eftersom du vill ha den snabbaste körhastigheten.

Det finns också ett tillförlitlighetsproblem - kodkörning i faktisk ROM är svår att ändra med buggykod.

Förutom alla bra svar:

Varför skulle jag inte alltid köra från RAM om bara fördelen är ökad hastighet?

Eftersom du i ett inbäddat system vanligtvis inte har den nödvändiga mängden RAM.Till exempel en STM32 med 32 kB eller RAM och 512 kB EEPROM.För att kunna köra hela programmet i RAM behöver du en RAM-storlek som är större än EEPROM.

Andra svar verkar inte ha diskuterat mycket energiförbrukning, vilket du specifikt frågade om.

Svaret är att det beror något på mikrokontrollern, men ofta kan körning från RAM minska energiförbrukningen eftersom det kräver mindre energi för att läsa instruktioner från RAM än från flashminne.

En typisk användning skulle vara att köra en "strömsparläge" med låg effekt från RAM, med flashminnet avstängt.Strömförbrukningen minskar inte bara, men om mikrokontrollern behöver vakna snabbt (t.ex. som svar på ett externt avbrott) är det ingen fördröjning medan flashminnet startas igen.

Vissa delar, till exempel några av Atmel SAM-serien, har speciellt extra RAM-minne med låg effekt som kan användas för detta ändamål.Detta gör att en liten mängd kod kan laddas till det speciella RAM-minnet, medan huvuddelen av tillgängligt RAM-minne och alla andra minnen stängs av och mikrokontrollern går in i ett djupt viloläge.

Förutom de potentiella hastighetsfördelarna som nämns av andra, är RAM-kod också dynamisk och kan modifieras direkt med någon skräddarsydd kod i FLASH efter behov.

Detta kan vara så enkelt som att ändra några parametrar eller kan vara hela hanteringsrutiner som laddas upp på distans.

Att köra kod från RAM går betydligt snabbare än att köra den från flashminnet. De flesta processorer är kraftigt optimerade för snabbast möjliga RAM-åtkomst, och till och med det snabbaste flashminnet når bara en bråkdel av RAM-hastigheten.

Tänk dock på att det tar tid att flytta koden från flash till RAM. Om koden exekveras bara en gång behöver du bara läsa den en gång, och därför skulle du faktiskt tappa tid för att kopiera den till RAM först istället för att köra den direkt. Om kod exekveras ibland (så att kopiera den till RAM skulle öka körningen andra gången den kallas), men systemet är i allmänhet inaktivt, då skulle du köra den koden snabbare genom att kopiera den till RAM, men ingen bryr sig eftersom systemet har tillräckligt med tid att spendera.

Så sådana optimeringar är bara värda ansträngningen, om koden körs ofta, och du har mätt att den är en kvävningspunkt i systemet.

Å andra sidan måste RAM aktivt lagra data medan flashminnet inte gör det, så den totala strömförbrukningen ökar om RAM behöver hållas aktivt. Detta är dock bara relevant om RAM-minnet annars inte används alls, men de flesta moderna system kommer - på ett eller annat sätt - att använda det tillgängliga RAM-minnet redan och därför redan hålla det aktivt.

Det finns två mycket vanliga skäl att köra kod från RAM:

1. Vissa mikroprocessorer kan inte köras från blixt under blixtprogrammering - även om många kan göra det så länge som koden är i ett annat block än den blixt som skrivs.Flash-skrivningar kan omprogrammera applikationen (boot-loader case) eller när flash används för att lagra icke-flyktig programinformation (konfiguration, kalibrering etc.)

2. På många mikroprocessorer är RAM mycket snabbare än blixt.För dessa enheter kan små hastighetskritiska rutiner köras från RAM, men RAM har vanligtvis mycket kortare än flash.

En annan användningsfas för RAM-exekveringssäkerhet mot slumpmässiga bitflips.Vi använder den här modellen på vår lilla kubesats eftersom huvudkortet har en ECC-ram som tål bitlips på grund av strålning.Hela operativsystemet laddas in i ram eftersom en ramdisk vid start körs helt i en ECC-miljö.

Blixten är inte ECC-skyddad (standard från micro SD-kort) men vi har andra metoder för att kontrollera korruption (flera bilder, kontrollsummor etc.)