Skall börja med att säga att jag har kört mycket PIC,
men har lämnat den för just AVR.
Största svagheten med PIC16xx är att det bara finns 1 index register.
Detta gör att PIC inte inbjuder till att skriva programrutiner som kan
arbeta på olika data. Det går att göra men koden blir oftast längre
än om man skriver in
Movf data,w
..gör något med data
Movwf data
Detta funkar naturligtvis också.. men programmen blir besvärliga att underhålla. Det är så ruskigt lätt att missa något om samma kod
är kopierad X antal gånger fast med olika indata.
Största tiden och kostnaden för ett program ligger i
underhåll och modifiering. (vi talar naturligtvis om program
som ligger utanför hobbyverksamhet.)
Konstanttabeller är också ett svagt kapitel hos PIC16xx
Bytetabeller går att göra med Retlw .... men oftast
blir det så komplicerat att man låter bli.
Observera dock att jag inte säger att det inte går på en PIC,
det är bara att den inte inbjuder till att göra det varav man
helt enkelt låter bli och skriver sina program utan tabeller och
med rutiner som arbetar direkt mot data.
Likaså är jag också medveten om att man har macrostöd som hjälper
till att fixa dessa svagheter
Men jag har lämnat PIC, inte för att den var svår att programmera
utan för att underhåll av programmen blev för tidskrävande.
Skulle däremot gärna prova på att köra Icecaps favorit Renesas.
Swech
Atmel eller PIC?
*lyssnar* *tänker* Det där är en djupt filosofisk fråga.
Alltid med religionskrig blir det diskussion vid brasan. "Det finns bara en gud!!!". Hur vet du det? "- Jag har bara sett en!". " - Sluta nu. Öppna upp, tänk dig att det finns två eller tre. Vilken skulle du då välja.". Att diskutera vilken CPU som är att föredra. Med någon som bara har sett en. Är som att diskutera "Antalet gudar" med en kristen präst. Man får bara ett svar.
Och där startade kriget.
Jag gillar AVRs teknik som verkar lite ärligare. Den visar direkt att man jobbar med olika minnen. Att försöka lägga det bakom någon abstraktion dvs, banker. Det bidrar till att koden inte tar hänsyn till att det är olika minnen. Det är skillnad på kod som försöker jobba med snabbt och segt minne. Om instruktionerna återspeglar det. Och det får utvecklaren medveten om vad han jobbar med. Då är väl det bra?
Alltid med religionskrig blir det diskussion vid brasan. "Det finns bara en gud!!!". Hur vet du det? "- Jag har bara sett en!". " - Sluta nu. Öppna upp, tänk dig att det finns två eller tre. Vilken skulle du då välja.". Att diskutera vilken CPU som är att föredra. Med någon som bara har sett en. Är som att diskutera "Antalet gudar" med en kristen präst. Man får bara ett svar.
Och där startade kriget.
Jag gillar AVRs teknik som verkar lite ärligare. Den visar direkt att man jobbar med olika minnen. Att försöka lägga det bakom någon abstraktion dvs, banker. Det bidrar till att koden inte tar hänsyn till att det är olika minnen. Det är skillnad på kod som försöker jobba med snabbt och segt minne. Om instruktionerna återspeglar det. Och det får utvecklaren medveten om vad han jobbar med. Då är väl det bra?
Banker är ingen "abstraktion" av "olika minnen". Det är enbart en fråga
om *adressering* och inget annat. Allt minne i en PIC är för övrigt helt
likadant, d.v.s med avseende på vad man kan göra med det.
> Det är skillnad på kod som försöker jobba med snabbt och segt minne
PIC har enbart snabbt minne, så detta kan jag inte kommentera närmare...
> ...att PIC är designad primärt för assemblerprogrammering, och AVR för C.
...att de mindre PIC-serierna är designad primärt för assemblerprogrammering,
och AVR samt PIC18 (och "större" PIC-serier) för C.
om *adressering* och inget annat. Allt minne i en PIC är för övrigt helt
likadant, d.v.s med avseende på vad man kan göra med det.
> Det är skillnad på kod som försöker jobba med snabbt och segt minne
PIC har enbart snabbt minne, så detta kan jag inte kommentera närmare...
> ...att PIC är designad primärt för assemblerprogrammering, och AVR för C.
...att de mindre PIC-serierna är designad primärt för assemblerprogrammering,
och AVR samt PIC18 (och "större" PIC-serier) för C.
För de flesta applikationer värdesätter jag:
Lägsta möjliga energiförbrukning.
En sleep funktion som är enkel att hantera.
Bra och lätthanterliga I/O portar, hög drivförmåga.
Snabba AD omvandlare.
Pålitliga interupts.
In circuit programming.
jag är än så länge nöjd med PIC utan att veta något om AVR.
Lägsta möjliga energiförbrukning.
En sleep funktion som är enkel att hantera.
Bra och lätthanterliga I/O portar, hög drivförmåga.
Snabba AD omvandlare.
Pålitliga interupts.
In circuit programming.
jag är än så länge nöjd med PIC utan att veta något om AVR.
Jag funderar lite på dessa "jämförelser" som finns mellan AVR och PIC om varför man just valt AVR
T.ex har det diskuterats att pic har/är:
* begränsningar i lookup tabeller,
* ej "konsekvent" (flyttbar kod mellan olika processorer)
* Underhåll av kod.
Dessa jämförelser verkar främst vara den gamla 16F serien, eller har jag fel?
jag tycker nämligen inte att dessa argument stämmer för de senare modellerna från 18F och framåt.
Jag har arbetat med både PIC och AVR, främst med C-programmering. Det jag gillar med AVR är att de har en ordentlig debugg-miljö om man kör en j-tag eller liknande. Microchips "realice" eller ICD2 har en hel del begränsningar och är buggiga när stegar och letar fel i sin kod.
Däremot tycker jag att Microchip har lagt ut massor av bra programexempel, färdiga bibliotek osv osv på sin hemsida så att det hyfsat snabbt att få ihop en avancerad applikation.
Jag föredrar PIC framför AVR för att det är den jag kan och vet ung vart jag ska leta för att hitta information = snabbare att utvecka.
T.ex har det diskuterats att pic har/är:
* begränsningar i lookup tabeller,
* ej "konsekvent" (flyttbar kod mellan olika processorer)
* Underhåll av kod.
Dessa jämförelser verkar främst vara den gamla 16F serien, eller har jag fel?
jag tycker nämligen inte att dessa argument stämmer för de senare modellerna från 18F och framåt.
Jag har arbetat med både PIC och AVR, främst med C-programmering. Det jag gillar med AVR är att de har en ordentlig debugg-miljö om man kör en j-tag eller liknande. Microchips "realice" eller ICD2 har en hel del begränsningar och är buggiga när stegar och letar fel i sin kod.
Däremot tycker jag att Microchip har lagt ut massor av bra programexempel, färdiga bibliotek osv osv på sin hemsida så att det hyfsat snabbt att få ihop en avancerad applikation.
Jag föredrar PIC framför AVR för att det är den jag kan och vet ung vart jag ska leta för att hitta information = snabbare att utvecka.
> Dessa jämförelser verkar främst vara den gamla 16F serien,
Och speciellt *äldre* modeller från "den gamla" 16F serien som inte
kan skriva/läsa direkt från flash. Där har man enbart RETLW-tabeller att
tillgå.
Nyare 16F-modeller har i många fall direkt skrivning/läsning till/från
flash, så där blir det enklare tabellhantering. 18F har ju 3 index ("tabell")
register så där underlättas det ytterligare.
Och "konsekvent". Tja, det beror väldigt mycket på hur man har skrivit sin
kod från början. Med rellocatable-code m.m så blir flytten mellan olika
modeller mer eller mindre enkel. Adresser till register m.m justeras
automatiskt av länkaren.
Även underhållet av koden beror mest på hur den var skriven från början.
Det gäller *all* kod oavsett vad den körs på från mikrokontrollers till mainframes...
Och speciellt *äldre* modeller från "den gamla" 16F serien som inte
kan skriva/läsa direkt från flash. Där har man enbart RETLW-tabeller att
tillgå.
Nyare 16F-modeller har i många fall direkt skrivning/läsning till/från
flash, så där blir det enklare tabellhantering. 18F har ju 3 index ("tabell")
register så där underlättas det ytterligare.
Och "konsekvent". Tja, det beror väldigt mycket på hur man har skrivit sin
kod från början. Med rellocatable-code m.m så blir flytten mellan olika
modeller mer eller mindre enkel. Adresser till register m.m justeras
automatiskt av länkaren.
Även underhållet av koden beror mest på hur den var skriven från början.
Det gäller *all* kod oavsett vad den körs på från mikrokontrollers till mainframes...
Kan bara hålla med sodjan: kvaliteten på koden avgör hur enkelt det blir att porta till annan µC-version.
Jag har som regel att ett värde ska anges på 1 plats och alla andra delar av programmet ska referera till denna definition. Värden som "sitter ihop" med detta värde ska ha en definition som definieras sv värdet det hör ihop med.
Exempel:
#define BUFFERSIZE 20
#define PENULTIMATE (BUFFERSIZE - 1)
("penultimate" betyder nästsista)
Och varenda gång jag behöver värdet 20 OCH det beror på bufferstorleken använder jag BUFFERSIZE. Känner jag för att ändra värdet pga. ändrade förutsättningar är det bara att göra det 1(!) ställe, sedan kompilerar man om och det är klart.
Likaså med portar:
#define LED_RED PORTA,0
#define SOLENOID PORTB,3
och sedan uteslutande använda dessa namn till dessa funktioner (gäller självklart input också).
Måste man sedan byta port på in-/utgång för att man byter storlek på krets eller annan orsak är det bara att byta i definitionen, kompilera om och det kör direkt.
Jag har lyckats med att göra ett mycket stort C-program som kan kompileras till en Fujitsu FFMC-16LX processor OCH till en Renesas M16C62, källkoden är samma fast det skiljer på vilken hårdvara-filer som kallas in men hela "main-funktionen" är samma fil.
Jag använder samma fil till att definiera alla kommunikationsvärden oavsett om det är i µC'en eller i PC-programmet (alltså vilket värde nummer som betyder vad) och på det vis har jag en del extra jobb i det inledande skedet... men senare har jag det hur enkelt som helst: Kompilerar jag alla de olika projekt i deras respektive kompiler fungerar allt och de pratar inte fel med varandra.
Jag har som regel att ett värde ska anges på 1 plats och alla andra delar av programmet ska referera till denna definition. Värden som "sitter ihop" med detta värde ska ha en definition som definieras sv värdet det hör ihop med.
Exempel:
#define BUFFERSIZE 20
#define PENULTIMATE (BUFFERSIZE - 1)
("penultimate" betyder nästsista)
Och varenda gång jag behöver värdet 20 OCH det beror på bufferstorleken använder jag BUFFERSIZE. Känner jag för att ändra värdet pga. ändrade förutsättningar är det bara att göra det 1(!) ställe, sedan kompilerar man om och det är klart.
Likaså med portar:
#define LED_RED PORTA,0
#define SOLENOID PORTB,3
och sedan uteslutande använda dessa namn till dessa funktioner (gäller självklart input också).
Måste man sedan byta port på in-/utgång för att man byter storlek på krets eller annan orsak är det bara att byta i definitionen, kompilera om och det kör direkt.
Jag har lyckats med att göra ett mycket stort C-program som kan kompileras till en Fujitsu FFMC-16LX processor OCH till en Renesas M16C62, källkoden är samma fast det skiljer på vilken hårdvara-filer som kallas in men hela "main-funktionen" är samma fil.
Jag använder samma fil till att definiera alla kommunikationsvärden oavsett om det är i µC'en eller i PC-programmet (alltså vilket värde nummer som betyder vad) och på det vis har jag en del extra jobb i det inledande skedet... men senare har jag det hur enkelt som helst: Kompilerar jag alla de olika projekt i deras respektive kompiler fungerar allt och de pratar inte fel med varandra.
Största svagheten med PIC16xx är att det bara finns 1 index register.
Detta gör att PIC inte inbjuder till att skriva programrutiner som kan
arbeta på olika data.
Lösningen på detta heter PIC18, absolut inte AVR!
Med PIC18 finns det tre pekare som dessutom har autoinkrement.
Även andra jobbigheter är lösta, t.ex. ADD/SUB med ingående carry.
Bankproblemet för SFR's är löst, en speciell bit som direktväljer dessa samt ett stycke RAM där man lägger t.ex. inerrupthanterares data och annat som skall vara snabbt och lätt tillgängligt. Sparar massor av bankswitchar.
Stacken har 32 nivåer, så det går att nesta subrutiner hyfsat väl utan att få takkänning. Datastack är det tyvärr sämre med.
Varje programsteg kan delas till två tabellpositioner som dessutom addresseras på ett vettigt sätt, även autoinkrement om man så önskar.
Finns liteannat smått och gott också givetvis.
Kontentan av det hela: Känns PIC16 för trång så är svaret PIC18, absolut inte AVR!
Detta gör att PIC inte inbjuder till att skriva programrutiner som kan
arbeta på olika data.
Lösningen på detta heter PIC18, absolut inte AVR!
Med PIC18 finns det tre pekare som dessutom har autoinkrement.
Även andra jobbigheter är lösta, t.ex. ADD/SUB med ingående carry.
Bankproblemet för SFR's är löst, en speciell bit som direktväljer dessa samt ett stycke RAM där man lägger t.ex. inerrupthanterares data och annat som skall vara snabbt och lätt tillgängligt. Sparar massor av bankswitchar.
Stacken har 32 nivåer, så det går att nesta subrutiner hyfsat väl utan att få takkänning. Datastack är det tyvärr sämre med.
Varje programsteg kan delas till två tabellpositioner som dessutom addresseras på ett vettigt sätt, även autoinkrement om man så önskar.
Finns liteannat smått och gott också givetvis.
Kontentan av det hela: Känns PIC16 för trång så är svaret PIC18, absolut inte AVR!
Då var det igång igen, det stora kriget mellan PIC och AVR.
Detta är lika roligt att läsa varje gång, jag förstår inte varför vissa är så inbitna i sitt favorit fabrikat och strider med näbbar och klor för dem.
I bland är det nästan på nivån att min bil är mycket bättre än din för den är röd. Men min är blå... bla bla.
De olika fabrikaten har sina olika för och nackdelar.
Följande är MINA kriterier när jag avgör PIC eller AVR
+ PIC
Bra kom-igång dokumentation
Stort urval av modeller
Mycket projekt på internet
- PIC
Mycket errata på de ny modellerna. (Tråkigt när man berörs av dem själv)
Begränsad debug (endast en brytpunkt )
+ AVR
Bra interrupt hantering
Finns modeller med lätthanterad minnes mappad extern buss
Gratis C miljö
-AVR
Finns ej dokumentation för den oinvigde. (Kan vara tungt att komma igång med hårdvara, pwm o.s.v.)
Detta är lika roligt att läsa varje gång, jag förstår inte varför vissa är så inbitna i sitt favorit fabrikat och strider med näbbar och klor för dem.
I bland är det nästan på nivån att min bil är mycket bättre än din för den är röd. Men min är blå... bla bla.
De olika fabrikaten har sina olika för och nackdelar.
Följande är MINA kriterier när jag avgör PIC eller AVR
+ PIC
Bra kom-igång dokumentation
Stort urval av modeller
Mycket projekt på internet
- PIC
Mycket errata på de ny modellerna. (Tråkigt när man berörs av dem själv)
Begränsad debug (endast en brytpunkt )
+ AVR
Bra interrupt hantering
Finns modeller med lätthanterad minnes mappad extern buss
Gratis C miljö
-AVR
Finns ej dokumentation för den oinvigde. (Kan vara tungt att komma igång med hårdvara, pwm o.s.v.)
