Svenska ElektronikForumet

Angående ARM så fråga Storbom, tror att han höll på med det.

Icecap skrev: Utvecklingsmiljöt har mycket att säga också, efter vad jag har sett i detta forum om strul med C-kompilern till AVR är det inte lönt, jag vill att problemen jag ska lösa härrör från programmet jag skriver, inte från kompilern!

Jag tror mer på att det är sbt (skit bakom tangentbordet)
Att AVR skulle vara för bra för enklare uppgifter har mycket svårt att förstå, det är ju knappast priset AVR som avgör...

Micket: om du nöjer dej med AT91SAM7S64 finns SAM-BA (programerings verktyg för AT91SAM7S** som går att ladda ner från atmel hemsida.)

Ett hyfsat billigt utveklingsbord för 60$

Dock skulle jag inte rekomdera som första "processorn" man leker med

cykze: jag menar att man kan använda de minsta PIC där det vore oekonomisk att använda en "riktig" MCU, i detta tänkar jag på pris och fysisk storlek.

exile: det konstiga är ju att så pass många har problem med att få allt "trimmat in" eller hur? Visst finns det dator-analfabeter som inte skulle ge sig in på det alls men en del av det jag har läst rör sig om hyggligt kompetenta personer som har svårt att förstå vissa inställningar.

Som tekniker vet jag om "RTFM" men som användare vill jag ha plug-and-play och det verkar det miljö inte erbjuda. Om det så är en C-kompilator med öppen källkod skiter jag totalt i, det säger tyvärr ofta att det är baserat på ett tekniker-miljö och det är sällan användarvänligt.

Grejen är att jag vill ha det hela, gratis och enkelt och det får gärna vara snyggt och effektivt också.

Nu har jag inte kört AVR-grejor alls förutom några äldre 8015-kärnor som jag blixtsnabbt skaffade mig av med så jag är ganska mycket "hear-say" i detta, jag är övertygad om att AVR har bra processorer men i mitt tankesätt placerar de sig där jag i alla fall ville ta till en större processor och därmed är de onödiga för mig.

För att bredda diskussionen lite, så tänkte jag bara ge min bild...

AVR är snabbare i många fall, samtidigt medför detta vissa nackdelar. Snabbheten kommer till viss del från att man hos Atmel har valt att köra med finare geometrier i sin processortillverkning. Microchip däremot har varit lite mer konservativa och kör med lite äldre teknik. Jag har hört från flera håll att AVR'erna är något känsligare i "svåra" miljöer med hög elektrisk och magnetiskt störnivå. PIC däremot, tack vare att de kör med lite äldre teknik, är mer okänsliga i detta avseende.

Dock, Microchip har flera nya processorer (de med ett "J" i namnet) där man har infört en snabbare och finare tillverkningsprocess. Detta gör samtidigt att de bara finns som 3.3V modeller. T.ex de nya PIC24J, 16-bitar, 120 Mhz och 40 MIPS. Det finns även en PIC24H serie som använder den äldre processen och kan köras i 5V, dock inte med riktigt samma hastighet. Även i PIC18 serien finns flera "J" modeller som tillverkas i en modernare process.

Det finns många olika PIC, jag kollade just nu och det ser ut så här (enbart "flash", till dessa tillkommer modellerna med ROM och OTP, tillsammans 30 st "in production") :
"In production" : 124st, varav 7st PIC12, 44st PIC16 och 70st PIC18.
"Future product" : 39st, varav 8-bit 17st och 16-bit 22st (alltså "PIC24").
Detta är olika bas-modeller, de finns sedan i olika kapsel o.s.v.

Jag tror inte att det finns 124 olika AVR "in production".

Den breda produktlinjen hos PIC verkar även göra den populär där det gäller att trimma kostnader och tillverka flera miljoner exemplar av en produkt. Nu är detta ju inte "hobby" marknaden, så det beror ju lite på vad man har för utgångspunkt.

När det gäller PIC16 vs. PIC18, så är skillnaderna inte så stora. Den mesta assembler koden kan köras efter en genomgång. PIC18 är enklare att programmera bl.a p.g.a att paging och banking är mindre "störande".

Men, sen tror jag att det är väldigt mycket tillfälligheter som gör vilken serie man "fastnar" för. Ungefär som vad det är som gör att en del blir "die-hard" Volvo ägare, och andra SAAB...

För det första så har 8051 inget med AVR...
Ju måste jag hålla med om att det är konstigt, då går att köra helt grafisk utan att peta i några konstiga filler...
Det du behöver är AVRstudio och WINAVR sedan installera både programen.
Starta AVRstudio skapa ett projet med C-kopilatorn välj mcu typ och skriv din kod och programmera AVR med tex STK500...
Jag har svårt att se att blir lättare...

