Svenska ElektronikForumet

Det här med AVR vers PIC vers ...

Varför måste man välja?

Personligen kör jag mycket och helst i ARM men det går lika bra med PPC, SH, x86, MIPS, AVR mfl, och för att kunna använda mig av andras finurliga lösningar behöver jag nu också lära mig PIC. Kan inte säga att den ena verkligen är så mycket bättre än en annan.
Det som avgör är kundens erfarenheter, applikationen, vem som ska underhålla grejorna, produktens livslängd, utvecklarnas erfarenheter (ifall utvecklarna != kunden), pris på den för applikationen mest lämpade hardware och en massa andra faktorer.

Möjligtvis att det är något lättare att svara på vilken som är bäst av PIC/AVR/Parallax/...
än att ge frågan till svaret 42, men det ligger nog i samma härad i min mening.

Vilket språk man väljer är ju samma egentligen, beroende på vad man ska göra så tex:

* C, Basic, mfl tar större plats i minnet. Så när man vill ha plats med allt i det lilla minne som finns tillgänglig i en microcontroller alá PIC, AVR mfl så har man kanske inte ens lyxen att få välja, man blir helt enkelt tvungen att koda i assembler.

* Ifall man ska koda en generell rutin för att lösa ett generellt problem, kanske man helt enkelt blir tvungen att göra det i C för att det ska vara portabelt (annars blir det parallella lösningar per arkitektur, dvs AVR, PIC, ARM, PPC mfl)

Vi kan också gå vidare och prata OS (för host och för target..) samma sak här med

Ifall trådskaparen ska börja med något och känner för PIC, that's the way to go!
Och snöa inte in på enbart C el assembler, du behöver minst bägge

Jag är nog den med minst erfarenhet (efter dig) av microprollar som kommer skriva i denna tråd.
Köpte en Arduino när jag gick i dina tankar.
+Dom har gjort den väldigt lätt att programera med en egen bootloader (vet inte vad det är). Det mesta sköter sig själv via USB.
+En bra compilator (har inget att jämföra med)
+Open Source!
+Finns massor med bibliotek till olika kretsar, typ LCD-drivers, stegmotorer och sånt.
+Stort community med kod man kan apa efter.
+Billig.
+Många färdiga tillbehör som också är Open Source.

Finns säker mer. Jag är i alla fall nöjd med min. Arduino är väl tänkt att göra det enkelt att bygga interaktiva saker med många I/O som både är digitala och analoga.

+En bra compilator (har inget att jämföra med)

Hur vet du då att den är bra?

AndersG: Den kanske gör det den ska enligt Spruft.

Antar att Spruft menar avr-gcc.
Den fungerar och den är bra! Då behövs det strängt taget inga jämförelser!

Om du ska börja med microprocessorer behöver du lära dig assembler och hur processorn arbetar. Innan du gör det måste du ha några grundkunskaper i digitalteknik (grindar, register osv.)

Assembler är inte ett språk. Varje processor har sitt eget assembler. Så om du lär dig assembler för Z80 eller 8080 så är det oanvändbart för PIC eller AVR. Och lär du dig assembler för PIC så är det oanvändbart för AVR och vice versa. Alltså måste du välja - PIC eller AVR.,.

Då börjar du att gå till bibblan och lånar en bok om PIC och en bok om AVR (Per Foyer - om du gillar att läsa på svenska) ... läser lite i varje tills du fattar något . Välj den du verkar fatta mesta av och börja läs.

Assembler är ett programmeringsspråk som finns i många "dialekter"
för olika processorarkitekturer. I många fall är det större likheter
än vad man kanske tror. I princip alla assemblers har "ADD", "MOV" o.s.v.
Den exakta implementeringen för varje arkitektur skiljer dock lite (eller mycket).

> Och lär du dig assembler för PIC så är det oanvändbart för AVR och vice versa.

Koden ja, men inte *kunskapen*, och den senare är det viktiga!

Själva koden (dialekterna) går naturligtsvis inte att köra rakt av, men om
man har lärt sig PIC (eller AVR) assembler så går det snabbare att sedan
lära sig AVR (eller PIC) assembler än om man inte kan assembler alls innan...

Jag håller med sodjan här, jesse's uttalande är lite väl fyrkantigt.

Det sätt man utför funktioner i assembler är ganska lika oavsett vilken processor man använder, sekvensen är ofta den samma fastän kommandon heter lite olika.

