Jag har en variabel som uppdateras kontinuerligt av ett timer interrupt. Denna variabel används sedan av huvudprogrammet, detta leder till att det kan uppträda situationer då två olika delar av programmet vill komma åt variabeln samtidigt vilket leder till lorrupt data.
Jag tänkte lösa detta genom att inte tillåta timer interrupts medans huvudprogammet jobbar med variabeln, vilket inte borde fungera.
Min fråga är om ev. missade timer interrupts kommer att utföras så fort avbrotten slås på igen. Dvs. sätts interrupt flaggan även om interrupt är avstängda?
interrupts och delning av variabler med PIC
-
matseng
- Inlägg: 2360
- Blev medlem: 16 september 2003, 17:18:13
- Ort: Dubai, United Arab Emirates
- Kontakt:
Jag förmodar att du tänkt igenom problemet så att du vet att du verkligen har ett "samtidighets"-problem.
Det är inte alltid som det spelar någon roll. Om interruptet bara räknar upp en 8-bitars variabel från 0 till 255 och låter den wrappa automatiskt, och huvudprogrammet bara läser från variabeln så har du inget problem.
Ska variabeln bara räkna upp från 0 till 99 så flytta väret till en temporär variabel, öka med 1, kolla om det är >99 och då ändra till 0, och sedan skriv tillbaka till till den riktiga variabeln. Inga problem då heller.
Om båda "trådarna" ska ändra variabeln och man använder intruktioner som är atomära (dvs gör läs-modifiera-skriv i en ointerruptbar enstaka instruktion) så är det inte heller något problem.
Värre är det förståss om du ska skriva från båda och wrappa på något mindre än 255 eller om du har en 16 bitars variabel. Då är är det nästan bara att disabla/enabla interrupt som gäller.
Det är inte alltid som det spelar någon roll. Om interruptet bara räknar upp en 8-bitars variabel från 0 till 255 och låter den wrappa automatiskt, och huvudprogrammet bara läser från variabeln så har du inget problem.
Ska variabeln bara räkna upp från 0 till 99 så flytta väret till en temporär variabel, öka med 1, kolla om det är >99 och då ändra till 0, och sedan skriv tillbaka till till den riktiga variabeln. Inga problem då heller.
Om båda "trådarna" ska ändra variabeln och man använder intruktioner som är atomära (dvs gör läs-modifiera-skriv i en ointerruptbar enstaka instruktion) så är det inte heller något problem.
Värre är det förståss om du ska skriva från båda och wrappa på något mindre än 255 eller om du har en 16 bitars variabel. Då är är det nästan bara att disabla/enabla interrupt som gäller.
precis så är det. Jag jobbar med en 32 bitars integer vilket gör att det tar flera operationer att utföra aritmetiska operationer på variabeln. Detta ställer nästan aldrig till med några problem. Men jag har fått underliga värden ibland och det enda jag spåra problemet till är just dettaa eftersom att de underliga värdena uppträder slumpmässigt.
Hur snabb timer hade du tänkt dig?
Om du disablar timern medans du behandlar värdet på sidan av så går det ofta åt väldigt många instruktioner innan man måste kompensera den tid interruptet var disablat. Men givetvis beror det på i vilken hastighet timern är satt.
En annan idé är att låta timern sätta en flagga, som du kollar efter i "huvudloopen" (där även din hantering av variabeln finns), och är den satt så öker du värdet direkt i loopen.
Det gör att den automatiskt kommer att kompensera tiden med nästan den dubbla klocktiden.
Figurera att du får en flagga, du ökar variablen, hanterar värdet om så behövs. Om nu klockan har flaggat en gång, så kommer du ju att öka värdet och "släcka" flaggan för att nästa varv kolla av flaggan igen.
Om du missar hela två flaggningar från timern är det inte mycket att göra åt tyvärr.
Men ett "litet" tips iaf...
Mvh
speakman
Om du disablar timern medans du behandlar värdet på sidan av så går det ofta åt väldigt många instruktioner innan man måste kompensera den tid interruptet var disablat. Men givetvis beror det på i vilken hastighet timern är satt.
En annan idé är att låta timern sätta en flagga, som du kollar efter i "huvudloopen" (där även din hantering av variabeln finns), och är den satt så öker du värdet direkt i loopen.
Det gör att den automatiskt kommer att kompensera tiden med nästan den dubbla klocktiden.
Figurera att du får en flagga, du ökar variablen, hanterar värdet om så behövs. Om nu klockan har flaggat en gång, så kommer du ju att öka värdet och "släcka" flaggan för att nästa varv kolla av flaggan igen.
Om du missar hela två flaggningar från timern är det inte mycket att göra åt tyvärr.
Men ett "litet" tips iaf...
Mvh
speakman
Jag har testat både att stänga av avbrotten och köra flag metoden nu men felet med "underliga" värden kvarstår. Så jag fortsatta att felsöka och kom fram till att PICen resteas lite då och då så jag slängde in lite debug kod för att kolla vilken reset det var fråga om det visar sig att det är Brown out Reseten som får PICen att starta om.
Jag fattar inte varför den gör det, jag kör för tillfället på ett en molex kontakt från min dators 5V line som, enligt Mother Board Manager, ger helt stabila spänningar, så jag fattar inte varför PICen resetar.
Får forska vidare på detta.
Jag fattar inte varför den gör det, jag kör för tillfället på ett en molex kontakt från min dators 5V line som, enligt Mother Board Manager, ger helt stabila spänningar, så jag fattar inte varför PICen resetar.
Får forska vidare på detta.
Har precis hittat vad som var fel. Sånt här kan man bli sinnessjuk av. Jag började leta i helt fel ända, nämligen koden. Men det visade sig nu efter en trevlig kväll tillsammans med många små sladdar att det var en sladd som låg och kortslöt en port på PICen med ojämna mellan rum. Ett så ofantligt lätt fel men så otroligt svårt att hitta...
