[C] avr progmem array probleem

Dat klopt, precies zoals ik al zei: Je moet voor functies die pointers gebruiken twee versies maken.
Een met een normale pointer en eentje die een PROGMEM pointer type kan gebruiken.
En de compiler zegt helemaal niks, alleen de code werkt niet.
Lekker onhandig......

O ja: Die 8051 met zijn 3 memory spaces is verrekte handig.
De Keil 8051 compiler die ik ooit gebruikt heb deed precies wat je verwachte en genereerde WEL correcte code zodat je code deed wat er staat. Het kan dus wel degelijk.

Het KAN wel, maar er zit een prijskaartje aan. Runtime. AVR-GCC bouwers hebben er voor gekozen om jou die prijs niet telaten betalen.

Zelfs runtime kun je dit niet oplossen, de pointer heeft maar een 16-bits size. Hoe wil je aan die pointer zien welke space het moet zijn?

Het enige wat je kunt doen is de helft van je flash en ram size opofferen zodat <32k => ram >32k =>flash. Dus het hoogste bit misbruiken of zo.

De meeste avr's hebben veel minder dan 64k adressruimte nodig. ATMega32 heeft 32k flash en 2k sram. Dus die kunnen in principe best in dezelfde adressruimte. Maar atmel heeft ervoor gekozen om de adressen te laten overlappen zodat je verschillende instrukties moet gebruiken.
Harvard betekent alleen dat je aparte bussen hebt zodat je sneller kunt werken. Dus niet perse overlappende adressen. ARM cortex M3 heeft ook harvard, en toch een enkele adressruimte. Dus dat kan best wel. Zie intro to arm cortex m3.pdf.

En de compiler zegt helemaal niks, alleen de code werkt niet.
Lekker onhandig......

Het zit meer richting assembly. Dat iets door een assembler heen komt, zegt ook niks over het functioneren. Maar ik weet het, zelf nadenken mag anno 2015 niet meer...

O ja: Die 8051 met zijn 3 memory spaces is verrekte handig.

Ik snap hoe het zo gekomen is, maar handig is het niet. Een stuk RAM (het merendeel...) waar je alleen een byte naartoe of vandaan kunt kopiëren... Is niet handig. En ja, er is prima mee te leven. Maar handig?

De Keil 8051 compiler die ik ooit gebruikt heb deed precies wat je verwachte en genereerde WEL correcte code zodat je code deed wat er staat. Het kan dus wel degelijk.

Functioneel wel. En dat kost je dus performance voor de delen die niet compile-time zijn op te lossen. De code doet dus wat er staat, maar vaak niet wat je wilt verwacht.

Zelfs runtime kun je dit niet oplossen, de pointer heeft maar een 16-bits size. Hoe wil je aan die pointer zien welke space het moet zijn?

Ik weet niet hoe Keil dat deed, maar bij SDCC (voor 8051) wordt een pointer dus 24 bits. 1 byte die aangeeft in welke memory space het spul zit, en 16 bits 'pointer'. Zo lossen zij het runtime op. Als je er data uit wilt hebben, dan wordt er een stuk runtime lib aangeroepen wat op basis van die pointer een stuk data 'ergens' vandaan trekt, het in RAM frut en van daaruit gaat de rest van de routine verder. Daar gaat dat prima, omdat je uit XRAM toch maar 1 byte per keer kunt lezen (of schrijven). Nadeel is dat een enkele read ipv. een paar cycli er opeens een stapel kost.

En eh... ik ben erachter gekomen dat het zo werkte omdat een ISR de boel onderuit trok. Ik vroeg me af waarom dat ding zo vreselijk duuuuur was. Dus uiteindelijk de gegenereerde assembly in gedoken om dit te ontdekken. (het deed duidelijk NIET wat ik ervan verwachtte!)

Harvard betekent alleen dat je aparte bussen hebt zodat je sneller kunt werken.

