Electrokit Buggfix Plus
Aktuellt datum och tid: 11.42 2018-11-15

Alla tidsangivelser är UTC + 1 timme




Svara på tråd  [ 80 inlägg ]  Gå till sida Föregående  1, 2, 3, 4, 5, 6  Nästa
Författare Meddelande
InläggPostat: 16.05 2018-04-04 

Blev medlem: 20.01 2009-10-29
Inlägg: 1453
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.


Logga in för att visa de filer som bifogats till detta inlägg.


Upp
 Profil  
 
InläggPostat: 18.10 2018-04-04 
Användarvisningsbild

Blev medlem: 14.52 2005-01-10
Inlägg: 23209
Ort: Kristinehamn
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.


Upp
 Profil  
 
InläggPostat: 10.02 2018-04-05 

Blev medlem: 21.06 2011-01-29
Inlägg: 655
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.


Upp
 Profil  
 
InläggPostat: 10.44 2018-04-05 
Användarvisningsbild

Blev medlem: 14.52 2005-01-10
Inlägg: 23209
Ort: Kristinehamn
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.


Upp
 Profil  
 
InläggPostat: 12.29 2018-04-05 

Blev medlem: 20.01 2009-10-29
Inlägg: 1453
Mr Andersson skrev:
Det är väl ingen som sagt att hela flash kopieras till SRAM?
Det som jag blev förvirrad av var detta:
Glattnos skrev:
Icecap skrev:
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:
Mr Andersson skrev:
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 :)


Upp
 Profil  
 
InläggPostat: 16.25 2018-04-05 

Blev medlem: 21.06 2011-01-29
Inlägg: 655
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.


Senast redigerad av Mr Andersson 16.28 2018-04-05, redigerad totalt 1 gång.

Upp
 Profil  
 
InläggPostat: 16.28 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 36908
Ort: Söderköping
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".


Upp
 Profil  
 
InläggPostat: 16.43 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 21.31 2005-12-15
Inlägg: 6241
Ort: Malmö
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.


Upp
 Profil  
 
InläggPostat: 17.29 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 22.54 2006-09-23
Inlägg: 30212
Ort: Borås
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.


Upp
 Profil  
 
InläggPostat: 17.37 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 36908
Ort: Söderköping
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.


Upp
 Profil  
 
InläggPostat: 17.41 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 22.54 2006-09-23
Inlägg: 30212
Ort: Borås
Sodjan, vad jag menade är att konstanten inte kopieras till RAM, utan hämtas vid behov från PROGMEM.


Upp
 Profil  
 
InläggPostat: 17.46 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 36908
Ort: Söderköping
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.


Upp
 Profil  
 
InläggPostat: 17.49 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 22.54 2006-09-23
Inlägg: 30212
Ort: Borås
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.


Upp
 Profil  
 
InläggPostat: 18.15 2018-04-05 

Blev medlem: 20.01 2009-10-29
Inlägg: 1453
sodjan skrev:
> 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):
Glattnos skrev:
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?
sodjan skrev:
2. Nej, självklart inte.
Hur skulle kompilatorn i så fall kunna skapa *sin* assemblerkod ??
3. Kanske...
Dom orden har hjälp mig mycket :D


Upp
 Profil  
 
InläggPostat: 19.29 2018-04-05 
EF Sponsor
Användarvisningsbild

Blev medlem: 15.29 2005-05-10
Inlägg: 36908
Ort: Söderköping
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...)


Upp
 Profil  
 
Visa inlägg nyare än:  Sortera efter  
Svara på tråd  [ 80 inlägg ]  Gå till sida Föregående  1, 2, 3, 4, 5, 6  Nästa

Alla tidsangivelser är UTC + 1 timme


Vilka är online

Användare som besöker denna kategori: Inga registrerade användare och 6 gäster


Du kan inte skapa nya trådar i denna kategori
Du kan inte svara på trådar i denna kategori
Du kan inte redigera dina inlägg i denna kategori
Du kan inte ta bort dina inlägg i denna kategori
Du kan inte bifoga filer i denna kategori

Sök efter:
Hoppa till:  
   
Drivs av phpBB® Forum Software © phpBB Group
Swedish translation by Peetra & phpBB Sweden © 2006-2010