Hej på er där ute. börjar mer och mer begripa vad man kan göra,och hur man ska gå till väga med att arbeta med interrupt. Nu har jag fått en del funderingar till. Först så kommer min kod se nedan för denna mening.
koden:
list P=18F452
#include <P18F452.INC>
CONFIG OSC=HS ; Sätt in det som stämmer överens med din miljö !!
; CONFIG isrOSCS=OFF, PWRT=ON, BOR=OFF, WDT=OFF, LVP=OFF, DEBUG=OFF
CONFIG CP1=OFF, CP2=OFF, CP3=OFF, CPB=OFF, CPD=OFF
CONFIG WRT1=OFF, WRT2=OFF, WRT3=OFF, WRTB=OFF, WRTC=OFF, WRTD=OFF
CONFIG EBTR1=OFF, EBTR2=OFF, EBTR3=OFF, EBTRB=OFF
;******************************************************************************
;Variable definitions
; These variables are only needed if low priority interrupts are used.
; More variables may be needed to store other special function registers used
; in the interrupt routines.
;
;UDATA
;
;WREG_TEMP RES 1 ;variable in RAM for context saving
;STATUS_TEMP RES 1 ;variable in RAM for context saving
;BSR_TEMP RES 1 ;variable in RAM for context saving
;
; OVANSTÅENDE BEHÖVS INTE...
;
;
;******************Reset_start*************************************************
;Reset and interrupt vectors
code h'0000'
goto Main
ISR_hog code h'8'
goto isr_start_hog
ISR_log code h'18'
goto isr_start_log
;**************************************************************************
;***************interrupt_låg****************************************************
isr_log_code code
isr_start_log
nop
nop
nop
bcf INTCON3,INT1IF ;Clear INT1 external interrupt flag.
retfie
;**************interrupt_hög**************************************************************
isr_hog_code code
isr_start_hog
nop
nop
nop
nop
bcf INTCON3,INT2IF ;Clear INT2 external interrupt flag.
retfie
;***************interrupt_konfig***********************************************
;här ställer jag in konfigruerar jag pic:en EX ställer in Out/in defineras och register ställs in.
;init_code code
init
;****************************Konfig portB*********************************************
Movlw B'11111111'
movwf TRISB ;Sätter PortB till ingångar bit 0-7
;****************************Generella Interrupts inställningar*************
bcf RCON,IPEN ;Disable priority levels on interrupts
bsf INTCON,PEIE ;Enables all unmasked peripheral interrupts
bsf INTCON,GIE ;Enable global interrupts.
;**************************Interrupt ingång 1(INT1)*************************
bsf INTCON2,INTEDG1 ;Interrupt on rising edge
bsf INTCON3,INT1IE ;Enables the INT1 external interrupt
bcf INTCON3,INT1IF ;Clear INT1 external interrupt flag.
bcf INTCON3,INT1IP
;**************************Interrupt ingång 2(INT2)*************************
bsf INTCON2,INTEDG2 ;Interrupt on rising edge
bsf INTCON3,INT2IE ;Enables the INT2 external interrupt
bcf INTCON3,INT2IF ;Clear INT2 external interrupt flag.
bsf INTCON3,INT2IP
;***************************************************************************
return
;*********************Main********************************************
; Start of main program
Main
call init
Loop
nop
nop
goto Loop
;******************************************************************************
;End of program
END
som ni ser så har jag två interruptingångar RB1(INT1) och RB2(INT2).INT1 är satt till låg prioteringsnivå medans prioteringsnivån på INT2 är satt till hög prioteringsnivå. Nu när jag kör programmet så hoppar programmet från huvudprogrammet och kör isr_start_hog subrutinen när jag jag trycker på RB1. det ska den inte göra utan den ska gå till isr_start_log.varför det? Sedan testar jag ändå under subrutinens gång så trycker jag på RB2(INT2) med högre prioteringsnivå än INT1. Men jag antar att programmet kör subrutinen isr_start_log tills retfie kommandot sätter GIE(Global interrupt enable) biten till ett. För att framtida intterupt ska inträffa. Så fattade jag på databladet. För interrupten ska inte kunna bli störd av en annan interrupt.
Så blev i alla fall resultatet av detta. när pic:en körde isr_start_hog så arbetade i denna subrutin tills retfie kommandot dök upp. Då tänkte jag att ok nu är INT2IF flaggan ett så efter detta kommando så kommer isr_start_hog att köras igen, men det gjorde det inte. Varför är frågan?.vad är det för mer inställing jag bör göra i mitt konfiguering inställningar sub init.
Står
mina frågor är nu föjande.
fråga 1
Vad menar dom med meningen High priority interrupt events will override any low priority interrupts that may be in progress. Dena mening fattar jag som att om interrupt med låg prio körs kan den brytas när som helst med en hög prioterad Interrupt. Så i mitt fall jag beskrev tidigare så borde programmet hoppa ur och köra den hög prioterings subrutinen(isr_start_hog). Men då får ju GIE biten ingen funktion. Den ska blocka interrupt källor när en interrupt körs.Den vill inte bli stör i en interrupt precis.
Kan någon bena ut mina funderingar och förviringar.
i data bladet står det klart och tydligt adress H8 är vector adress för hög priotering medans H18 är för låg priotering.
fråga 2
Sedan fundera jag på om jag har programmerat rätt om jag vill ha två ingångar RB1, OCH RB2 med två olika prioteringsnivåer HÖG=RB2 och låg=RB1 ingången. Sedan ska det vara en subrutin för vardera en för hög prioteringsinterrupt(isr_start_hog) sedan en för låg(isr_start_log)?
fråga 3
Funderar på kanske på att han en ingång till in på pic:en. INT 0 alltså. Denna interrupt signal ska också ha en subrutin. I mitt fall behövde jag ha tre vectro adresser H8,H18,HXX. kan man få detta eller inte?
Fråga 4
Testade att trycka på RB2(INT2) i stället för RB1 fört när den var i huvudprogrammet main. Då hände det något sludigt den gick till samma subrutin som för RB1. fattar inget.varför det?
i data bladet står det klart och tydligt adress H8 är vector adress för hög priotering medans H18 är för låg priotering.
MVH Markus Carlsson
interrupt igen ,men börjat att begripa
Använd gärna "code" taggarna så att koden blir läsbar...
Fråga 1 :
De menar precis det de skriver !
Men kanske viktigast, du kör med bara en prio-nivå,
"bcf RCON,IPEN ;Disable priority levels on interrupts".
Fråga 2 :
I princip är det rätt tänkt, men du har inte visat några krav
på applikationer som gör att du måste strula med två
prio-nivåer. Vilka krav på svarstider har du på de två
avbrotten ? Hur lång tid kommer varje avbrottsrutin att ta ?
Det är inte speciellt vanligt att man behöver gå över till
att använda high/low priority, och det medför en
del nackdelar som man måste vara medveten om, t.ex att
det bara finns en uppsättning "shadow" register för WREG,
STATUS och BSR, så de måste hanteras för hand i high
prio avbrottet.
Du kan ha hur många olika avbrottskällor som helst oavsett om
du kör med en eller två prio-nivåer (vilket jag har sagt MÅNGA
gånger tidigare !!! Vad är det som är så svårt att förstå ??)
Mitt förslag är att du kör mer "normalt" med en prio nivå
och kollar vilken xxIF flagga som har triggat avrottet i ISR'en.
I alla fall tills du har visat att applikationen faktiskt kräver
både high/low prio avbrottt...
Fråga 4:
Se svaret på fråga 1...
På fråga 3, vet jag inte...
Fråga 1 :
De menar precis det de skriver !
Men kanske viktigast, du kör med bara en prio-nivå,
"bcf RCON,IPEN ;Disable priority levels on interrupts".
Fråga 2 :
I princip är det rätt tänkt, men du har inte visat några krav
på applikationer som gör att du måste strula med två
prio-nivåer. Vilka krav på svarstider har du på de två
avbrotten ? Hur lång tid kommer varje avbrottsrutin att ta ?
Det är inte speciellt vanligt att man behöver gå över till
att använda high/low priority, och det medför en
del nackdelar som man måste vara medveten om, t.ex att
det bara finns en uppsättning "shadow" register för WREG,
STATUS och BSR, så de måste hanteras för hand i high
prio avbrottet.
Du kan ha hur många olika avbrottskällor som helst oavsett om
du kör med en eller två prio-nivåer (vilket jag har sagt MÅNGA
gånger tidigare !!! Vad är det som är så svårt att förstå ??)
Mitt förslag är att du kör mer "normalt" med en prio nivå
och kollar vilken xxIF flagga som har triggat avrottet i ISR'en.
I alla fall tills du har visat att applikationen faktiskt kräver
både high/low prio avbrottt...
Fråga 4:
Se svaret på fråga 1...
På fråga 3, vet jag inte...
Ett generellt råd i detta: Strunta i olika prioritetar på interrupts fram till du verkligen behöver det! Det är sällsynt att det behövs!
Vad du tydligen vill ha är olika interruptvektorer på olika interrupt och DET FINNS INTE PÅ PIC! OK?
En interrupt är en interrupt! Hur man sedan benar ut VAD som gav interrupten är en annan sak (man kollar först de olika enheters IE-bit och sedan deras IF-bit) men att börja strula till det med att använda olika nivåer är bara att be om jävelskap.
Jag sitter med ett system där den färdiga koden fyller ca: 45K, det finns ca: 9-10 olika enheter som ger interrupt oberoende av varandra och alla ISR (utom 1) har samma interruptprioritet!
Jag har ett real-time system med dubbla duplex seriekommunikationer, fjärrövervakning/justering under drift osv. AD-interrupts på 6 kanaler, 2 timers på olika tider och en del annat roligt.
Så jag tror att du FINT klarar att blinka med lampan på 1 interruptnivå.
Vad du tydligen vill ha är olika interruptvektorer på olika interrupt och DET FINNS INTE PÅ PIC! OK?
En interrupt är en interrupt! Hur man sedan benar ut VAD som gav interrupten är en annan sak (man kollar först de olika enheters IE-bit och sedan deras IF-bit) men att börja strula till det med att använda olika nivåer är bara att be om jävelskap.
Jag sitter med ett system där den färdiga koden fyller ca: 45K, det finns ca: 9-10 olika enheter som ger interrupt oberoende av varandra och alla ISR (utom 1) har samma interruptprioritet!
Jag har ett real-time system med dubbla duplex seriekommunikationer, fjärrövervakning/justering under drift osv. AD-interrupts på 6 kanaler, 2 timers på olika tider och en del annat roligt.
Så jag tror att du FINT klarar att blinka med lampan på 1 interruptnivå.
Markus:
Om du skall ha flera utifrån triggade interrupt kan du ju också använda "Port Change Interrupt" på PORTB (RB4 - RB7). Då har du ju 4 möjliga interruptkällor till. Däremot får du själv kolla vilken "pinne" som sätts/nollas. Interrupt ges för "change" alltså ändring från 0 till 1 eller 1 till 0. Det är upp till dig att koda hur du vill hantera det.
> Den vill inte bli stör i en interrupt precis.
Det är väl det du försöker att göra? Den typ av interrupt du håller på med verkar ju vara just sådan som avbryter ett lägre prioriterat interrupt för att exekvera ett högre prioriterat interrupt.
Annars är det ju bara att strunta i prioriterade interrupt och kolla i din generella interruptrutin vilken av INT0 - INT2 som genererar interrupt, och därefter anropa lämplig hanteringsrutin?
Din uppfattning om vad "prioritet" betyder i detta sammanhang verkar skilja sig från min uppfattning om vad det betyder, så du kanske kan klargöra bättre vad du vill uppnå med "prioritering"? Vad skall prioriteras?
Mats
Om du skall ha flera utifrån triggade interrupt kan du ju också använda "Port Change Interrupt" på PORTB (RB4 - RB7). Då har du ju 4 möjliga interruptkällor till. Däremot får du själv kolla vilken "pinne" som sätts/nollas. Interrupt ges för "change" alltså ändring från 0 till 1 eller 1 till 0. Det är upp till dig att koda hur du vill hantera det.
> Den vill inte bli stör i en interrupt precis.
Det är väl det du försöker att göra? Den typ av interrupt du håller på med verkar ju vara just sådan som avbryter ett lägre prioriterat interrupt för att exekvera ett högre prioriterat interrupt.
Annars är det ju bara att strunta i prioriterade interrupt och kolla i din generella interruptrutin vilken av INT0 - INT2 som genererar interrupt, och därefter anropa lämplig hanteringsrutin?
Din uppfattning om vad "prioritet" betyder i detta sammanhang verkar skilja sig från min uppfattning om vad det betyder, så du kanske kan klargöra bättre vad du vill uppnå med "prioritering"? Vad skall prioriteras?
Mats
Det som igentligen är intressant här, är vilken maximal "latency", alltså
fördröjning, som är acceptabel från det en händelse har inträffat tills
aktuell interrupt kods körs. Så länge denna tid för *något* interrupt
är längre en den längsta tiden för någon (annat) ISR, så är man i
princip "safe". Sen kan det även vara intressant hur ofta interrupt kommer.
Lösningen är oftast att se till att hålla sina ISR'er så korta som möjligt,
och bara utföra det som *måste* göras i ISR'en just där (d.v.s det som
inte får avbrytas av andra interrupt). Resten av bearbetningen körs i "main"
(eller icke-ISR kod i alla fall) och kan då avbryts av andra interrupt, så klart...
Att Markus har blandat ihop interrupt *prioritet* med *källor*, har
jag tjatat om 4-5 gånger i flera olika trådar nu...
fördröjning, som är acceptabel från det en händelse har inträffat tills
aktuell interrupt kods körs. Så länge denna tid för *något* interrupt
är längre en den längsta tiden för någon (annat) ISR, så är man i
princip "safe". Sen kan det även vara intressant hur ofta interrupt kommer.
Lösningen är oftast att se till att hålla sina ISR'er så korta som möjligt,
och bara utföra det som *måste* göras i ISR'en just där (d.v.s det som
inte får avbrytas av andra interrupt). Resten av bearbetningen körs i "main"
(eller icke-ISR kod i alla fall) och kan då avbryts av andra interrupt, så klart...
Att Markus har blandat ihop interrupt *prioritet* med *källor*, har
jag tjatat om 4-5 gånger i flera olika trådar nu...
