Vilken är lättast/smartast att börja med?

[HUGGBÄVERN]

AVR är stökig, bökig och svår på många sätt. Den försöker vara som en stor processor, men når inte ända fram. Vet Du vad RCA 1802 var för något så vet Du på ett grovt ungefär vad det är för arkitektur i AVR. Inte så bra...

Jag tyckte 1802 var riktigt behändig och var en riktig huggbäver att programmera i maskinkod, men det är preskriberat nu.

Om man då gillar 1802:s struktur, skulle man då gilla AVR?

[speakman]

Man gillar främst AVR om man kör högnivåspråk, helst C.
Vad jag förstått så är AVR-arkitekturen optimerad för kompilatorer i första hand, och manuell assemblerprogrammering i andra hand.
Det finns en annan tråd här någonstans där det diskuteras mer ingående hur dessa skiljer sig åt.
Men skriver man i C så är AVR suverän att köra på.

[sodjan]

På samma sätt som PIC18 har flera egenskaper speciellt avsedda för C kompilatorer...

[HUGGBÄVERN]

Jag kan tänka mig en mängd kriterier som kan vara avgörande vid valet av microprofessor (min felskrivning):

(*) Tillgänglighet
(*) Enkel att använda - hårdvara
(*) Enkel att programmera
(*) Tillgängliga utvärderingskit - hårdavrukit
(*) Tillgängliga programmeringshjälpmedel - kompilatorer, tolkar ... "da shit"
(*) Pris - processorer, hårdvarukit, mjukvarukit
(*) Tillgänglighet applikationsexempel - på nätet.


Jag var igång och skrev C-program efter 2 dagar, till en MC68HC812, och jag misstänker att det skulle kanske vara lika "lätt" för mig att vara igång med en PIC eller AVR. Alltså måste jag då titta på en rad andra parametrar när jag gör ett val.
Det är därför inte intressant att en processor kostar 3,57 i stycketal och är aslätt att pårogrammera om ett hårdvarukit kostar 5000kr. Och vice versa.

Kort: Ni som har erfarenhet och en synpunkt kan ju gärna bortse från "lätt att programmera registren" och titta på mina punkter ovan när ni svarar.[/list]

[bengt-re]

R8C

- Inte så lättillgänglig
-/+ Lätt att använda hårdvara - lite knölig klockhantering - många möjligheter, men också många sätt at göra fel på
+ Enkel att programmera, bra utvecklingsmiljö
+/- Finns bra utvecklingsverktyg, men lite svårinstallerade och inte lika tillgängliga som till PIC eller AVR
+ Pris en stor fördel - mycket bra pris för en väldigt kapabel MCU
- Inte så mycket som till AVR eller PIC på nätet

övrigt: Glöm att köra assambler på den - det är för komplext om du inte är extremt ihärdig och dessutom är C-kompilatorn så bra att det inte är helt enkelt att göra bättre kod själv


PIC 16F

+ Mycket tillgänglig i otal kapslar och varianter
+ Lätt att använda hårdvara - många bra hw-finesser, dock modellberoende
+ Enkel att programmera, bra utvecklingsmiljö. 16F är lite tråkig med bankning på både register, SFR och programminne - har man inte vanan så rekomenderar jag 18F för nyinlärning på de lite större kretsarna.
+ Finns bra utvecklingsverktyg, men i mitt tycke ingen riktigt bra C-kompilator (åsikt)
/-+ Billiga, men inte alltid billigast - high-end kretsarna ger 18F mer boost for the buck...
+ Oändligt på nätet....

övrigt: Enkel att programmera i ASM - mycket bra datalad

PIC 18F


+ Mycket tillgänglig i otal kapslar och varianter
+ Lätt att använda hårdvara - många bra hw-finesser, dock modellberoende. Många interface inklusive LAN och USB.
+ Enkel att programmera, bra utvecklingsmiljö. C18 är riktigt bra och gratis för hobbybruk. Men 18f är också enkel och smidig att programmera i ASM (lättare än 16F)
+ Finns bra utvecklingsverktyg, MPLAB klarar allt....
+ Billiga, kanske inte billigast överallt, men mycket prisvärda
+ Mycket info på nätet - inte lika mycket som till 16F, men kod ifrån 16F går i princip att portera utan för mycket strul. Ändra Config, stryk alla banksel och sen så är det i princip att köra - en del SFR ser annurlunda ut och är synd att inte nyttja en del nya instruktioner....

