PIC programmering i C - Kompilator?
-
- Inlägg: 79
- Blev medlem: 22 juni 2006, 16:11:17
- Ort: Lund
- Kontakt:
Det hjälper ju inte mycket om det är config uppsättningen som
är oklar, och det görs (tydligen) i själva IDE'n, inte i koden.
Men om det *kan* göras i koden så är det normalt bättre...
> Jag använder XWISP och där kan man inte ställa in det vad jag vet?
Nej, det förväntas att HEX filen är komplett från början.
är oklar, och det görs (tydligen) i själva IDE'n, inte i koden.
Men om det *kan* göras i koden så är det normalt bättre...
> Jag använder XWISP och där kan man inte ställa in det vad jag vet?
Nej, det förväntas att HEX filen är komplett från början.

Mvh
-
- Inlägg: 79
- Blev medlem: 22 juni 2006, 16:11:17
- Ort: Lund
- Kontakt:
Kolla bara upp hur de olika färdigförpackade funktionerna igentligen fungerar.
De kanske låser upp processorn lite mer än vad du räknar med. T.ex så
är det ovanligt att en funktion som delay_ms() har något användningsområde
i en riktig applikation. Normalt vill man inte låsa upp processorn på det sättet.
De kanske låser upp processorn lite mer än vad du räknar med. T.ex så
är det ovanligt att en funktion som delay_ms() har något användningsområde
i en riktig applikation. Normalt vill man inte låsa upp processorn på det sättet.
>..delay_ms() har något användningsområde i en riktig applikation. Normalt vill man inte låsa upp processorn på det sättet.
Du menar att det är en mjukvaru delay eller? Den fungerar ungefär likadant som mjukvarulopen jag gör i ASM, dock är det inte en subroutin som man kallar på utan den ligger i programmet så det blir en ny varje gång.. Tar onödigt mycket platts, men ensålänge har jag inget problem med det.
Menar du att man ska använda en timer istället eller?
Micke.prag: Jepp, jag såg den tidigare. Den verkar bara läsa av IO pinnen och sen vänta en stund som "debounce". Så den kanske kan vara bra ibland men det är likabra att lära sig hur man gör själv
--
Jag har fått USART'en att fungera i C nu också, dock har jag ett litet problem med "delay_us(XX)" funktionen.. Det verkar inte som om den accepterar att man skickar en variabel till den, utan att man bara kan skriva in siffrorna dirrekt..
Mvh
Du menar att det är en mjukvaru delay eller? Den fungerar ungefär likadant som mjukvarulopen jag gör i ASM, dock är det inte en subroutin som man kallar på utan den ligger i programmet så det blir en ny varje gång.. Tar onödigt mycket platts, men ensålänge har jag inget problem med det.
Menar du att man ska använda en timer istället eller?
Micke.prag: Jepp, jag såg den tidigare. Den verkar bara läsa av IO pinnen och sen vänta en stund som "debounce". Så den kanske kan vara bra ibland men det är likabra att lära sig hur man gör själv