Icecap:

Den minsta PIC:en verkar vara i en 6/SOT23-kapsel. Den minsta AVR:en har en kapsel med 8 pinnar. Visst är det någon millimeters skillnad, men så länge det inte rör sig om stor massproduktion så ser jag inte det som någon avgörande fördel för PIC. Hur det är med priser vid stora volymer vet jag faktiskt inte och det är inte intressant för mig.

När det gällde avr-gcc antog jag att du menade själva kompilatorn och inte hur man sätter upp en utvecklingsmiljö. Någon som använder WinAVR får gärna säga hur enkelt/svårt det är att sätta upp WinAVR nu för tiden. Under Linux sätter man upp ett AVR-projekt på samma sätt som vilket annat vanligt C-projekt som helst. Fast det underlättar ju naturligtvis om det finns färdiga installationspaket för den Linuxdist man använder...

> ...jag är övertygad om att AVR har bra processorer men i mitt tankesätt placerar de sig där jag i alla fall ville ta till en större processor och därmed är de onödiga för mig.

Jag kan förstå att du tycker att AVR är onödig. Men på samma sätt hade du nog tyckt att PIC var onödig om du istället hade börjat med AVR.

Jag vill nog säga att du har helt rätt i det påstående.

Jag kan så å andra sidan inte se de avgörande fördelar vid AVR....

Förut blev det påstådd att AVR är snäppet över PIC i "styrka" och flexibilitet, alltså överlappes den rikligt av Fujitsu'n jag använder....
Jag har seriösa funderinger på att helt spola 8-bitars och enbart jobba med 16 eller fler bitar, priserna på single-chip är ändå ganska lika vara sig det är 8 eller 16 bit men en 16-bit kan tugga större tal innan det blir besvärligt.

Slutsumman för mig är i alla fall att det till stor del är ganska likgiltigt vilken processor man använder (sålänge den pallar jobbet), det viktiga är utvecklingsmiljöt och verktygen.

Ta t.ex. Renesas processor där det var en tävling där ett antal fick utvecklingskit, jag har själv den 16-bitars varianten som finns.

Det är en trevlig processor, bra miljö att utveckla i....men för att få det _fulla_ paket med optimering osv ska man betala en summa.

Där dog det direkt för mig, jag vill inte betala för att låta dom sälja en hel del processorer, de ska vara glada om jag väljer deras produkt!

Av just den orsak har jag kört vidare med mitt projekt till SBS Janfire med Fujitsu'n:
C-kompiler med en "sådär" editor (ganska hygglig men inte perfekt), alla optimeringer, ingen begränsninger eller tjafs....total gratis.

Det gör att Fujitsu kommer att sälja x antal tusin processorer per år och Renesas ingen...i mitt projekt i alla fall.

Jag har även kollat på PIC 16-bitars (24xxx) men C-kompilern kostar i fullversionen = hejdå!

Så missuppfatta inte mig: AVR gör nog trevliga processorer och det finns bra verktyg att hämta....men jag vill helst att verktyget kommer från processortillverkaren så att man kan ställa någon till svars om det inte fungerar bra.

Just den situation har jag med den senaste versionen av Fujitsu's programpaket, det får spader om det finns svenska tecken i kommentar-delen! Deras support-kille _är_ igång kan jag lova!

Sen på slutklämmen: PIC16 och dens förbannade bankning _är_ en pärs men jag ser ingen anledning att börja med PIC18 som ju är 8 bitars...

Hm... Vad innebär egentligen användarvänligt i dessa sammanhang?
Om en nybörjare ska lära sig "datorer", så kan jag förstå att det är enkelt med ett grafiskt gränssnitt och med ett enkelt pekdon kunna göra de enklaste operationerna.
Men på den här nivån borde det vara passé sedan länge kan man tycka.
Jag kör den mesta utvecklingen i Emacs. Den editorn är det nog svårt att konkurrera mot när man väl lärt sig den.
Men den editorn har jag satt upp min alldeles egna utvecklingsmiljö anpassad för mina behov.
Jag kan utveckla programvaror i de flesta språk, och för de flesta plattformerna.

Därför kunde jag med enkelhet även sätta upp avr-gcc i samma invanda utvecklingsmiljö och direkt fördjupa mig i koden, än att försöka lära in mig i en helt ny miljö för just detta ändamål.
Det är vad jag kallar användarvänlighet!

Det förtäljer ju inte att själva AVR-processorerna är bättre, men det var en av anledningarna att jag valde AVR.

Mvh
speakman