Niet direct. Kijk naar een 8051 (als je wilt: 8086... van orgine ook Harvard maar door IBM meestal vaan von Neumann omgewerkt in de omliggende hardware...). Alles hangt aan 1 bus. Alleen 1 pin die aangeeft welk stuk memory je hebben wilt.

Ik heb een 8051 ook wel eens wat misbruikt (RAM als ROM, soort bootloader constructie). Wat trucen in de adresseringslogic doen wonderen. Werkt geweldig. Maar niet helemaal zoals Intel het bedoeld heeft. Maar daar zit alles extern, daar kan dat.

Dus niet perse overlappende adressen. ARM cortex M3 heeft ook harvard, en toch een enkele adressruimte. Dus dat kan best wel.

Het KAN ook prima. Maar (daar kom ik weer met die 8051...) als ik daar RAM en ROM in 1 address space (what's in a name) wil douwen, dan kan ik nog max. 64k adresseren. Nu kan ik 2x 64k adresseren.

Daar komt nog bij dat je dan instructies krijgt die writes kunnen doen naar stukken memory die niet writable zijn. De volgende discussie gaat dan dus worden waarom de assembler (of compiler) daar niet over zeurt. Het KAN tenslotte niet (en dat is compile-time bekend).

Het probleem bij de gcc compiler is dat deze op een 32-bit flat model is gebaseerd en helemaal geen awareness heeft van verschillende memory spaces. Die compiler is dan gebruikt voor een ander type architectuur en dat begint het gesodemieter.

Ik heb van de Keil en SDCC wel code vergeleken, heel lang geleden, maar eigenlijk niet op gelet toen hoe de XRAM addressering opgelost was. De gegenereerde assembly van de Keil compiler was wel degelijk kleiner/efficienter. Dat is nog wat ik er van weet.

Volgens mij weet de compiler best het verschil tussen flash en data.
Kijk maar in de mapfile voor een AtMega32 project, code gaat naar 'text' en data gaat naar 'data':


Memory Configuration

Name             Origin             Length             Attributes
text             0x00000000         0x00020000         xr
data             0x00800060         0x0000ffa0         rw !x
eeprom           0x00810000         0x00010000         rw !x
fuse             0x00820000         0x00000400         rw !x
lock             0x00830000         0x00000400         rw !x
signature        0x00840000         0x00000400         rw !x
user_signatures  0x00850000         0x00000400         rw !x
*default*        0x00000000         0xffffffff

Maar iemand heeft ervoor gekozen om die kennis niet te vertalen naar extra code en langere pointers.

@EricP
Waarom zou je graag 2x64K willen kunnen adressen in een Mega32 met in totaal 32K flash + 2K data? Je kunt nu dus 64K adres ruimte gebruiken om 2K data te adresseren. Dus elke byte in de SRam is te bereiken op 32 verschillende adressen. Dat doet niemand, en is ook niet erg handig. Die adres ruimte had toch wel beter benut kunnen worden.

[Bericht gewijzigd door deKees op (17%)]

Zoals je kunt lezen, had dat betrekking op een 8051. Voor een AVR zou het kunnen. Krijg je dezelfde maffe constructies zoals je vroeger met 6502 enzo had... 'ergens' in je memory map begint een stuk ander memory. Waar je instructies op los kunt laten die dat memory niet kan. Zoals gezegd: dat wordt de volgende discussie: waarom laat de assembler dat toe, want die weet toch dat....

Op 22 november 2015 22:58:06 schreef deKees:
Volgens mij weet de compiler best het verschil tussen flash en data.

De linker is een beetje op "flat memory" gebaseerd. Om toch verschil tussen data en flash te maken, zijn een paar hogere bitjes gekozen, die uiteindelijk NIET in de resulterende binary terecht komen. En again, je zou je pointers langer kunnen maken en in software de boel oplossen. Je code zal dan langzamer zijn.