--
Jag har fått USART'en att fungera i C nu också, dock har jag ett litet problem med "delay_us(XX)" funktionen.. Det verkar inte som om den accepterar att man skickar en variabel till den, utan att man bara kan skriva in siffrorna dirrekt..
Mvh
På min hemsida (under "Freebies") finns det ett projekt som styr 13 servon med en PIC16F628A, källkoden (som är med) är gjort i MikroC...
Alla dessa "delay_us", "setup_uart", "lcd_out" osv. har jag aldrig använd helt enkelt för att de är odukomenterat i den mening att deras källkod inte är med, alltså har man inte koll på vad man egentligen gör.
Att du inte kan skicka en variabel till "delay_us" är bara bra, då släpper du att använda den!
Alla dessa "delay_us", "setup_uart", "lcd_out" osv. har jag aldrig använd helt enkelt för att de är odukomenterat i den mening att deras källkod inte är med, alltså har man inte koll på vad man egentligen gör.
Att du inte kan skicka en variabel till "delay_us" är bara bra, då släpper du att använda den!
Antagligen kan du skicka en symbol/konstant till delay_ms(), men du kan
kanske inte skicka en variable som inte är har ett känt värde vid "compile-time". Så det beror lite på vad du menar med en "variabel"...
> Du menar att det är en mjukvaru delay eller?
Visst är den det !
> Menar du att man ska använda en timer istället eller?
Jag menar att den övergripande applikations designen styr vad man
ska använda. Ofta innebär det att olika "delays" kombineras ihop till
någon gemensam klocka som servar flera olika behov i applikationen.
Att ha en massa delay_ms() är att be om problem senare vid underhåll
av applikationen.
Eftersom delay_ms tydligen skapar en specifik kodsnutt för varje anrop
så är det ju ganska självklart att parametern *måste* vara känd
vid compile-time...
Det är inget fel i sig på programvaru-delayer, men när det blir så pass
långa tider så att det går att räkna i hela ms så är det nog inte så praktiskt.
Är det däremot ett tiotal us så är det mindre problem.
Men, i slutänden så är detta, så klart, väldigt applikationsspecifikt...
> Den verkar bara läsa av IO pinnen och sen vänta en stund som "debounce".
Och det är det där med "en stund" som är problemet. Du kanske vill
göra något annat under tiden än att "sitta fast" i just den rutinen.
kanske inte skicka en variable som inte är har ett känt värde vid "compile-time". Så det beror lite på vad du menar med en "variabel"...
> Du menar att det är en mjukvaru delay eller?
Visst är den det !
> Menar du att man ska använda en timer istället eller?
Jag menar att den övergripande applikations designen styr vad man
ska använda. Ofta innebär det att olika "delays" kombineras ihop till
någon gemensam klocka som servar flera olika behov i applikationen.
Att ha en massa delay_ms() är att be om problem senare vid underhåll
av applikationen.
Eftersom delay_ms tydligen skapar en specifik kodsnutt för varje anrop
så är det ju ganska självklart att parametern *måste* vara känd
vid compile-time...
Det är inget fel i sig på programvaru-delayer, men när det blir så pass
långa tider så att det går att räkna i hela ms så är det nog inte så praktiskt.
Är det däremot ett tiotal us så är det mindre problem.
Men, i slutänden så är detta, så klart, väldigt applikationsspecifikt...
> Den verkar bara läsa av IO pinnen och sen vänta en stund som "debounce".
Och det är det där med "en stund" som är problemet. Du kanske vill
göra något annat under tiden än att "sitta fast" i just den rutinen.
Tack Icecap! Jag har läst igenom den koden, men den är lite för avancerad, så jag fattar inte allt
.
Men jag tänkte att jag kan använda timer2 för att göra den pausen som behövs för att styyra servona (mellan 1 och 2ms). Timer0 används nu för att göra en 13ms pause mellan att servon får sina signaler.
Jag tänkte att jag har en kristall på 19,17Mhz så ställer jag timer2 på 1:1 prescale, och laddar PR2 registret med 240 (decimalt). Då kommer jag få ett interuppt från timer2:
19 170 000Hz / 4 (Fosc/4) = 4 792 500Hz
4 792 500Hz / 240 = 19968,75Hz
1/19968,75Hz = 50,078µS
Alltså får jag ett interruppt ca. var 50'e mikrosekund, då kan jag öka en variabel och när den har kommit till 30 (från 0) så har det går 1,502mS.
Så då kan jag alltså styra servona med en precision på 50µS vilket räcker fin fint för mig.
Det jag funderar över är bara att jag ska hinna med en seriel komunikation där jag ska överföra ca. 10byte mellan varje gång jag uppdatterar servona.. Så frågan är om jag hinner det..
Vad tror ni om detta sättet?
Mvh

Men jag tänkte att jag kan använda timer2 för att göra den pausen som behövs för att styyra servona (mellan 1 och 2ms). Timer0 används nu för att göra en 13ms pause mellan att servon får sina signaler.
Jag tänkte att jag har en kristall på 19,17Mhz så ställer jag timer2 på 1:1 prescale, och laddar PR2 registret med 240 (decimalt). Då kommer jag få ett interuppt från timer2:
19 170 000Hz / 4 (Fosc/4) = 4 792 500Hz
4 792 500Hz / 240 = 19968,75Hz
1/19968,75Hz = 50,078µS
Alltså får jag ett interruppt ca. var 50'e mikrosekund, då kan jag öka en variabel och när den har kommit till 30 (från 0) så har det går 1,502mS.
Så då kan jag alltså styra servona med en precision på 50µS vilket räcker fin fint för mig.
Det jag funderar över är bara att jag ska hinna med en seriel komunikation där jag ska överföra ca. 10byte mellan varje gång jag uppdatterar servona.. Så frågan är om jag hinner det..
Vad tror ni om detta sättet?
Mvh
Jag tänkte att under den tiden som timer2 rullar kanske jag får ignorera USART'en och se till att jag får datan efter att jag har skickat pulsen till servona, då har jag ju ca. 10mS på mig, räcker det till 10byte tror ni?
Den seriella komunikationen ska gå mellan två PIC'ar, den ena kommer få köra på mjukvaru USART, men denna ska kunna gå på hårdvaru USART'en.
USART'en är väll det snabbaste sättet att skicka data mellan PIC'arna? Jag funderade på manchesterprotokollet (stavning?) men det tog ca. 25mS per byte..
Mhv
Den seriella komunikationen ska gå mellan två PIC'ar, den ena kommer få köra på mjukvaru USART, men denna ska kunna gå på hårdvaru USART'en.
USART'en är väll det snabbaste sättet att skicka data mellan PIC'arna? Jag funderade på manchesterprotokollet (stavning?) men det tog ca. 25mS per byte..
Mhv