Sitter med ett projekt där jag använder en PIC16F88 och funderar på att flytta över koden till en PIC18F2685. Men vad är det som skiljer PIC16F och PIC18F familjerna?
I en annan tråd fick jag fram att PIC18 har inbyggd multipler av klockfrekvensen, interruptet sparar undan workregister mm automatiskt och det finns interrupt prioritering.
Men vad skiljer dem mer som man inte ser i Microchips jämförelsetabeller och vad ska jag tänka på när jag flyttar över koden?
När jag bara försökte kompilera koden för PIC18F rakt av så fick jag felmeddelande på if (INTCON.INTF) i interruptet.
Skillnad mellan PIC16F- och PIC18F-familjen
Vad snackar du om bearing? vad jag vet så har de ett low och ett high isr på PIC18. avr däremot har varje en egen adress.
Lite mer mellan PIC16 och PIC18.
Lite mer mellan PIC16 och PIC18.
- Bättre minneshantering
Finns med flash/ram
Mer hårdvara
> en annan tråd fick jag fram att PIC18 har inbyggd multipler av klockfrekvensen,
Ja. Sen skilljer det lite mellan olika modeller.
Vissa kan enbart använda 4X PLL med kristall, andra även med intosc.
> interruptet sparar undan workregister mm automatiskt
Ja, väldigt praktiskt och snabbt.
> och det finns interrupt prioritering.
Ja, men skit i det. Dessutom fungerar inte ovenstånde på samma sätt då...
> om har en annan instruktionsuppsättning,...
"Annan" skulle jag inte säga, de 35 instruktionerna från PIC16 är i stort
sätt de samma, sedan tillkommer det en del upp till ca 72 st totalt.
> Finns med flash/ram
Och det gör inte PIC16 !!!???
> och varje interrupt har en egen adress.
Inte PIC18, däremot PIC24 och dsPIC30/33...
Ja. Sen skilljer det lite mellan olika modeller.
Vissa kan enbart använda 4X PLL med kristall, andra även med intosc.
> interruptet sparar undan workregister mm automatiskt
Ja, väldigt praktiskt och snabbt.
> och det finns interrupt prioritering.
Ja, men skit i det. Dessutom fungerar inte ovenstånde på samma sätt då...
> om har en annan instruktionsuppsättning,...
"Annan" skulle jag inte säga, de 35 instruktionerna från PIC16 är i stort
sätt de samma, sedan tillkommer det en del upp till ca 72 st totalt.
> Finns med flash/ram
Och det gör inte PIC16 !!!???
> och varje interrupt har en egen adress.
Inte PIC18, däremot PIC24 och dsPIC30/33...
Instruktionssetet är bättre, bl.a. finns där villkorliga hopp och add/sub med carry. Hoppen kan gå +/-127 steg.
Relativt ovillkorligt hopp samt subrutin +/-1023 steg.
Långt hopp och långt call som når hela minnet utan krångel. Dessa tar två programsteg, men kan ändå användas ihop med skip eftersom de kodats så att andra steget tolkas som nop.
Ett SFR som är W så att alla instruktioner kan operera på värdet i detta.
Minneshanteringen är bättre, alla SFR är åtkomliga direkt utan bankswitch, dessutom 128 bytes ram på samma sätt.
Bättre tabellhantering med speciella funktioner för detta, två bytes kan lagras i en minnesposition istället för ett programsteg.
Stacken är djupare och kan göra mer än lagra returadresser om än det är krångligt.
Relativt ovillkorligt hopp samt subrutin +/-1023 steg.
Långt hopp och långt call som når hela minnet utan krångel. Dessa tar två programsteg, men kan ändå användas ihop med skip eftersom de kodats så att andra steget tolkas som nop.
Ett SFR som är W så att alla instruktioner kan operera på värdet i detta.
Minneshanteringen är bättre, alla SFR är åtkomliga direkt utan bankswitch, dessutom 128 bytes ram på samma sätt.
Bättre tabellhantering med speciella funktioner för detta, två bytes kan lagras i en minnesposition istället för ett programsteg.
Stacken är djupare och kan göra mer än lagra returadresser om än det är krångligt.
I första hand så är det igentligen bara mer minne som gör att jag behöver en bättre PIC men sedan har jag problem med timingen med den koden jag har skrivit nu.
Kör en PIC16 i 20Mhz som ska agera 1-Wire slav och hämta info via USART. Som det är nu kör jag alla 1-wire händelser i interruptet eftersom det är så högt prioriterat och väldigt snabba små saker.
Kör med 2-3 st switch-case satser och sedan några if satser. Vid varje avbrott på negativ flank på INT som är 1-wire bussen så ska oftast PICen svara på 1-wire bussen inom några få uS. Känns inte som att det är något alternativ att ha 1-wire koden i main eftersom rätt sak måste ske med det samma och pekaren kan vara på fel ställe i main för att hinna hamna rätt.
Jag hoppas att kompilatorn jag kör MikroC är bättre på att kompilera koden till PIC18F än vad den är på PIC16F. Den hoppar omkring i koden som en tok och sparar undan massa extra vid avbrott.
Så vad tror ni. Är PIC18 rätt väg att gå? aFrämsta fördelen verkar ju vara i mitt fall att interruptet är snabbare, mer minne och möjligheten till att köra i högre frekvens.
Kör en PIC16 i 20Mhz som ska agera 1-Wire slav och hämta info via USART. Som det är nu kör jag alla 1-wire händelser i interruptet eftersom det är så högt prioriterat och väldigt snabba små saker.
Kör med 2-3 st switch-case satser och sedan några if satser. Vid varje avbrott på negativ flank på INT som är 1-wire bussen så ska oftast PICen svara på 1-wire bussen inom några få uS. Känns inte som att det är något alternativ att ha 1-wire koden i main eftersom rätt sak måste ske med det samma och pekaren kan vara på fel ställe i main för att hinna hamna rätt.
Jag hoppas att kompilatorn jag kör MikroC är bättre på att kompilera koden till PIC18F än vad den är på PIC16F. Den hoppar omkring i koden som en tok och sparar undan massa extra vid avbrott.
Så vad tror ni. Är PIC18 rätt väg att gå? aFrämsta fördelen verkar ju vara i mitt fall att interruptet är snabbare, mer minne och möjligheten till att köra i högre frekvens.
Du ska inte ta för givet att din C-kompilator är "smartare" när den bygger
kod för PIC18 istället för PIC16. Men det är väl bara att prova! Kör
några rellevanta delar för PIC18 och kolla vad den åstakommer.
Sen är ju PIC18 i grunden dubbelt så snabb (10 instruktionscykler/sek
mot 5 för PIC16) så lite snabbare bör ju allt gå i alla fall.
*Största* vinsten gör du antagligen dock genom att göra som Marta rekomenderar.
Dessutom för du 100% kontroll över all kod...
Vissa delar kan kanske ansbbas upp med inline-assembler, men jag vet
inte om det finns någon möjlighet att komma runt (alltså få bort) den extra
hantering som kompilatorn lägger till i början på interrupt-rutinen...
kod för PIC18 istället för PIC16. Men det är väl bara att prova! Kör
några rellevanta delar för PIC18 och kolla vad den åstakommer.
Sen är ju PIC18 i grunden dubbelt så snabb (10 instruktionscykler/sek
mot 5 för PIC16) så lite snabbare bör ju allt gå i alla fall.
*Största* vinsten gör du antagligen dock genom att göra som Marta rekomenderar.
Dessutom för du 100% kontroll över all kod...
Vissa delar kan kanske ansbbas upp med inline-assembler, men jag vet
inte om det finns någon möjlighet att komma runt (alltså få bort) den extra
hantering som kompilatorn lägger till i början på interrupt-rutinen...
Visst assemble gör det hela effektivare men det tar rätt lång tid att koda om allt för min del. Visserligen skulle jag kunna utgå ifrån nuvarande kompilerad kod och sedan ändra där. Men jag känner att jag har bättre koll på C är ASM. ASM e rätt bökigt att koda i om man ska göra en switch case sats tex.
Så PIC18 går i grunden dubbelt så snabbt alltså på samma frekvens? Dubbelt så många instruktioner på samma tid.
Så PIC18 går i grunden dubbelt så snabbt alltså på samma frekvens? Dubbelt så många instruktioner på samma tid.
> Men jag känner att jag har bättre koll på C är ASM...
Vilket ju inte gör C bättre i sig...
> ASM e rätt bökigt att koda i om man ska göra en switch case sats tex.
Jasså ?
> Så PIC18 går i grunden dubbelt så snabbt alltså på samma frekvens?
Nej, Eller ja, det beror på vad du menar...
> Dubbelt så många instruktioner på samma tid.
Ja, vid dubbla frekvensen. PIC16 = 20MHz, PIC18 = 40 MHz.
Sen är det en annan sak att man med PIC18's instruktionsuppsättning
kan få mer *jobb* gjort på samma *antal* instruktioner. De är helt enkelt
i många fall effektivare. D.v.s att en PIC18 kan få mer gjort vid (t.ex) 20 MHz
än en PIC16 vid samma frekvens...
Vilket ju inte gör C bättre i sig...
> ASM e rätt bökigt att koda i om man ska göra en switch case sats tex.
Jasså ?
> Så PIC18 går i grunden dubbelt så snabbt alltså på samma frekvens?
Nej, Eller ja, det beror på vad du menar...
> Dubbelt så många instruktioner på samma tid.
Ja, vid dubbla frekvensen. PIC16 = 20MHz, PIC18 = 40 MHz.
Sen är det en annan sak att man med PIC18's instruktionsuppsättning
kan få mer *jobb* gjort på samma *antal* instruktioner. De är helt enkelt
i många fall effektivare. D.v.s att en PIC18 kan få mer gjort vid (t.ex) 20 MHz
än en PIC16 vid samma frekvens...
Man kanske borde ha dammat av sina ASM kunskaper och kodat lite i ASM. Men att börja koda i ASM nu och dessutom på en PIC18 blir nog för mycket för att jag ska kunna hinna klara mig inom tidsramarna.
C är trots allt ett högnivå språk så det är klart det är smidigare att programmera men man har helt klart bättre koll på vad som händer i PICen exakt om man kör i ASM. ASM känns lite segt att programmera i enligt mig.
Jobbigare att tolka och som rätt ny på språket så blir nog inte koden särskillt effektiv heller.
Har för mig att det diskuterades här för länge sedan att man lika gärna kunde programmera i C som i ASM. Koden som kompileras skulle ändå bli lika effektiv.
Är man van högnivåprogrammerare så är det hur som helst rätt bökigt att tänka om så att man kan åstakomma samma sak i ASM. En smidig liten rad i C kan bli flera kluriga rader i ASM. Låter bra att det finns fler kommandon i PIC18 men 71 st eller var det nu var extra verkar rätt mycket. Bökigt att hålla koll på alla. Men det e klart att det blir effektivare.,
Mer att tänka på vid ASM programmering kom jag på nu. Bara du har ett avbrott så ska du helst spara undan work-registret mm.
Skulle kanske kunna lägga upp nuvarande koden här för att se om ni kan hjälpa mig att effektiviser den. Har den både i C och C kommenterad ASM-kod.
C är trots allt ett högnivå språk så det är klart det är smidigare att programmera men man har helt klart bättre koll på vad som händer i PICen exakt om man kör i ASM. ASM känns lite segt att programmera i enligt mig.
Jobbigare att tolka och som rätt ny på språket så blir nog inte koden särskillt effektiv heller.
Har för mig att det diskuterades här för länge sedan att man lika gärna kunde programmera i C som i ASM. Koden som kompileras skulle ändå bli lika effektiv.
Är man van högnivåprogrammerare så är det hur som helst rätt bökigt att tänka om så att man kan åstakomma samma sak i ASM. En smidig liten rad i C kan bli flera kluriga rader i ASM. Låter bra att det finns fler kommandon i PIC18 men 71 st eller var det nu var extra verkar rätt mycket. Bökigt att hålla koll på alla. Men det e klart att det blir effektivare.,
Mer att tänka på vid ASM programmering kom jag på nu. Bara du har ett avbrott så ska du helst spara undan work-registret mm.
Skulle kanske kunna lägga upp nuvarande koden här för att se om ni kan hjälpa mig att effektiviser den. Har den både i C och C kommenterad ASM-kod.
ankan:Behöver inte ta allt för lång tid att översätta till .ASM själva idéen är det ju som tar tid att få på pränt. Utförandet är ju bara att skriva av "facit" så att säga. Man kan dessutom göra många listiga saker i ASM som jag antar att en c-kompilator INTE gör.
Sen bör du nog inte räkna kallt med att "lösa" det hela med en snabbare µc. Tänk om det fattas en switchcase och denna räcker för att överbelasta även den värre µcn?
En instruktion i 20 Mhz tar 50ns och du hinner med 20 såna på 1us du skriver några och är du uppe i 3 så har du 60 instruktioner till "förfogande" detta om du snackar .asm
*Minnet du skriver om är det arbetsminnet eller vilket minne pratar vi om?
Med förbehåll att några siffror _KAN_ vara fel räknade i min trötta skalle nämligen.
Sen bör du nog inte räkna kallt med att "lösa" det hela med en snabbare µc. Tänk om det fattas en switchcase och denna räcker för att överbelasta även den värre µcn?
En instruktion i 20 Mhz tar 50ns och du hinner med 20 såna på 1us du skriver några och är du uppe i 3 så har du 60 instruktioner till "förfogande" detta om du snackar .asm
*Minnet du skriver om är det arbetsminnet eller vilket minne pratar vi om?
Med förbehåll att några siffror _KAN_ vara fel räknade i min trötta skalle nämligen.
Syftar på arbetsminne där jag kan lagra variabler och arrayer mm.
Men bara en sån grej som att sända och ta emot data på USART blir jobbigare och att tex ha en delay på en viss tid.
Att skicka via USART i C är ju bara Usart_Write('X'); eller en delay är delay_ms(100). Det finns alltså rätt mycket färdigt i C kopilatorerna. Men det kanske även finns för ASM, eller?
Men bara en sån grej som att sända och ta emot data på USART blir jobbigare och att tex ha en delay på en viss tid.
Att skicka via USART i C är ju bara Usart_Write('X'); eller en delay är delay_ms(100). Det finns alltså rätt mycket färdigt i C kopilatorerna. Men det kanske även finns för ASM, eller?
