Arduino -Klent med ram minne.

[Glattnos]

Som jag misstänkte

Jag har använt det tillvägagångsättet för att skriva ut text och symboler på en 128x64 OLED. Atmega328 som har 32K flash har gott om utrymme för både text och symboler, beroende på hur stort själva programmet är. Jag har inte kört med någon buffer då utan skriver det som ska skrivas direkt där det ska skrivas på skärmen. Men man kan ha en buffer på 1K om man vill, man har fortfarande typ 1K SRAM över till annat.

[Icecap]

Att en ATmega inte har mycket RAM betyder ju mest att man ska tänka en aning innan man deklarerar konstanter. Ta många textrader som sodjan ger som exempel och spara i PROGMEM. Vill man sedan skriva ut en av dom kan man hämta ett tecken åt gången och skicka till displayen - men man kan också ha en liten buffer i RAM som man kopierar ut till från PROGMEM och sedan skickar till displayen.

Resultatet är att man kan ha en shitload texter och ändå använda ganska lite RAM.

[Mr Andersson]

Det är väl ingen som sagt att hela flash kopieras till SRAM?
Hela poängen med pgm_read_byte är just att kopiera från ej adresserbart minne till adresserbart minne.
Om du har tur så gör kompilatorn inga dumheter och din temporära variabel stannar i register hela tiden men den kan lika gärna hamna på stacken, som är SRAM.
Du kan inte, hur mycket du än försöker, skyffla data direkt från flash till en io-pinne.

[Icecap]

Orsaken till detta är att programminne och RAM är delade så att processorn inte kan exekvera program från RAM och att data inte kan sparas i programminne.

Detta betyder att man har högre skydd om man gör programfel - men samtidig måste det speciella instruktioner till om man ska hämta värden från programminnet till RAM.

Och vilket sätt man använder för att hämta data från programminnet beror helt på vad man behöver.

[Glattnos]

Det är väl ingen som sagt att hela flash kopieras till SRAM?

Det som jag blev förvirrad av var detta:

Alltså - har man konstanter (text, värden...) i en ATmega MÅSTE den ju - vid boot - kopiera dom från PROGMEM till RAM varför funktionen för detta redan finns i skiten.

Det här förstår jag inte riktigt. Kan någon förklara detta för mig? Varför måste konstanter kopieras till RAM vid boot?

Svaret förvirrade mig också lite:

Du (processorn) kan inte använda saker som inte finns i RAM. Det måste inte kopieras just vid boot men det är vad som sker som standard om du inte talar om något annat för kompilatorn.

Era ordval "måste" och "kan inte" var det som förvirrade. Men jag tror att jag förstår nu att ni pratar om högnivåspråk och kompilatorer medan jag tänkte på AVR generellt. I min värld är det inga problem att hålla konstanter i flash och även flytta värden och text från flash till register och utföra beräkningar utan någon större inblandning av SRAM. Ni får gärna rätta min uppfattning om den är fel men det känns som att Sodjan redan rett ut det.

Icecap: Om någon annan än du hade sagt det så hade jag inte reagerat, men enligt min erfarenhet här på forumet så har du oftast rätt(även denna gång) så jag var helt enkelt tvungen att reda ut på vilket sätt jag tänkte fel

[Mr Andersson]

Jo precis, jag menade C och C++ då det var en arduinotråd. Jag ser nu själv att det var ganska otydligt.
Det jag menade med 'om du inte talar om något annat för kompilatorn' är t.ex.
const int a = 7;
PROGMEM-macrot är just 'något annat'

Det måste inte heller hamna i ram så 'måste' var definitivt fel ordval av mig, skulle kanske sagt 'troligen' istället. Problemet med högnivåspråk är att man inte har någon direkt kontroll över registerallokering.

[sodjan]

Du måste skilja på vanliga konstanter som används löpande i koden
och (t.ex.) texter till en LCD som ju enbart läsas/kopieras då texten
på LCD behöver uppdateras.

Det Icecap (på ett kanske lite otydligt sätt ) nog syftade på var det förra,
sådana konstanter som används löpande (hela tiden) i koden. Det hanteras
med automatik. Kompilatorn lägger det i flash och lägger till en liten startkod
som kopierar det till RAM vid start/reset/power-on av AVR'en.

> att ni pratar om högnivåspråk och kompilatorer medan jag tänkte på AVR generellt.

I princip har det ju ingen betydelse. Inget högnivåspråk kan göra något som
inte en AVR kan göra "rent generellt".

[Micke_s]

Finns en anledning varför "Flat memory model" är trevlig på många andra processorer som Arm t.ex.
https://en.wikipedia.org/wiki/Flat_memory_model

Hade bara gcc varit lite intelligentare så hade inte pgm_read_byte behövs skrivas överallt.

[TomasL]

Hmm, det beror nog på hur GCC är implementerat i för resp processor, I MIPS-GCC (PIC32) så har jag för mig att det räcker med att deklarera som "const" så ligger den i programminne.

[sodjan]

Hur skulle den överleva en power of/on om den *inte* ligger i programminne (flash)?
Rent praktiskt kan det ju sedan vara implementerat genom någon "load immediate"
instruktion där värdet ligger i själva instruktionen, beror på datatyp. Sen skrivs det
till det RAM utrymme som allokerades för konstanten vid kompileringen.

Men *om* det går att läsa flash/programminne lika snabbt (och med lika enkla
instruktioner) som från vanliga register/RAM, så behöver det ju inte kopieras alls.
Men det är ju sällan fallet på mindre 8-bits processorer.

[TomasL]

Sodjan, vad jag menade är att konstanten inte kopieras till RAM, utan hämtas vid behov från PROGMEM.

[sodjan]

Ah, OK... Ja, om det är snabbt nog, om det finns stöd i
processorns arkitektur för att göra det effektivt, så går det ju.

[TomasL]

Jo, PIC32 har ju prefetch och Cache, och snurrar i minst 80 MHz, dock Flash har väl en WS har jag för mig.

[Glattnos]

> att ni pratar om högnivåspråk och kompilatorer medan jag tänkte på AVR generellt.

I princip har det ju ingen betydelse. Inget högnivåspråk kan göra något som
inte en AVR kan göra "rent generellt".

Sant, men kanske åt andra hållet. Om någon säger "det går inte" och då menar specifik med C++ och GCC så kan det ju ändå gå rent generellt med en AVR och AVR-assembler.

Kom att tänka på lite "nostalgi". Kolla dessa 9 år gamla citaten från oss(det var innan jag hade skrivit en enda rad kod och inte visste hur jag skulle börja):

2. Kan man åstakomma ett program i C som inte går att få till i Assembler?
3. Tvärt om mot 2. Kan man åstakomma ett program i Assembler som inte går att få till i C?

2. Nej, självklart inte.
Hur skulle kompilatorn i så fall kunna skapa *sin* assemblerkod ??
3. Kanske...

Dom orden har hjälp mig mycket

[sodjan]

He, lite kul... Kul med IT-arkeologi. Kollade just ett program
i miljön på jobbet och det står "DATE-WRITTEN. MARS 1986".
Det kompilerade, länkade och körde i alla fall utan problem...

(Ursäkta att det blev lite O.T...)