Tråden med råd om programmering.

[jesse]

Det är väl en *mycket* större skillnad än så. T.ex är assemblerkoden helt olika. AVR-koden liknar gamla Z80 till viss del, PIC liknar vad?
Sedan har jag ännu en aversion mot PIC pga hur man adresserar RAM-minnet. Det är inte ett sammanhängande block utan en massa olika på nåt vis ... har aldrig satt mig in i det, men verkar väldigt onödigt och krångligt om man vill jobba med stora vektorer t.ex.
Kanske även Flash och EEprom är uppdelat på det viset i PIC?
Sedan antar jag att det finns vissa skillnader i kringutrustningen - timers, ADC, UART I2C med mera. De är säkert väldigt lika i grunden, men det är nog ganska stora skillnader där också, hur flaggor och interrupt fingerar t.ex. Jag är för lite insatt i PIC för att ta något konkret exempel.

[Icecap]

jesse: att minnet i PIC är i banker är korrekt när vi pratar PIC16, med PIC18+ är det knappast ett större problem.

Och att asm-instruktionerna skiljer sig är synnerligt normalt, din liknelse är ganska åt skogen! AVR-mnemonics påminner lika mycket om Z80 mnemonics som PIC gör det, eller Motorola eller Fujitsu eller Renesas...

Och att lika enheter i olika PIC ska ställas olika visar bara att du är van med AVR som ju är ökända för att t.ex. inte vara speciellt bakåtkompatibla, som avslutar tillverkning av en modell utan att ha en lämplig ersättare osv.

Varje tillverkare har sina fördelar och nackdelar, AVR är varken bättre eller sämre än PIC, de har bara lite olika sätt att göra samma jobb på. Fördelen för PIC är att Microchip är mycket bra på att skriva datablad, har många App. Notes och bra verktyg.

PICKit2 är t.ex. en del billigare än samma funktion till AVR eller hur?

[sodjan]

> Det är väl en *mycket* större skillnad än så.

Vadå "än så" ? Min kommentar var riktad till det som Swech skrev:
"Skillnaden mellan AVR - PIC blir att på AVR ligger CONFIG utanför, i FUSES".
Det är helt enkelt fel. CONFIG/FUSES ligger "utanför" på båda PIC och AVR.
Det är i princip ingen som helst skillnad i det avseendet, mer än till namnet.
(Och i det faktum att en AVR kan "brickas" om man inte ser upp).

Sen så finns det naturligstvis *andra* skillnader, med det var inget som
kommenterades i föregående inlägg, men eftersom du ända tar upp det...

> T.ex är assemblerkoden helt olika.

Tja, en ADD är alltid en ADD o.s.v. Sen så heter de olika instruktionerna
kanske lite olika saker men *principerna* är i stort ganska lika. PIC är både när det
gäller instruktioner och i arkitekturen mer ortogonal, d.v.s att alla instruktioner
fungerar mot alla adresser (ingen uppdelning i "register" resp "RAM" som i AVR).

> AVR-koden liknar gamla Z80 till viss del,

OK, kanske det. Och exakt för hur många är just *det* är fördel ? Märklig kommentar...

Sen var det lite kommenterar kring adresseringen, och det som verkar stämma bäst
där är nog "har aldrig satt mig in i det" och "Jag är för lite insatt i PIC..."

> ...men verkar väldigt onödigt och krångligt om man vill jobba med stora vektorer t.ex.

