det blir nog väldigt svårt att räkna ut hur lång tid c-koden tar att exekvera eftersom kompilatorn optimerar koden och håller på... så man måste nog nästan titta på assemblerkoden tror jag :/
Man kan ansluta RTC (realtimecountern) så den ökar på varje, varannan etc klockcykel. Resetta den vid start, när programmet är slut, hämta svaret i RTC. Den kopplingen kan man ju även använda i själva programmet om det går på tid.
MPLAB simulerar RTC bra. Fast RTC skippar alltid två cyclar efter en reset(även i chipet).
Det är så att jag försöker göra några "enkla" RTOS funktioner. Och då vill jag ha en funktion "TIMEOUT" som återkommer till varje process efter TIMEOUT.
Vet nån om det redan finns färdiga RTOS funktioner för mikrokontroller? På microchip.com har de ju lagt upp några enkla rutiner till hur man kan realisera, men jag tänkte något kraftfullare....
Du menar något som klallar och går, även om ditt program stannat? Då skulle du antingen kunna använda RTC (timer1) med interrupt on overflow, interuptrutinen skulle då kunna kolla/fiksa processen, eller du kan använda vakthunden, den resetter hela processorn om du (ditt program) inte ger den en signal (reset) inom 'timeout' kan man säga.
Nja...inte riktigt...har man arbetat med RTOS så vet man att det finns möjlighet att få "delay" rutiner i en process samtidigt som man kör en anna process...Genom att bestämma TIMEOUT i ms (time slice) så kan man köra flera processer parallellt...nåt sånt har jag i tanken iaf....
Jag tänkte mig att köra med en 16bits timer som bara räknar upp som ska fungera som IDLE. Sen kan man utgå från timers och bestämma när nästa process/operation ska köras. Man missar ju några klockcykler när man jämför o så men det blir säkert inte märkbart....
RTOS har jag aldrig hört talas om men jag förstår ungefär vad du vill göra.
Du vill styra exekveringen av flera oberoende processer som man gör i operativsystem.
Om du tex ska ha 2st processer som växelvis bryts av ett timer-interrupt så att du på det viset får 2st huvudprogram som körs samtidigt.
Jag har funderat på det en stund och kommit fram till att det kräver att man kan läsa och skriva till stacken.
Det går inte med pic16, men med pic18 går det.
Men jag tror inte att det är nödvändigt att använda ett sånt system, man kommer väldigt långt med vanliga interrupt och ett huvudprogram.
Det går faktiskt att simulera flera prioritetsnivåer på interrupten även om hårdvaran i Pic16 bara har 1 nivå.
Pic18 har 2 prioritetsnivåer i hårdvaran.
Ett (oftast relativt kompakt) operativsystem, vars främsta prioritet är att garantera att processerna får kort och framförallt predikterbar svarstid.
I t.ex. en mobiltelefon finns det ett RTOS, som bland annat har till syfte att hantera inkommande GSM-paket. För att inte samtalet ska brytas måste processen som tar hand om paketet göra detta fort och regelbundet. Det hade aldrig gått att skriva separata processer i UNIX/Linux/Windows för att hantera sådana här saker. Helt plötsligt tar det några sekunder innan en process vaknar och vips har samtalet brutits. Ett exempel på RTOS är Eneas OSE.
Vanliga OS som t.ex. Linux brukar kallas GPOS (General Purpose OS).
Precis. De flesta RTOS som finns kräver kraftiga processorer, jämför med en vanlig 8-bits PIC! Det skulle då vara mycket lättare att konstruera applikationer som kör flera saker parallellt...
Jag skrev en gång nåt som skulle kunna kallas ett väldigt enkelt RTOS för PIC16. Jag hade upp till 8 strikt prioriterade "trådar", och bara kooperativ multitasking (dvs varje tråd fick anropa en funktion med jämna mellanrum för att kolla om en annan tråd ville köras). Det fanns en slags enkla mutex och condition-variabler som synkroniserade trådarna och interrupt. Skrev det för ett 16F84-projekt där väldigt mycket skulle göras på en gång, det blev dock aldrig riktigt klart.
Riktig preemptiv multitasking tror jag också kräver PIC18...
DSO-projektet är ganska inaktivt just nu, och det är en hel del kvar att göra. Men fömodligen ska det bli klart under hösten, beroende på tid förstås...