Det finns OS där man kan sätta deadlines på trådar. Ett sådant är Rubus. Om man missar en deadline, dvs fortfarande kör när deadline passeras så rapporteras det som ett fatal fel. Rubus är byggt kring två schedulers. En earliest deadline first som hanterar tidsstyrda (röda) trådar och en som hanterar en strikt prioritetsbasering (blå). Röda trådar har alltid prioritet över blå.
Om jag minns rätt, det var ett par år sen jag körde Rubus.
Realtidssystem
> Vadå "dess deadline" ? Finns det OS där man kan sätta en "deadline" på tasks/processer ?
Det är ju det som är poängen att det kan komma en task och fråga OSet om det kan köras innan en viss deadline, OSet kan då antingen acceptera tasken och garanterar då att den kommer att vara färdig innan deadline. Här finns det två svårigheter:
1) Hur vet man hur lång tid det tar att genomföra denna task? Här behövs någon maximal tid som man får beräkna i förväg. (Man vet ju trots allt vad det är meningen att tasken ska göra när man skriver koden) Här är det viktigt att man får en övre gräns. Desto bättre denna estimering är desto bättre nyttjandegrad kan man få i sitt system.
2) Hur vet man om en man hinner göra en task utan att missa någon deadline? Här kan man utnyttja olika schemaläggares egenskaper för att förutsäga detta.
> Och hur hanterar i så fall OS'et det fall där "deadline" passeras ??
Det ska inte hanteras, kanske rapporteras. Är det ett hårt RT-system så är du redan död så det spelar igentligen ingen roll. I ett mjukt RT-system så blir prestandan sämre, som exempel kanske din dvd-spelare börjar hacka och du som användare tycker att det var en dålig dvd-spelare.
En förutsättning för att öht kunna börja fundera på att bygga ett RTOS är att man har en schemaläggare med stör för preemption och prioritering.
Preemption: När nya tasks anländer så avbryts en task med lägre prioritet för att den nyanlända tasken ska kunna köras. Har den nya tasken däremot lägre prioritet så får den vänta.
Prioritering: Att varje task har en prioritet relativt andra tasks. Vanligtvis finns det minst 256 nivåer i ett RTOS.
> Rohan, din beskrivning av multitasking är väl hyggligt OK, även om den
> är kraftigt förrenklad, och jag inte riktigt ser vad som är "problemet". Det du
> kallar för ett "problem" är bara *en* egenskap hos OS'et som man som
> konstruktiör/programmerare får ta hänsyn till.
Givetvis kan man se det som en egenskap hos systemet men det är problem, visserligen framtvingat av hårdvaran men ändock. Detta anser jag eftersom den egentligan uppgiften är att bygga ett så förutsägbart system som det bara är möjligt. Delade resurser är ett stort hinder.
Det är ju det som är poängen att det kan komma en task och fråga OSet om det kan köras innan en viss deadline, OSet kan då antingen acceptera tasken och garanterar då att den kommer att vara färdig innan deadline. Här finns det två svårigheter:
1) Hur vet man hur lång tid det tar att genomföra denna task? Här behövs någon maximal tid som man får beräkna i förväg. (Man vet ju trots allt vad det är meningen att tasken ska göra när man skriver koden) Här är det viktigt att man får en övre gräns. Desto bättre denna estimering är desto bättre nyttjandegrad kan man få i sitt system.
2) Hur vet man om en man hinner göra en task utan att missa någon deadline? Här kan man utnyttja olika schemaläggares egenskaper för att förutsäga detta.
> Och hur hanterar i så fall OS'et det fall där "deadline" passeras ??
Det ska inte hanteras, kanske rapporteras. Är det ett hårt RT-system så är du redan död så det spelar igentligen ingen roll. I ett mjukt RT-system så blir prestandan sämre, som exempel kanske din dvd-spelare börjar hacka och du som användare tycker att det var en dålig dvd-spelare.
En förutsättning för att öht kunna börja fundera på att bygga ett RTOS är att man har en schemaläggare med stör för preemption och prioritering.
Preemption: När nya tasks anländer så avbryts en task med lägre prioritet för att den nyanlända tasken ska kunna köras. Har den nya tasken däremot lägre prioritet så får den vänta.
Prioritering: Att varje task har en prioritet relativt andra tasks. Vanligtvis finns det minst 256 nivåer i ett RTOS.
> Rohan, din beskrivning av multitasking är väl hyggligt OK, även om den
> är kraftigt förrenklad, och jag inte riktigt ser vad som är "problemet". Det du
> kallar för ett "problem" är bara *en* egenskap hos OS'et som man som
> konstruktiör/programmerare får ta hänsyn till.
Givetvis kan man se det som en egenskap hos systemet men det är problem, visserligen framtvingat av hårdvaran men ändock. Detta anser jag eftersom den egentligan uppgiften är att bygga ett så förutsägbart system som det bara är möjligt. Delade resurser är ett stort hinder.
Det lät inte som att det stämde.
Rubus VS (pekoklick för att ta konfigurera sitt OS) kör man nog mest bara på windows-burkar kanske, men Rubus OS går nog på de flesta arkitekturer som x86, PPC, C167, 68K/ColdFire osv.
Anledningen till att det mest verkar vara ett antal "libbar" som länkas ihop med "applikationer" är nog att man ska få en så liten footprint/låg lagg som möjligt (bygger på att väldigt mycket är känt när man bygger, ingen dynamisk schemaläggning osv).
Men visst, det ser inte ut som ett OS som man är van vid det kanske
Rubus VS (pekoklick för att ta konfigurera sitt OS) kör man nog mest bara på windows-burkar kanske, men Rubus OS går nog på de flesta arkitekturer som x86, PPC, C167, 68K/ColdFire osv.
Anledningen till att det mest verkar vara ett antal "libbar" som länkas ihop med "applikationer" är nog att man ska få en så liten footprint/låg lagg som möjligt (bygger på att väldigt mycket är känt när man bygger, ingen dynamisk schemaläggning osv).
Men visst, det ser inte ut som ett OS som man är van vid det kanske
-
bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
Nä, frågan är som sagt rätt difus. Ibland räcker sekundproritet och ibland måste man träffa rätt på 200ns när.... Lite olika krav och lite olika lösningar.
Realtid handlar minst lika mycket om programering och utnyttja styrkor, möjlighter och undvika svagheter då egenskaper hos ett system uppvisar svagheter för just den aktuella applikationen.
Timingnoggranhet hos en programdriven rutin på en PIC:
Basic: 40ms när
C: 500us när
Asm: 400ns när....
självklart en luddigt exempel, men räcker 40ms när och man har brått att testa en kod/hårdvara så varför inte? Räcker C så självklart välj det - enklare och snabbare att skriva koden än att skriva i asm. Är det tidskritisk på riktigt så är asm och utnyttja alla smarta finesser som finns i många uC en självklarhet. Sen att bra C kod kan vara "bättre" än dålig asm om man inte tänker sig för är en annan sak...
Realtid handlar minst lika mycket om programering och utnyttja styrkor, möjlighter och undvika svagheter då egenskaper hos ett system uppvisar svagheter för just den aktuella applikationen.
Timingnoggranhet hos en programdriven rutin på en PIC:
Basic: 40ms när
C: 500us när
Asm: 400ns när....
självklart en luddigt exempel, men räcker 40ms när och man har brått att testa en kod/hårdvara så varför inte? Räcker C så självklart välj det - enklare och snabbare att skriva koden än att skriva i asm. Är det tidskritisk på riktigt så är asm och utnyttja alla smarta finesser som finns i många uC en självklarhet. Sen att bra C kod kan vara "bättre" än dålig asm om man inte tänker sig för är en annan sak...
-
JimmyAndersson
- Inlägg: 26470
- Blev medlem: 6 augusti 2005, 21:23:33
- Ort: Oskarshamn (En bit utanför)
- Kontakt:
