Svenska ElektronikForumet

Det där var en förklaring av mitt "Skillnaden mellan AVR och PIC när det gäller att jobba mot RAM är ju obefintlig när det gäller vad processorn gör." som du tyckte var svårtolkat.


PIC och AVR gör alltså "samma sak", enda skillnaden är att på AVR måste man skriva lite mer kod.

OK, då är jag med. Ja, min poäng är att man får göra tre olika saker på AVR
beroende på om minnet tillhör "register" "I/O memory" eller "data space".
På en PIC är allt samma sak och hanteras på exakt samma sätt. Och det
har hela tiden varit "the programmer view" som varit mitt intresse, inte
hur det hela är byggt "under the hood" med bussar hit och dit...
Men då är vi ju överens!

Du missade tydligen det Swech skrev:

"Skillnaden är att LD/ST alltid fungerar så om man har problem med IN/OUT så kan man ALLTID köra LD/ST över hela minnet."

Vill man slippa fundera på vad det är man adresserar så kör man alltså LD/ST rakt av. För mig sitter det i ryggmärgen sen ABC80-tiden att I/O-portar adresserar man med IN/OUT och RAM med PEEK/POKE.

Nackdelen är att LD/ST tar större plats eftersom instruktionen måste rymma den kompletta adressen.

IN/OUT-instruktioner är kortare eftersom de inte behöver lika många bitar till adressen.

Nej, jag missade inte det. Jag tog det inte på allvar just p.g.a
de nackdelar som du nämner. Det är helt enkelt inte praktiskt
att göra så. Men det löser enbart problemet med "load/store".
Du kan fortfarnde inte göra en "decrement" mot vad du vill.

Ta det lite lungt, jag *är* påläst om hur AVR fungerar...

> För mig sitter det i ryggmärgen sen ABC80-tiden att I/O-portar
> adresserar man med IN/OUT och RAM med PEEK/POKE.

Visst, så är det i *alla* arkitekturer som inte har "memory mapped I/O".
Det var väl ett designbeslut som verkade vettigt någon gång i Intels
begynnelse. Idag är det tveksamt om det är en bra design.

Nej, jag kan inte göra en decrement mot vad jag vill, men på samma tid som en PIC gör decrement av en variabel i RAM så kan jag med en AVR läsa värdet från RAM, räkna ner, skriva tillbaka till RAM.

Decrementen måste ju ändå göras av ALU, d.v.s ett värde ska in i ALU och sen ut från ALU. Ligger en PIC verkligen "online" mot RAM när den gör en sån manöver? Det kan den knappast göra, datat måste latchas in och latchas ut (eftersom du inte kan skriva och läsa en adress samtidigt). Dessa latchar fungerar precis som ett register. Ett register är ju i princip två latchar som ligger efter varandra.

Nåja, nu ska vi väl håla oss till sanningen, eller hur Nerre?

Vad tuggar en 8-bitars ATmega max? 16MHz?

Och jag sitter just nu med en PIC18F25K22 som kan skrämmas upp på 64MHz med det interna clock-system. Så trots att en PIC18 behöver 4 cyklar för att utföra en instruktion blir det ändå 16MHz i exekveringshastighet.

Så de kör rent faktisk lika snabbt räknat i antal instruktioner per sekund - och då behöver en PIC färre instruktioner för att göra samma jobb...

Nej, 20MHz, likaså Tiny. Atxmega upp till 32MHz.

Jag ser det mer i form av flexibilitet. T.ex att använda indexerad ("indirect" på AVR)
adressering över en tabell/buffert och göra DEC/INC direct mot den. Notera att
indexerad ("indirect") adressering kan användas av alla instruktioner, inte bara
till load/store (LD/ST) som på AVR.

> Ligger en PIC verkligen "online" mot RAM...

Som sagt, du får tänka om när det gäller begrepp som "RAM".
Den där frågan är inte intressant för en PIC, de har inget "RAM"
som skilljer sig från det vanliga minnet ("register").

Om det nu skall jämföras hastighet så får man inkludera banksel som man
måste ha på PIC om programmet skall kunna nå hela adressområdet

Det som gång på gång nämns är att man har ett område för IO på AVR
som är speciellt, och allt utanfär detta måste nås med de hemska LD/ST
instruktionerna. Det rör sig om 64 adresser totalt. Alla fulla med
register/bitar för portar, uart mm... Övriga 64k adresser når man

PIC måste man för alla 128 bytes bankar hålla på att sätta banksel bitarna
för att det skall bli rätt. Över hela området

Så att ha bankselect krav i en processor idag så kan man citera:

Det var väl ett designbeslut som verkade vettigt någon gång i Intels
begynnelse. Idag är det tveksamt om det är en bra design.

Swech

sodjan skrev: Den där frågan är inte intressant för en PIC, de har inget "RAM"
som skilljer sig från det vanliga minnet ("register").

Likväl tar instruktionerna som jobbar mot PICens "register" 4 klockcykler... vilket stämmer väl överens med hur de flesta processorer adresserar RAM (och inte register).

Latcha ut adress på adressbussen, skicka read-signal till minnet, latcha in datat från databussen.
eller
Latcha ut adress på databussen, latcha ut datat på databussen, skicka write-signal till minnet.

Spelar ingen roll vad du kallar det, processorn adresserar det precis som en processor adresserar RAM.

> Likväl tar instruktionerna som jobbar mot PICens "register" 4 klockcykler... vilket stämmer väl överens med hur de flesta processorer adresserar RAM (och inte register).

Det har inte ett smack med det att göra! 4 klockcykler är 1 instruktionscykel,
det är bara så den är byggd.

Och ytterligaren en gång, att "allt kan göras mot allt" värderar jag högre.
Och att det enbart finns en sort minne som alltid uppträder likadant.
Samma instruktioner oavsett vad man jobbar med (I/O, minne o.s.v).

Och jag tror att många andra värderar att slippa bankswitchning och att ha en riktig stack där man kan ha både returadresser och variabler.

Tja, jag vet inte vilken värld du lever i, men du blandar ihop saker.
Först och främst klockhastighet, du blandar ihop klockhastighet och instruktionshastighet, det är två helt skilda saker.
En AVR kör garanterat på en intern klockhastighet som är minst 4X den officiella, annars kan den inte fungera.

Bankswitchning och stack är väl inga problem, skillnaden mellan en PIC<=18 och andra är att du har minst två stackar, faktiskt flera (ofta 4 st), varav en av stackarna är helt hårdvarustyrd, vilket betyder att du inte behöver bekymra dig över den, de andra stackarna kan du manipulera hur du vill.
Bankswitchning behövs enbart när du skall göra en direktaccess till de bankar som inte är mappade till bank 0, vilket inte är så vanligt, sas.
Normalt använder man ju stackarna och Bank0, vilket gör att behovet av bnankswitchning inte är så stort, dessutom hanterar ju C-kompilatorn det hela, utan att du behöver bekymra dig.

Blanda nu inte in C i det hela....

Swech

Öh, varför inte, det är väl det normala verktyget man använder, eller.....