Vad är det som äter RAM?
Re: Vad är det som äter RAM?
Adent har i alla fall *lite* rätt...
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.
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.
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Vad är det som äter RAM?
ARM Cortex M har ett flertal bussar och kan kanske klassas som Harvard++.
Mellan bussarna finns bryggor och alla minnesareorna är mappade i samma adressutrymme.
Från USD0,88 i stycketal från DigiKey.
Mellan bussarna finns bryggor och alla minnesareorna är mappade i samma adressutrymme.
Från USD0,88 i stycketal från DigiKey.
- lillahuset
- Gått bort
- Inlägg: 13969
- Blev medlem: 3 juli 2008, 08:13:14
- Ort: Norrköping
Re: Vad är det som äter RAM?
Jag bara ville visa på en elegant lösning om man har en harvardliknande arkitektur. Och lite info om att det inte kostar speciellt mycket.
Edit: 88 centaren har 2k RAM och 8k Flash.
Edit: 88 centaren har 2k RAM och 8k Flash.
Re: Vad är det som äter RAM?
sodjan: du har totalt rätt med de moderna PIC - men detta är en PIC16F690 och där är svaret RETLW då den inte har indexregister på samma sätt.
Re: Vad är det som äter RAM?
Jo, men adents kommentar verkade mer generell.
Just i detta fall skulle det vara stora vinster med en
PIC16F1xxxx. Högre hastighet, effektivare arkitektur och instruktioner.
Jag minns inte exakt, men det är väl 5-10 år sedan nya arkitekturen kom.
Hur som helst, mitt inlägg var mer ett svar på adents inlägg
än en kommentar på det aktuella projektet...
Just i detta fall skulle det vara stora vinster med en
PIC16F1xxxx. Högre hastighet, effektivare arkitektur och instruktioner.
Jag minns inte exakt, men det är väl 5-10 år sedan nya arkitekturen kom.
Hur som helst, mitt inlägg var mer ett svar på adents inlägg
än en kommentar på det aktuella projektet...
Re: Vad är det som äter RAM?
Sodjan: Icecap: Ah jag förstår, ja jag är inte expert på pic:ar. Gör man en Harvardarkitektur vill man förstås försöka komma runt problemen med den och det ser microchip ut att ha löst
på diverse sätt genom åren och antagligen andra tillverkare också.
lillahuset: Så länge de alla är inmappade i samma adressrymd i slutändan skulle jag nog vilja kalla det en von-neumanarkitektur.
Men nu har vi glidit för långt bort från ämnet tror jag.
på diverse sätt genom åren och antagligen andra tillverkare också.
lillahuset: Så länge de alla är inmappade i samma adressrymd i slutändan skulle jag nog vilja kalla det en von-neumanarkitektur.
Men nu har vi glidit för långt bort från ämnet tror jag.
Re: Vad är det som äter RAM?
Oavsett, så är det nog ingen bra ide att ha så stora buffertar, man får helt enkelt läsa/skriva i mindre batchar.
När man lekte med Ethernet i de gamla PIC16F prollarna så fanns det garanterat inte plats att läsa skriva ethernetkretsarnas buffertar, utan man fick ta en byte i taget, och sedan manipulera bufferten i ethernetkretsen för att få önskad effekt, till exempel skriva/räkna checksumma mm.
Personligen skulle jag nog valt en lite större processor med mer RAM osv.
När man lekte med Ethernet i de gamla PIC16F prollarna så fanns det garanterat inte plats att läsa skriva ethernetkretsarnas buffertar, utan man fick ta en byte i taget, och sedan manipulera bufferten i ethernetkretsen för att få önskad effekt, till exempel skriva/räkna checksumma mm.
Personligen skulle jag nog valt en lite större processor med mer RAM osv.