övrigt: Enkel att programmera i ASM - mycket bra datalad

[Icecap]

M16C
+ många variationer, kapslingar, pinnantal, samma kärna
+ Mycket periferutrustning
+ Smidig användning av denna periferutrustning
± Skapligt utvecklingsmiljö, HEW är (utan licens) begränsat till max 64kB kod och det är MYCKET.
+ Bra prisbild
+ Modern processor
+ Många nyheter som kommer
- Mycket att hålla reda på i periferutrustning
- Inte lika pedagogiska AN som MicroChip
- Inte DIP-versioner, enbart ytmonterat (+ i produktion, - i amatör/labb)

[ucadv]

inget flamewar är fullständigt utan lite hjärndöd statistik. denna från http://www.freertos.org/PC/modules.html

Kod: Markera allt

Family                           AVR         PIC18          ARM7
CPU                              ATMega323   PIC18F452      LPC2106: THUMB [ARM]
Freq.                            7.9 MHz     20MHz          59MHz (memory @ 20MHz)
----------------------------------------------------------------------------------
16bit addition                   55.2us      71.6us         9.2us [7.4us]
16bit multiplication             71.4us      193us          9.7us [8.2us]
16bit division                   536us       940us          26.4us [22us]
32bit multiplication             180us       344us          10.4us [8.76us]
32bit subtraction                88.1us      76.4us         9.1us [7.6us]
Bubble sort                      834us       3.33ms         432us [420us]
Block memory move and compare    7.9ms       12.4ms         1.1ms [1.08ms]
Conditional branch to procedure  245.6us     169us-220us    48us, [46.8us]
PUSHuing and POPuing             258us       412us          43.8us, [43.6us]

vill också påpeka att det är mycket svårt att få ett ärligt svar från folk när det gäller såna här "X vs. Y" frågor.

Om nån säger att 68K är bättre än x86 så menar han troligen att
1. Jag kan bara 68K och det vore bekvämt om allt annat bara dog ut
2. Jag säljer 68K produkter och det vore dålig för affärerna och x86 visade sig vara bättre.
3. Jag vet inte ett smack om 68k eller x86, men gillar att delta i ett flamewar
4. Jag har en dyr 68K-baserat XXX hemma och skulle känna mig dum om x86 visade sig vara bättre.

Det är väldig sällan någon ärlig säger något i still med "Jag har använt både 68k och x86 i X antal år och överlagt tycker att 68K är något bättre när det gäller XXX och YYY".



ville bara få det ur mig,
ha det gôtt

[speakman]

Det var ett välkommet inslag, då bara de PIC-frälsta orkar engagera sig.
AVR-älskare har inget behov av att hävda sig.

[sodjan]

I tabellen ser PIC18452 långsammare ut än en ATMega323 på 7 av 9 tester.
Visst, när man kör AVRen på full fart och PIC'en på halv...

Om man räknar om siffrorna till respektive *fullfart* på båda
processorerna, d.v.s AVRen 7.9 => 8.0 Mhz och PIC 20 => 40 Mhz,
så ser det istället ut så här :

Kod: Markera allt

Family                           AVR         PIC18          ARM7
CPU                              ATMega323   PIC18F452      LPC2106: THUMB [ARM]
Freq.                            8.0 MHz     40MHz          59MHz (memory @ 20MHz)
----------------------------------------------------------------------------------
16bit addition                   54.5us      35.8us         9.2us [7.4us]
16bit multiplication             70.5us      96.5us         9.7us [8.2us]
16bit division                   529us       470us          26.4us [22us]
32bit multiplication             178us       172us          10.4us [8.76us]
32bit subtraction                87.0us      38.2us         9.1us [7.6us]
Bubble sort                      824us       1.66ms         432us [420us]
Block memory move and compare    7.8ms       6.2ms          1.1ms [1.08ms]
Conditional branch to procedure  242.5us     84.5us-110us   48us, [46.8us]
PUSHuing and POPuing             255us       206us          43.8us, [43.6us]

