OK. Det var ju en jäkla skillnad !!
Du skrev från början att du "vill veta pulslängden på dem."
Det behöver du inte alls ! Det vet du ju redan !
Du vill bara se **skillnad** på pulserna, vilket är en helt annan sak !!
Och betydligt enklare...
Jag har tappat sugen, men i princip handlar det om att fixa en
räknare som om man väljer en "lämplig" hastighet
enkelt kan kollas med bit-test operationer vilken
pulslängd det är...
Pulserna är så pass långa och med så stor skillnad, så man behöver
inte använda timern direkt för att mäta perioden.
Definiera 4 räknare i GPR (en för varje räknare)
Nolla varje räknare vid en positiv flank på resp pinne.
Sätt up en timer för t.ex 100 us interrrupt (se nedan).
Räkna upp varje räknare i timer-overflow ISR'en.
Kolla räknaren vid en negativ flank på resp pinne.
Jag skulle "matcha" ihop timerinterruptet med de olika
pulslängderna så att det blir enkelt att "se" vilken puls
det var genom några enkla bit-tester på räknarna...
Du behöver varken RB-interrupt eller IOC, kolla bara de
4 pinnarna i timer-interruptet...
EDIT : Icecap kom imellan, men visst är det fortfarande
intressant/viktigt att veta hur stabila pulstiderna är !!
Tre olika insignaler med CCP
Har ändrat lite i koden nu.. Tydligare? Debugar på PortB nu..
Har bara simulerat hur det skulle se ut och det blinkar och har sig på de 4 lägsta bitarna.
Har tidigare debugat mot terminalfönster och då får man värden från 1 till 20 så det är inte så stabilt precis.. Verkar vara något som ger extra interups.
Har bara simulerat hur det skulle se ut och det blinkar och har sig på de 4 lägsta bitarna.
Har tidigare debugat mot terminalfönster och då får man värden från 1 till 20 så det är inte så stabilt precis.. Verkar vara något som ger extra interups.
Senast redigerad av ankan 7 april 2006, 10:45:23, redigerad totalt 3 gånger.
Menade och menade... 
I och för sig funderade jag utifrån ett assembler perspektiv.
Jag har ingen uppfattning om hurvida det fortfarande är
rellevant om man kör (t.ex) C.
En liten detalj bara, du behöver antagligen inte göra "GIE=1" själv...
> Följande kod skickar ut lite alla möjliga siffror.
Vad är "skickar ut" ? Och vad är "alla möjliga siffror" ?
Koden saknar helt kommenterar, så den som vill kolla får
gissa en massa. Det saknas beskrivning av vad RA0 används till.
I och för sig funderade jag utifrån ett assembler perspektiv.
Jag har ingen uppfattning om hurvida det fortfarande är
rellevant om man kör (t.ex) C.
En liten detalj bara, du behöver antagligen inte göra "GIE=1" själv...
> Följande kod skickar ut lite alla möjliga siffror.
Vad är "skickar ut" ? Och vad är "alla möjliga siffror" ?
Koden saknar helt kommenterar, så den som vill kolla får
gissa en massa. Det saknas beskrivning av vad RA0 används till.
Har ändrat lite i koden nu.. Tydligare? Debugar på PortB nu..
Har bara simulerat hur det skulle se ut och det blinkar och har sig på de 4 lägsta bitarna.
Har tidigare debugat mot terminalfönster och då får man värden från 1 till 20 så det är inte så stabilt precis.. Verkar vara något som ger extra interups.
Har bara simulerat hur det skulle se ut och det blinkar och har sig på de 4 lägsta bitarna.
Har tidigare debugat mot terminalfönster och då får man värden från 1 till 20 så det är inte så stabilt precis.. Verkar vara något som ger extra interups.
Hur påverkas RA0 nu?
Stämmer det att du endast simulerat? Hur blinkar det och har sig då?
>>TMR0=8; // För att det ska vara samma värde efter timerinterupp och första gången.
Förklara.
>>TMR0=0; // Nollställ räknaren också..
Det här kommer göra så att det tar fler cykler än 256*presc för timern att snurra runt. Det blir ju interrupt när T0=0!
>>OPTION=0b01010000;
Vad blir det för prescaler?
Undran: Heter det TMR0IE/TMR0IF i din kompilator? I min heter de T0IE/T0IF , bitarna heter så enligt databladet.
Sodian:
Varför behöver ankan inte sätta GIE=1 själv?
Stämmer det att du endast simulerat? Hur blinkar det och har sig då?
>>TMR0=8; // För att det ska vara samma värde efter timerinterupp och första gången.
Förklara.
>>TMR0=0; // Nollställ räknaren också..
Det här kommer göra så att det tar fler cykler än 256*presc för timern att snurra runt. Det blir ju interrupt när T0=0!
>>OPTION=0b01010000;
Vad blir det för prescaler?
Undran: Heter det TMR0IE/TMR0IF i din kompilator? I min heter de T0IE/T0IF , bitarna heter så enligt databladet.
Sodian:
Varför behöver ankan inte sätta GIE=1 själv?
Borde nog bränna ut programmet och testa.. Men jag vet inte hur jag ska testa då. Hur kan jag läsa av värdet den får i picen på ett vettigt sätt?
Smartast borde vara att räkna lite på hur långt räknaren ska hinna för en viss längd på puls.
Prescalen har jag bara gissat mig på. Verkar som att jag måste köra 1:1 för att få någon chans att se skillnad på signalerna.
Smartast borde vara att räkna lite på hur långt räknaren ska hinna för en viss längd på puls.
Prescalen har jag bara gissat mig på. Verkar som att jag måste köra 1:1 för att få någon chans att se skillnad på signalerna.
Japp, man måste sätt GIE=1 *en* gång, annars går inte interrupten igång alls.
> Men jag vet inte hur jag ska testa då.
Hur testar du *nu* ? Var kommer insignalen från ?
Annars används oftare TMR2 för att generera intervall
med viss längd. Kolla lite på den...
> Hur kan jag läsa av värdet den får i picen på ett vettigt sätt?
Skicka det via USART'en.
Lägg ut det på LEDs (jag trodde att det var det du gjorde
eftersom du skrev att det "blinkade"...).
> Men jag vet inte hur jag ska testa då.
Hur testar du *nu* ? Var kommer insignalen från ?
Annars används oftare TMR2 för att generera intervall
med viss längd. Kolla lite på den...
> Hur kan jag läsa av värdet den får i picen på ett vettigt sätt?
Skicka det via USART'en.
Lägg ut det på LEDs (jag trodde att det var det du gjorde
eftersom du skrev att det "blinkade"...).
>>Insignalen kommer från en annan pic.
Då har det blivit ett missförstånd. Jag trodde att du menade att du simulerat på datorn. Är för övrigt ett väldigt bra sätt att testa koden.
Finns demoversion på ett program som heter PIC Simulator IDE att tanka hem. Med det kan du simulera ditt program. Du kan få en grafisk bild av vad som händer på I/O samt skapa periodiska insignaler vilket kan användas för att testa ditt interrupt. Tror det skulle passa perfekt till det du håller på med.
Då har det blivit ett missförstånd. Jag trodde att du menade att du simulerat på datorn. Är för övrigt ett väldigt bra sätt att testa koden.
Finns demoversion på ett program som heter PIC Simulator IDE att tanka hem. Med det kan du simulera ditt program. Du kan få en grafisk bild av vad som händer på I/O samt skapa periodiska insignaler vilket kan användas för att testa ditt interrupt. Tror det skulle passa perfekt till det du håller på med.