Ja, det är uppenbart att du inte vet vad du skriver om. Bankningen är mest något att
ta hänsyn till (vilket är oerhört enkelt dessutom) när det gäller direkt-adressering.
Användningen av indexerad adressering via indexregistren har inte denna "begränsning".
Senaste generationen av PIC16 (de 4-siffriga) har även en mappad linjär adressarea
för hela RAM minnet. PIC18 (vilket sannolikt är aktuellt om man har större datamängder
har alltid haft en linjär hantering av RAM minnet.

> Kanske även Flash och EEprom är uppdelat på det viset i PIC?

Nej, det har de aldrig haft. Flash är uppdelat i "pages", vilket man ibland
får ta hänsyn till. EEPROM är helt linjärt. Spekulativ gissning utan grund.

En annan sak är att på en PIC så fungerar alla register (SFR eller GPR) exakt på
samma sätt. D.v.s att alla instruktioner som jobbar mot ett register kan alltid
användas mot *alla* register. I en AVR finns det en (eller flera) uppdelningar
i olika areor där vissa instruktioner fungerar mot alla register och andra (som
t.ex bit-instruktionern) enbart fungerar mot en mindre del av RAM. Det finns också
en uppdelning av minnet i "register" resp "RAM" som PIC saknar (d.v.s att *allt* RAM i
en PIC kan användas ungeför som det begränsade antalet "register" i en AVR).

> Sedan antar jag att det finns vissa skillnader i kringutrustningen - timers, ADC, UART I2C med mera.

Tja, det är väl samma sak där, en timer är en timer o.s.v. Det finns mindre skillnader
främst i vad saker och ting kallas, men principerna för hur det fungerar är ganska lika.

> ...men det är nog ganska stora skillnader där också, hur flaggor och interrupt fingerar t.ex.

Det är självklart att det *finns* skillnader. Det är lite svårt att tolka vad du ingetligen vill
säga med det konstatarandet, det är ju inget problem i sig med att det *finns* skillnader !?

Du är ute och simmar på ett något för djupt vatten...

[jesse]

Det är väl bara bra att ni kommer med fakta. Jag sa inte att AVR var bättre av de olika anledningarna, jag nämnde bara vad jag uppfattat vara skillnader. Likheten med Z80 assembler gjorde att jag direkt kände mig hemma med AVR, vilket jag inte kände när jag snabbt försökte få en uppfattning om PIC, när jag var tvungen att välja en av dem. Skillnaden mot PIC var så stor att jag faktiskt tackade nej till att låna ett komplett paket (PIC kit eller nåt sånt) och köpte en AVR-ISP istället. Det var även en viktig avgörande sak att jag hittade litteratur på svenska om AVR. Men det är ju personligt vad man tycker verkar begripligt och inte när man är nybörjare. Det är säkert så att PIC inte är konstigare än AVR när man väl kan det.

Tanken med inlägget var väl att en novis kunde få uppfattningen att det inte var någon skillnad alls, förutom FUSES / CONFIG, som om att kan du AVR så kan du PIC eller vice versa. Riktigt så är det ju inte.

"har aldrig satt mig in i det, men verkar väldigt onödigt och krångligt om man vill jobba med stora vektorer" ... här påstår jag alltså inte att det ÄR krångligt, men jag hade fått uppfattningen att det var det av att ha läst i andra trådar. Det är ju bra att jag får fakta här...

Kanske skulle jag skrivit inlägger mer i form av en fråga istället.. Så kanske svaren hade blivit lite gladare

[sodjan]

He, jo, kanske det...

> Det är säkert så att PIC inte är konstigare än AVR när man väl kan det.

Och inte ens innan man kan det heller. PIC och AVR är nog ungefär lika
"konstiga", för en nybörjare.

> Tanken med inlägget var väl att en novis kunde få uppfattningen att det inte var
> någon skillnad alls, förutom FUSES / CONFIG, som om att kan du AVR så kan du
> PIC eller vice versa. Riktigt så är det ju inte.

Ja, det där var lite olyckligt. Både CONFIG bitarna i en PIC och FUSES i en AVR har
ju med grundläggande saker kring hur processorn "körs". Val och oscillator, startup
timer, watchdog på/av, brownout på/av o.s.v. Just i de delarna är det kanske minst
skillnad mellan AVR och PIC.

> som om att kan du AVR så kan du PIC eller vice versa.

Jag skulle vilja uttrycka det som att, om du kan *mikrokontrollers* ö.h.t,
så kan du både PIC och AVR. Om inte så kan du varken AVR eller PIC. För
den någorlunda tekniskt lagde som kan antingen AVR eller PIC, så ska det
inte vara något större problem att fatta hur den andra fungerar, bara man
tar sig tid att studera det.

Problemet med "stora vektorer" är att de inte får plats i någon PIC eller AVR,
med en tillräckligt vid definition av "stora". Ett sådant påstående är ganska
meningslöst utan en tydlig definition av vad man menar med "stora" och det
kan bli vitt skillda metoder att lösa det beroende på vad man menar.

Jag vill inte heller påstå att den ena är *generellt* bättre än den andra, men
om man gör jämförelser så bör det i alla fall inte bygga på direkta felaktigheter.

[stekern]

Den här tråden har visst spårat ur till AVR vs PIC.
Som sagts innan, båda platformarna har sina för och nackdelar.
När jag började med microcontroller så testade jag på både AVR (at90s2313) och PIC (16f84) och gjorde ett par projekt till båda där jag skrev koden i assembler.
Båda var i mitt tycke ungefär lika enkla/svåra att komma igång med, hade sina egna små egenheter som jag gillade/ogillade.
Anledningen till att jag sedan gick helt över till AVR var att vid den tiden var det mycket enklare/billigare att få tag på C-kompilator till AVR.

För att försöka någorlunda knyta in AVR vs PIC i trådens topic:
Testa båda, det kan mycket väl vara att det är fallet som för Jesse att någon av dessa känns enklare (beroende på tidigare preferenser).
Om du har någon i närheten som håller på med den ena eller den andra, välj samma, "real-life" support är guld värt.

[sodjan]

Absolut, välj den där "supporten" är bäst...

[persika]

Nackdel för PIC: begränsat stackminne.

[Swech]

Generella tips vid programmering

1 Undvik cut and paste. Har man något som skall beräknas med lite olika inparametrar
så kan det vara lätt att kopiera sin första rutin och ändra ytterst lite i den.
Sen behöver man kanske en till.. och man kopierar igen och ändrar lite.
och så håller det på.

Varför är detta illa? - största delen av tiden man lägger på program är att ändra dem
eller felsöka. Har man då något som ändrar sig och man kopierat detta på 1000 ställen
(t.ex. en ingång bytar pinne i hårdvaran) så blir det ett h... vete att hitta alla och
korrigera dessa.

- Gör istället 1 rutin som gör jobbet och som kan justeras via inparametrar.

2. Gör programmet så oberoende av hårdvaran som möjligt.
Pilla inte direkt på utgångar, läs inte av ingångar överallt. och framförallt gör inte smarta
lösningar där koden är direkt beroende av hårdvaran. Jag har sett kod där man läser en hel byte från en port och man ville kolla ingångsbit 7. Detta gjordes med att se om byten var negativ. Kanon så länge som man inte flyttar signalen till en annan pinne....

3. Följd av punkt 2. Läs alla ingångar på 1 ställe i programmet. Avstudsa på samma ställe
Sortera upp ingångarna och spara i en RAM cell med en given definierad ordning.
Resten av programmet kollar bara RAM cellen med dess definierade bitordning.
Förändring av hårdvaran innebär att man justerar på ETT ställe.. resten av koden kommer
att funka utan ändringar.

Se även till att invertera ev ingångar med pull up och aktivering vid slutning mot jord i detta
magiska ställe som tar hand om all IO och sparar mot RAM.
Resten av programmet behöver alltså inte bry sig
om pinnen sluts mot + eller jord. i ditt RAM skall detta vara åtgärdat och resten av programmet körs med att "1" är aktiv ingång (oavsett polaritet)

Punkterna ovan gäller naturligtvis inte för pinnar som har specifik hårdvarufunkton
så som PWM, Timers mm...

Swech

[gunnerfeldt]

Det här verkar bli en lovande tråd.

Jag testar/felsöker alltid min kod med LEDar och oscilloskop/logger.
Använder folk i allmänhet debugger eller till och med VSM?

Jag själv känner mig för ivrig och börjar löda så fort jag har en idé, men skulle gärna utveckla ett mer sofistikerat skapande utan trassel.


/Pelle

[sodjan]

Papper och penna är underskattade utvecklingshjälpmedel.

[gunnerfeldt]

Det kan jag skriva under på (no pun intended)!

Alltså, ett block och en blyertspenna på dass är min räddning.
Jag vet inte hur många snygga lösningar jag "klämt" fram därinne.

/Pelle

[jesse]

Jag har aldrig testat debugger, om du menar direkt i hårdvara. Däremot använder jag ganska ofta simulatorn som kommer med AVR Studio 4. Fast simulator fungerar bäst med givna algoritmer som ska lösa något logiskt problem eller så. Så fort det blir avancerade indata (som är svåra att simulera) så tycker jag att simulatorn blir svåranvänd. Ofta krävs ju mycket avancerad indata som ska göras beräkningar på och respons beroende på detta. Detta kan ofta vara helt omöjligt att simulera. (ibland när jag måste simulera så skriver jag särskilda "indatageneratorer" så programmet får vettiga data att jobba med. Exempel:

Kod: Markera allt

#define simulator // kommentera bort när programmet ska köras i hårdvara!

...

#ifdef simulator
// indatagenerator för simulering
#warning SIMULATOR MODE ONLY! 
indata = indatalista[nr++];
#else
indata = PINA;
#endif

[gunnerfeldt]

...jag programmerade en och samma PIC 668 gånger på en dag.

Kanske kan vara något slags rekord. I hjärnsläpp.