Plötsligt är PIC'en *snabbare* än AVR'en på 7 av 9 tester...
Notera att varken ATMega323 eller 18F452 är speciellt aktuella modeller...

[ucadv]

ATMega323 är en _gammal_ krets. Atmel rekommenderade redan 2001 alla kunder att gå över till nya ATMega32 (16MHz).

Det flesta nya kretsar kan köras i 20MHz (och överklockas utan problem till 24MHz). Tänk också på att kompilatorn har förbättras avsevärt sen 2001.

Kod: Markera allt

Family                           AVR         PIC18          ARM7 
CPU                              ATTINY2313  PIC18F452      LPC2106: THUMB [ARM] 
Freq.                            20.0 MHz    40MHz          59MHz (memory @ 20MHz) 
---------------------------------------------------------------------------------- 
16bit addition                   21.8us      35.8us         9.2us [7.4us] 
16bit multiplication             28.2us      96.5us         9.7us [8.2us] 
16bit division                   212us       470us          26.4us [22us] 
32bit multiplication             71.2us      172us          10.4us [8.76us] 
32bit subtraction                35us        38.2us         9.1us [7.6us] 
Bubble sort                      340us        1.66ms         432us [420us] 
Block memory move and compare    3.12ms      6.2ms          1.1ms [1.08ms] 
Conditional branch to procedure  97us        84.5us-110us   48us, [46.8us] 
PUSHuing and POPuing             102us       206us          43.8us, [43.6us]

edit: la in ATiny323, fixade flestavfningagrr

[speakman]

Ersätts av Mega32 som körs @ 16MHz.
Hade faktiskt varit intressant med ett färskare test...

EDIT: Hittade denna bl.a.. De andra jag hittar ger ungefär samma resultat...

[Icecap]

Och slutsatsen är egentligen att det inte finns en viss processortyp som är "bäst". Alla har fördelar och nackdelar och i slutskedet är det ändamålet som bestämmer.

Ska en enhet massproduceras har priset/MIPS betydelse, är det lågt stycktal är TTM viktigt (TTM = Time To Market), är det hobby är det enkel och stabil programmering + billigt prog. språk som gäller.

Frågan är lite som att fråga vad som är bäst av en "Yamazuki" hoj och en Scania lastbil och det går självklart inte att besvara: ska man flytta 10m³ jord är hojen inte så användbar men vill man ta en vårtur och njuta av den friska luften är hojen ett attraktivt alternativ.

Själv håller jag på att bli ganska frälst på Renesas, där finns många trevliga versioner men trevliga periferutrustning till bra pris och för att blåsa in programmet behövs en serieport, en MAX232 (behövs ändå för kommunikation) samt 2 optokopplare + det av mig utvecklade programmet som styr resten.

Att jag håller på med dom beror på att vi sparar pengar i jämförelse med Fujitsun och får mer MIPS/kr.

[ucadv]

WTF?

"billigt prog. språk"??

Har du också blivit lurad av Darl McBride?

[Marta]

Den där jämförelsen kallar jag 100% bullshit!

Hur i HELVETE (usäkta, men finner inget annat adekvat uttryck) programmerar man för att få en 16 bit addition att ta 30 µs?

PIC18 har "add with carry", det betyder denna sekvens:

Hämta addendens låga byte
Addera till augendens låga byte utan carry
Hämta addendens höga byte
Addera till augendens höga bytemed carry.

Varje steg tar 4 klockor, alltså totalt 16. Vid 32MHz (intosc med pll) blir detta 0.5µs, eller 500ns.

Fast med en kompilator så kan ju allting hända, speciellt om man har fullt debug-stöd och maximal felrapportering aktiverad. Hur det är med detta framgår inte. Alltså är uppgifterna totalt intetsägande.

Slutsats: PIC är fortfarande bäst! (Per definition och därmed basta!)

[speakman]

Sakligt...

Vad skulle "fullt debugstöd" påverka hastigheten? Det innebär ju bara att debugsymboler lagras i en separat fil, så exekvering går att följa i IDE:n.
Om PIC-resultatet är så missvisande, så lär nog AVR-resultatet vara det också.

AVR *är* bäst, per definition...