Alltså är förståelsen man får med assembler en mycket bra grund att ha det hela på, vill man sedan avancera till högre nivå i språk tar man oftast med sig detta synsätt och man förstår oftast vad man egentligen begär av µC'n med de olika kommandon.

AVR eller PIC är inte det viktiga här. Välj den familj som du hittar ett bra experimentkort för. Prestandamässigt (och "språkmässigt") är de i princip likvärdiga (fast inte precis likadana).

Jag har för mig att det finns en trevlig assemblerprogramvara till PIC (MPASM?) där du kan simulera exekveringen, följa den steg för steg och se vad varje assemblerinstruktion gör. Det är jättebra när du lär dig (och annars också).

För AVR finns en väldigt bra open-source-C-kompilator (gcc för avr), inkl debugger (gdb) och en kunnig community.

När det gäller vilket språk du ska börja med så tycker jag så här:

1) Skriv något/några väldigt enkla testprogram, typ blinka lysdiod, i assembler för den mikrokontroller du har valt. Se till att du förstår det ordentligt.

2) Använd interrupts för att få lysdioden att blinka i programmet ovan (eller för att göra något annat på tid eller som svar på knapptryckning eller liknande).

3) Gå över till C och skriv ditt riktiga program.

När man väl har lärt sig en mikrokontroller är det inga större problem att gå över till en annan (undantag BasicStamp som inte ger "riktiga" kunskaper). Så om du vill så skulle du t.ex. kunna börja med PIC och MPASM för att sedan gå över till AVR med dess utmärkta C-kompilator.

Edit: den bästa källan till kunskap är tillverkarnas datablad (även om någon bra bok också kan vara en bra hjälp i början). ATtiny2313 (AVR) kan vara en lämplig µC att börja läsa om.

> Jag har för mig att det finns en trevlig assemblerprogramvara till PIC (MPASM?) där du kan simulera exekveringen,

http://www.jescab.se/Info_MPLAB.html

Äntligen börjar jag få rätt känsla för hur jag ska gå vidare. En bra bok från bibblan verkar bra och sedan ta det därifrån. PIC har jag redan valt utan att egentligen veta, men av alla de forum,trådar och annat jag plöjt säger PIC så det får bli så.
Sen blir det till att anlita Jescab för ett och annat.

Ok Per foyer men det var AVR, men vad är det bästa bok tipset men om PIC?
I värsta fall får jag väl köra flera.

> men vad är det bästa bok tipset men om PIC?

Om du hänger med lite och läser lite mer än dina egna trådar, så borde
du ha sett detta : http://elektronikforumet.com/forum/view ... hp?t=30674

> Sen blir det till att anlita Jescab för ett och annat.

Välkommen!

>jesse's uttalande är lite väl fyrkantigt.

Jo, det blev kanske lite överdrivet. Sodjan's förklaring med dialekter var bra. Själv hade jag enorm nytta av att jag programmerat Z80 för 26 år sedan när jag skulle börja med AVR. Grundprinciperna är ju desamma- processorerna fungerar fortfarande ganska lika efter alla dessa år. Men jag menade bara att man ska inte tro att man kan använda kodsnuttar tvärs över gränserna, eller - än värre - börja läsa om "assembler" på slumpvist vald sida på nätet utan att ha en aning om vad det är man läser om egentligen.

Om man är nybörjare så tar det ju en hel del tid, kraft och energi att orka lära sig alla nya begrepp osv... då är det synd om man läser assemblerexempel från olika processorer om vartannat - då kommer man bara att bli förvirrad. Därför menar jag - välj processor först - lär dig assembler som passar just den processorn. Sedan går det bra att börja lära sig andra dialekter, om det skulle behövas.

sodjan skrev:> men vad är det bästa bok tipset men om PIC?

Om du hänger med lite och läser lite mer än dina egna trådar, så borde
du ha sett detta : http://elektronikforumet.com/forum/view ... hp?t=30674

> Sen blir det till att anlita Jescab för ett och annat.

Välkommen!

Jo jag hade sett den men det kunde kanske funnits något annat eller hur? Men nu är boken beställd

Det är ju viktigt att vara medveten om att ska man skriva C för en mikrocontroller så behöver man ofta ändå veta en del om hur assembler fungerar.

Just olika konfigureringsgrejer och sånt görs ju ofta med makron när man skriver i C och det kan i vissa fall vara tydligare att skriva det som inline assembler.