Pic vs Avr en liten jämförelse

[Gizmo]

Det finns ju lite (i mitt tycke mindre givande) tendenser till att det blir lite krig mellan de som anser att en viss processorarkitektur är bättre än den andra. Hur som helst, så tycker jag faktiskt att artikeln http://digital-diy.com/pic-micrcontroller/532-why-i-pick-pic.html var riktigt läsvärd, rekommenderar den!

(Om nån admin på forumet, vill flytta inlägget till bättre avdelning, så gör gärna det, hittade ingen avdelning som bara hette "länkar/läsvärt").

[Nerre]

Den var ju inte så intressant eftersom det var en jämförelse för en väldigt specifik tillämpning. Dessutom verkade det vara en del missuppfattningar i artikeln enligt ett par av kommentarerna (t.ex. tog han ingen hänsyn till hur många MIPS processorerna klarade utan tittade bara på klockfrekvensen, vilket ju blir lite snett när den ena processorna kör de flesta instruktioner på en klockcykel medans den andra kräver 4 klockcykler).

[sodjan]

OK, här är vad jag tycker. Rent personligt så klart...

En fullständigt värdelös jämförselse!

Det kör i diket redan på den första punkten i tabellen
med jämförda egenskaper med distiktionen mellan "RISC"
och "Harvard". Det ena har med instruktions-arkitekturen att
göra och det andra ha med hårdvaru-arkitekturen att göra och
det kan inte jämföras direkt mot varandra.

Dessutom är, när det gäller just *denna* punkt, AVR och PIC i
princip lika, *båda* har en separa bussar för programminnet!

Jag läste inte vidare eftersom han inte verkar veta vad han skriver om.

Eller, bara för att ta en enda punkt till...

RAM som anges till 2024 (AVR) och 3684 (PIC). Men det missar helt den viktigaste
punkten i en sådan jämförelse. På en AVR så kan "RAM" endast användas med
*2* instruktiner, "store" och "load" . För att göra något som helst annat med
dessa så måste datat flyttas fram och tillbara via ett "register". På en PIC
kan *alla* instruktioner (arith, shift/roll, bit set/clear/test o.s.v) användas
på *alla* 3684 register. D.v.s att en PICs hela "RAM" i princip fungerar som
en AVR's 16/32 "register". Det är bl.a detta som gör att en AVR har 131
instruktioner mot en PIC (18) har 75 intruktioner (83 med "extended
instruktions set" påslaget). Så en PIC är ungefär dubbelt så mycket
"RISC" som en AVR, om man mäter så...

[blueint]

Bra kompilator som kan kompileras för valfri plattform och därmed är reellt porterbart är också en faktor, iaf för utvecklingsmiljön.

[sodjan]

Ja, kanske. Finns väl lite olika åsikter runt just *det*...
Men nu var ju inte frågan en jämförelse som sådan,
utan kommenterar kring just den där sidan.

[victor_passe]

Kan också kommentera på hand användande av klockfrekvens. Det är väll instruktionsfrekvensen som är det intressanta.
I avr är det ju samma men inte i den picen han tittar på. Vet inte hur det är på msp.

[TomasL]

Bra kompilator som kan kompileras för valfri plattform och därmed är reellt porterbart är också en faktor, iaf för utvecklingsmiljön.

Fullständigt ointressant om verktygen går att kompilera eller inte.
Det viktiga är att det finns färdiga och fungerande verktyg, för den miljön man använder, samt en fungerande support.

[sodjan]

> Det är väll instruktionsfrekvensen som är det intressanta.

Ja, det är *en* faktor. Det är även intressant hur effektiv arkitekturen
i sig är. D.v.s t.ex hur mycket "data shuffling" man måste göra för
att utföra en typisk uppgift. Så i slutänden måste man jämföra genom
att köra samma funktion i de aktuella miljöerna.

Jag är övertygad om att man kan hitta olika uppgifter som råkar bli
optimala på olika plattformar beroende på vad som ska utföras.

Men du har rätt i sak, klockfrekvensen som sådan är ganska ointressant,
och det säger nog mest att det var en glad amatör som hade hittat ett
trevligt HTML verktyg men som saknade något vettigt att skriva om...

[Krille Krokodil]

Så kan man sitta och filosofera i timmar, dagar, veckor över vilken som är den optimala processorn till sitt enstycks projekt när nästa, lite mer kraftfulla modell kostar en krona mer eller två...

Alla större företag kartlägger ju sina konkurrenters produkter i detalj, så för var AVR och PIC finns där säkert varsin powerpoint hos Atmel och Microchip med + och - mot motsvarande modell hos konkurrenten.

[sodjan]

Absolut, därför blir dessa jämförelser ganska akademiska.
Mitt tips brukar vara att "kör med den som kompisen kör med".

[Krille Krokodil]

Sodjan, hur är det med programmeringsverktygen och ICE för PIC?

Fåniga Atmel tjuvhåller ju på information om protokollen för ICE vilket gör att det tar en massa tid för open source-projekten att få fram stöd för verktygen och egna verktyg, konkurrenterna har väl bara någon jävla indier de sätter på att analysera saken om de vill och så någon vecka senare är det kartlagt, ingen raketforskning direkt tror jag om man har analysverktygen.

[sodjan]

Microchip har en massa olika verktyg, kolla med www.microchip.com.
De flesta skiter nog i protokoll o.s.v så länge som verktygen gör jobbet.

[nifelheim]

Jag har bara kört MPLAB till min Pickit 3, finns det någon annan (OSS)toolchain jag borde prova

[TomasL]

Nej det behöver du inte, visst finns det andra, men de är tämligen onödiga iom MPLAB.

[TomasL]

Sodjan, hur är det med programmeringsverktygen och ICE för PIC?

Fåniga Atmel tjuvhåller ju på information om protokollen för ICE vilket gör att det tar en massa tid för open source-projekten att få fram stöd för verktygen och egna verktyg, konkurrenterna har väl bara någon jävla indier de sätter på att analysera saken om de vill och så någon vecka senare är det kartlagt, ingen raketforskning direkt tror jag om man har analysverktygen.

Microchip har ett antal AN som i vilket fall beskriver programmeringsprotokollet i detalj, hur det är med debuggern vet jag inte, gissar att det är skillnad hur de olika verktygen fungerar. Tror dock att REAL-ICE och ICD3 är likartade, upplever dock REAL-ICE snabbare.