Jag börjar få ordning på PIC och dess Assembler.
Nya frågor blir det dock...
Jag kan förresten rekommendera vad Lewis Loflin delar med sig av på nätet.
När han skriver sina programexempel går han genom det hela grundligt.
Nå, en ny fråga...
Hur långt kan man nysta CALL?
Ja ja, det heter nesting på engelska, och nästa på halv svengelska, nysta blir det. ...garnnystan, eller spagettibrunn om man (kapp-) seglar.
Alltså stapla gosub-rutiner in i varandra?
Det står saker som "• 8-level deep hardware stack" och "The PIC12F683 has a 13-bit program counter capable of addressing an 8k x 14 program memory space.", men hur kan man läsa ut hur många nystningar den håller reda på?
PICking PICling
Re: PICking PICling
> Hur långt kan man nysta CALL?
Svaret har du så klart redan nämnt själv:
> 8-level deep hardware stack.
Dra bort 1 om du även använder interrupt.
Storleken på programminnet (flash) är komplett ointressant.
Detta gäller de lite äldre PIC16. De modernare PIC16F1xxx har en 16 pos stack.
Nu så är både 8 och 16 ändå rellativt djupt för att vara en call-stack, det behövs
en rellativt komplex applikation för att köra det "i taket".
Svaret har du så klart redan nämnt själv:
> 8-level deep hardware stack.
Dra bort 1 om du även använder interrupt.
Storleken på programminnet (flash) är komplett ointressant.
Detta gäller de lite äldre PIC16. De modernare PIC16F1xxx har en 16 pos stack.
Nu så är både 8 och 16 ändå rellativt djupt för att vara en call-stack, det behövs
en rellativt komplex applikation för att köra det "i taket".
Re: PICking PICling
Tack sodjan. 
Dock nämnde jag inte svaret, endast exempel på var svaret torde gå hitta.
Om det inte stått "hardware stack" utan det mer begripliga, för att inte säga betydligt mer relevanta, "callstack" så hade frågan knappt ens behövt ställas.
Det är varken PIC eller dess Assembler som ställer till det.
Sättet MicroChip skriver sina produkters manualer, det är vad som ställer till det.
Dock nämnde jag inte svaret, endast exempel på var svaret torde gå hitta.
Om det inte stått "hardware stack" utan det mer begripliga, för att inte säga betydligt mer relevanta, "callstack" så hade frågan knappt ens behövt ställas.
Det är varken PIC eller dess Assembler som ställer till det.
Sättet MicroChip skriver sina produkters manualer, det är vad som ställer till det.
Re: PICking PICling
Hm...
"8-level deep hardware stack" *är* svaret.
Jag tror att om man läser några olika delar så ger det sig.
Sen så är det ett datablad, ingen manual. Det beskriver
i tekniska termer hur den aktuella processorn fungerar.
Microchip anses generellt ha ganska bra datablad.
Du anger inte vilken processor det är så det går inte
att hänvisa vidare till faktiska kapitel i databladet.
"8-level deep hardware stack" *är* svaret.
Jag tror att om man läser några olika delar så ger det sig.
Sen så är det ett datablad, ingen manual. Det beskriver
i tekniska termer hur den aktuella processorn fungerar.
Microchip anses generellt ha ganska bra datablad.
Du anger inte vilken processor det är så det går inte
att hänvisa vidare till faktiska kapitel i databladet.
Re: PICking PICling
Nedan utgår jag från PIC12F683.
En ADC ger ett tio-bitars värde, som hamnar i dels ADRESH och dels i ADRESL.
(Jag låter bli fråga varför...)
Vad jag gärna vill ha reda på, vilket ni här ju brukar kunna hjälpa till med, är var vilka av dessa tio bit hamnar var vid left respektive right justification (ADFM)?
Om jag förstår det hela rätt så blir det som följer:
Vid ADFM = 0 (left justification) ...
I ADRESH hamnar de åtta högsta bitarna, vilket ger ett något avrundat värde.
De två kvarvarande, LSB, hamnar i ADRESL<7:6>, som lite av slaggprodukt.
Vid ADFM = 1 (right justification) ...
I ADRESH hamnar två bitar (ADRESH<1:0> som bildar ett två bit extremt toppvärde, våldsamt avrundat.
Resten hamnar i ADRESL, som ganska ordentligt hög med slagg.
Korrekt...?
Och ungefär på samma vis behandlas PWM?
Dvs PWM'n i sig är iofs tio bit, men MSB<9:2> ligger i CCPR1L<7:0> och LSB i CCP1CON<5:4>?
För att nå full PWM måste CCPR1L vara 0xFF och CCP1CON<5:4> båda vara 1, korrekt?
Och för att nå PWM noll måste dels CCPR1L vara 0x00 och CCP1CON<5:4> båda vara 0 korrekt?
Skulle jag få max/min PWM om jag satte både CCPR1L och CCPR1H till max (0xFF) respektive båda till 0x00...?
(Javisst når jag PWM noll om jag BSF TRISIO,0x2, men det är inte önskat att slå av PWM'n.
Endast att nå dess absolut lägsta läge.)
En ADC ger ett tio-bitars värde, som hamnar i dels ADRESH och dels i ADRESL.
(Jag låter bli fråga varför...)
Vad jag gärna vill ha reda på, vilket ni här ju brukar kunna hjälpa till med, är var vilka av dessa tio bit hamnar var vid left respektive right justification (ADFM)?
Om jag förstår det hela rätt så blir det som följer:
Vid ADFM = 0 (left justification) ...
I ADRESH hamnar de åtta högsta bitarna, vilket ger ett något avrundat värde.
De två kvarvarande, LSB, hamnar i ADRESL<7:6>, som lite av slaggprodukt.
Vid ADFM = 1 (right justification) ...
I ADRESH hamnar två bitar (ADRESH<1:0> som bildar ett två bit extremt toppvärde, våldsamt avrundat.
Resten hamnar i ADRESL, som ganska ordentligt hög med slagg.
Korrekt...?
Och ungefär på samma vis behandlas PWM?
Dvs PWM'n i sig är iofs tio bit, men MSB<9:2> ligger i CCPR1L<7:0> och LSB i CCP1CON<5:4>?
För att nå full PWM måste CCPR1L vara 0xFF och CCP1CON<5:4> båda vara 1, korrekt?
Och för att nå PWM noll måste dels CCPR1L vara 0x00 och CCP1CON<5:4> båda vara 0 korrekt?
Skulle jag få max/min PWM om jag satte både CCPR1L och CCPR1H till max (0xFF) respektive båda till 0x00...?
(Javisst når jag PWM noll om jag BSF TRISIO,0x2, men det är inte önskat att slå av PWM'n.
Endast att nå dess absolut lägsta läge.)
Re: PICking PICling
> Korrekt...?
Ja, förrutom att det du kallar "slagg" är en del av ADC värdet.
Beroende på vad du ska använda det till så väljer du vänster
eller högerjusterat. Efter register har 8 bitar och ADC'n ger ett
tio bitars resultat, så måste det ju bli två register...
CCPR1H har ingenting med PWM att göra. För övrigt stämmer
väl det du skriver kring PWM modulen.
Ja, förrutom att det du kallar "slagg" är en del av ADC värdet.
Beroende på vad du ska använda det till så väljer du vänster
eller högerjusterat. Efter register har 8 bitar och ADC'n ger ett
tio bitars resultat, så måste det ju bli två register...
CCPR1H har ingenting med PWM att göra. För övrigt stämmer
väl det du skriver kring PWM modulen.
Re: PICking PICling
Givetvis måste ett värde om tio bitar använda, minst, två register om åtta bitar; det vore besynnerligt annars.
Japp, CCPR1H används vid PWM; dock Read Only.
För att ge PWM dess fulla intervall måste både CCPR1L och DC1B användas. Check.
Hm...
Hur skulle en #define som fyllde, eller tömde, CCPR1L och DC1B se ut, månne?
Eller kanske att en INCFSZ/DECFSZ på CCPR1L skulle leda till BSF respektive BCF av DC1B...?
Japp, CCPR1H används vid PWM; dock Read Only.
För att ge PWM dess fulla intervall måste både CCPR1L och DC1B användas. Check.
Hm...
Hur skulle en #define som fyllde, eller tömde, CCPR1L och DC1B se ut, månne?
Eller kanske att en INCFSZ/DECFSZ på CCPR1L skulle leda till BSF respektive BCF av DC1B...?
Re: PICking PICling
I all fall - Framåt gossar blå!
Om jag förstår interupt rätt så ser man inte vilken GPIO som ändrat sitt läge, endast att någon av de, som är ställda till det i IOC, har ändrats, korrekt?
Sedan blir jag lite fundersam på vad det är för speciellt med GP2/INT.
Är det att just denna I/O kan man se individuellt?
Om jag förstår interupt rätt så ser man inte vilken GPIO som ändrat sitt läge, endast att någon av de, som är ställda till det i IOC, har ändrats, korrekt?
Sedan blir jag lite fundersam på vad det är för speciellt med GP2/INT.
Är det att just denna I/O kan man se individuellt?
Re: PICking PICling
INT (den gamla typen av interrupt) och IOC (interrupt on change)
har bl.a egna flaggor som anger vad som har inträffat. Och INT typen
av extern interrupt har funnit "hur länge som helst", i princip. IOC är
ett lite mer modernt påfund.
Om man har flera pinnar igång med IOC så får man kolla på pinnarna
och jämföra med ett lagrat läge för att avgöra vad som har ändrats.
Så det är pinnarna i själv själva som meddelar vilken som har ändrats.
INT skulle väl kunna vara marginellt snabbare att hantera eftersom
man inte behöver undersöka *vilken* pinne det var, det finns
ju bara en...
har bl.a egna flaggor som anger vad som har inträffat. Och INT typen
av extern interrupt har funnit "hur länge som helst", i princip. IOC är
ett lite mer modernt påfund.
Om man har flera pinnar igång med IOC så får man kolla på pinnarna
och jämföra med ett lagrat läge för att avgöra vad som har ändrats.
Så det är pinnarna i själv själva som meddelar vilken som har ändrats.
INT skulle väl kunna vara marginellt snabbare att hantera eftersom
man inte behöver undersöka *vilken* pinne det var, det finns
ju bara en...
Re: PICking PICling
Tack Janne.
Det var som jag förstått det då, det går ju bättre å bättre det här.
Låt oss ta en luring.
Om vi nu förutsätter att inget används förrän allt är klart - spelar det någon roll vilken ordning man fixar till SFR?
Det var som jag förstått det då, det går ju bättre å bättre det här.
Låt oss ta en luring.
Om vi nu förutsätter att inget används förrän allt är klart - spelar det någon roll vilken ordning man fixar till SFR?
Re: PICking PICling
OK, låt oss se om jag fått även detta rätt...
Jag vill ha en händelse med fast tidsintervall för att uppdatera olika räknare när denna flödar över.
Detta torde vara grunden - Timer0 använder den interna klockan.
BCF OPTION_REG,T0CS ; 0 = Internal instruction cycle clock (FOSC/4)
Den stegas en gång per instruktion (Fosc/4), dvs en gång per µs.
För att använda den så behövs...
BSF INTCON,T0IE
; Timer0 Overflow Interrupt Enable bit.
; 1 = Enables the Timer0 interrupt.
Och man får reda på att TMR0 flödat över genom att INTCON,T0IF blir 1.
Vilket skapar en interupt... Men var?
Dvs hamnar alla interupt på samma....
ORG 0x04
goto IRQ_CALL
....?
Vad gör Prescaler?
För att ge en begriplig funktion tänker jag att om PS<2:0> sätts till 011, dvs 1:16 i detta fall, så räknas TMR0 en gång per sexton instruktioner, var 16µs, korrekt?
Om jag med samma PS skulle sätta IRCF<2:0> (Internal Oscillator Frequency Select) till 100 (1MHz), dvs Fosc/1, skulle TMR0 stegas var 64µs, eller?
Sedan då...
...är det säkert saker jag inte fått med.
Jo visst!
Är inte STATUS kapslat från vad som händer inom interupt-rutinen?
Dvs vad än som händer vid utförandet av ett Interupt Call ska väl värdet i STATUS och W etc återställas vid RETURN...?
Jag vill ha en händelse med fast tidsintervall för att uppdatera olika räknare när denna flödar över.
Detta torde vara grunden - Timer0 använder den interna klockan.
BCF OPTION_REG,T0CS ; 0 = Internal instruction cycle clock (FOSC/4)
Den stegas en gång per instruktion (Fosc/4), dvs en gång per µs.
För att använda den så behövs...
BSF INTCON,T0IE
; Timer0 Overflow Interrupt Enable bit.
; 1 = Enables the Timer0 interrupt.
Och man får reda på att TMR0 flödat över genom att INTCON,T0IF blir 1.
Vilket skapar en interupt... Men var?
Dvs hamnar alla interupt på samma....
ORG 0x04
goto IRQ_CALL
....?
Vad gör Prescaler?
För att ge en begriplig funktion tänker jag att om PS<2:0> sätts till 011, dvs 1:16 i detta fall, så räknas TMR0 en gång per sexton instruktioner, var 16µs, korrekt?
Om jag med samma PS skulle sätta IRCF<2:0> (Internal Oscillator Frequency Select) till 100 (1MHz), dvs Fosc/1, skulle TMR0 stegas var 64µs, eller?
Sedan då...
...är det säkert saker jag inte fått med.
Jo visst!
Är inte STATUS kapslat från vad som händer inom interupt-rutinen?
Dvs vad än som händer vid utförandet av ett Interupt Call ska väl värdet i STATUS och W etc återställas vid RETURN...?
Re: PICking PICling
Det ovan är att veta.
Men...;
Problemet som uppkommit och inte ser ut vilja ge sig är att den inverterade sensorn på GP3 inte reagerar som den ska, inte med en gång som tidigare.
Den måste helt plötsligt komma tillbaka till Off (alltså hög) för att släppa fram On (låg) att börja arbeta.
Det ska inte vara några interupt eller så som spökar, det finns inga igång.
Sammanfattningsvis måste GP3 gå ner och upp igen innan den kommer igång.
Jag har för mig jag sett något om latch mellan GPIO och TRISIO, men varför nu?
Men...;
Problemet som uppkommit och inte ser ut vilja ge sig är att den inverterade sensorn på GP3 inte reagerar som den ska, inte med en gång som tidigare.
Den måste helt plötsligt komma tillbaka till Off (alltså hög) för att släppa fram On (låg) att börja arbeta.
Det ska inte vara några interupt eller så som spökar, det finns inga igång.
Sammanfattningsvis måste GP3 gå ner och upp igen innan den kommer igång.
Jag har för mig jag sett något om latch mellan GPIO och TRISIO, men varför nu?
Re: PICking PICling
> spelar det någon roll vilken ordning man fixar till SFR?
Det är ganska vanligt att man man ställer in allt först och sist
sätter "on" flaggan för de enheter som har sådan.
> Vad gör Prescaler?
Det är en "växellåda" som ligger mellan systemklocken och Timer0.
Den växlar ner klockan och får Timer0 att gå långsammare.
> Är inte STATUS kapslat från vad som händer inom interupt-rutinen?
> Dvs vad än som händer vid utförandet av ett Interupt Call ska väl värdet i STATUS och W etc återställas vid RETURN...?
Detta beror till stor del vilken PIC modell du jobbar med. Men oavsett vilken det är
så är detta en sak som brukar vara tydligt dokumenterat. Du har rätt i sak att vissa
register ska/bör/måste återställas (det beror ju lite på vad ISR'en använder också),
men om det måste ska i koden eller om det sker automatiskt beror på PIC modell.
I sista inlägget är det lite oklart vad du menar. Med "reagerar", menar du IOC?
Notera att IOC reagerar på *ändringar*, d.v.s själva flanken hög->låg eller låg->hög,
alltså inte själva nivån hög eller låg i sig. Om det nu var det du talade om...
Det är ganska vanligt att man man ställer in allt först och sist
sätter "on" flaggan för de enheter som har sådan.
> Vad gör Prescaler?
Det är en "växellåda" som ligger mellan systemklocken och Timer0.
Den växlar ner klockan och får Timer0 att gå långsammare.
> Är inte STATUS kapslat från vad som händer inom interupt-rutinen?
> Dvs vad än som händer vid utförandet av ett Interupt Call ska väl värdet i STATUS och W etc återställas vid RETURN...?
Detta beror till stor del vilken PIC modell du jobbar med. Men oavsett vilken det är
så är detta en sak som brukar vara tydligt dokumenterat. Du har rätt i sak att vissa
register ska/bör/måste återställas (det beror ju lite på vad ISR'en använder också),
men om det måste ska i koden eller om det sker automatiskt beror på PIC modell.
I sista inlägget är det lite oklart vad du menar. Med "reagerar", menar du IOC?
Notera att IOC reagerar på *ändringar*, d.v.s själva flanken hög->låg eller låg->hög,
alltså inte själva nivån hög eller låg i sig. Om det nu var det du talade om...
Re: PICking PICling
Tack.
OK, Prescaler fungerar som jag beskrev det då alltså.
I alla fall, borde man inte kunna ändra detta med...
OPTION_REG
INTEDG: Interrupt Edge Select bit
1 = Interrupt on rising edge of INT pin
0 = Interrupt on falling edge of INT pin
...vilket inte borde ställa till det - INTEDG står ju redan på 1, dvs rising (leading) edge.
Men just detta förefaller inte påverka, dvs problemet kvarstår oavsett 1 eller 0.
OK, Prescaler fungerar som jag beskrev det då alltså.
Så vilken flak det aktiveras på ska ju inte påverka. Eller om det är så ändå...?Det ska inte vara några interupt eller så som spökar, det finns inga igång.
I alla fall, borde man inte kunna ändra detta med...
OPTION_REG
INTEDG: Interrupt Edge Select bit
1 = Interrupt on rising edge of INT pin
0 = Interrupt on falling edge of INT pin
...vilket inte borde ställa till det - INTEDG står ju redan på 1, dvs rising (leading) edge.
Men just detta förefaller inte påverka, dvs problemet kvarstår oavsett 1 eller 0.
