I och för sig har flash och "RAM" olika adress areor, men de är även mappade
mot en större area (inte helt korrekt, men i princip), så man kan t.ex ladda indexregister
med adresser som kan peka mot båda minnena. Och normalt sker det transparent genom
att symboler till olika objekt laddas till indexregistren och det sker utan att man just då
behöver veta var det ligger. Så visst, det är en Harvard arkitektur, men det spelar inte
stor roll i praktiken.
Om MSB är satt i indexregistret så pekar det mot Flash, annars mot RAM. I fallet med
RAM så kan det peka mot "linjear address space" där RAM från samtliga banker ligger
i en linjär följd så att man enkelt kan ha buffertar som är större än minnet i en bank.
Själva koden som laddar indexregister och läser ser exakt likadan ut oavsett om
(t.ex.) textsträngen som ska läsas ligger i flash eller RAM. Det är bara där man
definierar texten som det skiljer på var man vill att den ska skapas. Sen laddas
indexregister symboliskt och då sätts MSB om det är Flash.
Så i princip har Adent rätt i skillnaderna mellan arkitekturerna i sig, men inte många
rätt i vilka konsekvenser det får i praktiken.
Icecap> Det går utmärkt att ha konstanter i ROM och läsa ut dom "on the fly". Instruktionen RETLW är lösningen,
Nej. Inte på dagens processorer (PIC16F1xxx och bättre). RETLW stöds fortfarande men det
är betydligt smidigare att köra med indexregister och "auto post/pre increment" o.s.v.
Eftersom det finns två indexregister så går en kopiering från Flash till RAM väldigt
effektivt med en loop och auto increment på båda registren...
> Men jag menar faktisk att det finns, kanske även i MikroC...
Om MikroC är uppdaterad till PCI16F1xxx standard, så förväntar jag mig att detta
hanteras lite halv-automatiskt i de fall där det är aktuellt och där det går.
