RTOS för AVR

[JJ]

Jo, oJsan, det hade nog tagit längre tid.

Min avsikt med denhär tråden var inte att diskutera för och emot RTOS överhuvudtaget men eftersom diskussionen startat och jag fått frågan(karlstedt):

1) Vi har en stor klass av system mellan 8-bitars och PC där RTOS kan behövas. Nu pratar vi inte AVR.
2) man kan slippa skriva så mycket kod själv=>spar tid. Till priset av mindra kontroll.
3) Om man behöver en IP-stack så har många OS en sådan integrerad. Detta kanske är killer-argumentet för mindre system.
4) Om man är många utvecklare behövs en struktur, ett OS kan vara en hjälp.
5) Samma sak om komplexiteten stiger över den nivå där man kan ha allt i huvudet. (*Du* kanske kan men inte den klantige praktikanten som skall hjälpa dig. OS *kan* kan vara en hjälp.)
6) En hjälp att separera applikationsdomänen från implementationsdetaljer.
7) Tillgång till komponenter; filsystem, ip-stack...

Punkt 6 är den viktigaste men inte för små system.


Både sodjan och Icecap har tydligen framgångsrikt utvecklat system utan RTOS. Då finn det finns ju ingen anledning att ha ett RTOS för sakens skull.


sodjan: Jag tycket att timers och interrupt *är* svårt

[Fagge]

Men vad är det som avgör om ett program är ett os eller ett vanligt hemma snickrat program innehållande subrutiner för att kontrollera övrig kringutrustning?.
Begreppet os har jag aldrig hört talas om när det gäller små microcontrolers. I mina öron låter det mer som att det är ett lass med färdiga subrutiner som bara är att anropa ifrån huvudprogrammet, & då kallar man det ett os för att det ska låta mer avancerat & häftigt !?.

[Icecap]

oJsan: och hur många av dessa apparater använder en 8-bit µC med 4Kb RAM???

Om ett RTOS tar över en viss % av RAM/ROM vil jag kalla det overkill men kommer man upp i en viss storlek program/data kan ett (RT)OS ge en stabil plattform att stå på och gå vidare ifrån.

I effekten kommer alla de interruptrutinet (ISR) osv. man lägger i programmet ju att utgöra ett OS i samband med "main"-programmet så skillnaden är om man vill utveckla en standart plattform eller inte.

Essensen är, för mig, att om ett (RT)OS tar t.ex. 20% systemresurser (ROM/RAM/CPU belastning) eller mer är det totalt overkill men i många större och komplicerade applikationer kan det vara ett bra val, man får ju en hel del på köpet så att säga.

I Windows får man ju en "lätthanterat" GUI samt en hel del annat som gör det enklare (filåtkomst osv osv.) men i ett egetbyggd "OS" måste man uppfinna hjulet minst 1 gång, det kan vara bra eller dåligt, allt beroende av hur skicklig programmör man är.

Jag har t.ex. färdiga rutiner för LCD, EEPROM, RTC, datum/tidsräkning, seriell komunikation, FLASH "self-programming" och mycket annat liggande som jag återanvänder när jag får tillfällen och kommer det nya enheter i mitt spektrum gör jag en rutin till det som jag sedan kan återanvända.

Och det är väl en sorts OS?

[oJsan]

Nej Fagge, riktigt så är det inte. Ett OS är inte bara en uppsättning funktioner, det innehåller en schemaläggare som hanterar olika "tasks" som man satt upp.. utöver detta finns events mailboxes och andra finesser. Jag är ingen expert på det här området men ett program är inte os. Ett os kan däremot innehålla ett program!
Någon som vet bättre får gärna utveckla definitionen på OS när det gäller mikrokontrollers..

[oJsan]

icecap: Förmodligen ingen av dem, hur så?

Att ha färdiga funktioner/rutiner som man kan klistra in vid behov är suveränt, men det utgör ju inte ett OperativSystem tycker jag!
Ett OS är något som "ligger i botten" och sköter/övervakar övriga program och ser till att de kan dela processorkraft(tid), minne och andra hårdvaruresurser..

[Icecap]

oJsan: då kanske du kan förklara för mig om DOS var ett OS?

I DOS fanns ingen schemaläggning eller timeslot-styrning.

Vad du pratar om är ett multitasking OS och det är definitivt inte DOS/Win3.1 fastän de är OS som sådan. Det fanns "tillägg" till dessa OS som kunne hjälpa till med multitasking men det var ju patches.

Ett operativsystem är, i min uppfattningen, den grund som gör att cpu'n inte spårar ut när den inte gör något "vettigt" så i grunden, down-to-the-bone är:
void main(void)
{
while(1)
{
// Kör de saker som ska köras
}
}
ju ett OS...mycket primitivt och simpelt utan några finesser men likaväl ett OS.

Grejen är att det är ett "hårdkodad" OS, man kan inte i efterhand ändra/lägga till/ta bort tasks och funktioner (jovisst går det men det är ganska knepigt) när systemet kör.

Själva återanvändandet äv rutiner är såklart inte ett OS, det är bara klokt

[Fagge]

Jag gör precis som du Icecap, med att bygga upp en subrutins bank för att snabbt komma i gång med framtida projekt.
Men alltså vadå schemaläggare, detta låter mer som ett PC-program.
Men i min lilla HC11 värld så har man ju ett huvud program & en hel hög med subrutiner & sen så lopas ju huvudprogrammet hela tiden men beroende på vad som händer på ingångarna så ändras ju funktionerna som processorn ska utföra!?. Sen kan man ju givetvis utnyttja tröga enheter så som displayer som inte är så snabba, & i stället för en delay så kan man be processorn att kolla något annat under tiden & då känns det som att man jobbar pararellt.

[oJsan]

Jag vet inte alls hur DOS är uppbyggt, men finns det verkligen inte någon mekanism där som hanterar minne, hårdvara, avbrott osv? Jag har svårt att tänka mig att det vara är en evig while-loop?
...enligt nätet så finns det många definitioner på vad ett OS egentligen är, så vi kanske kan skippa den diskussionen eftersom vi är rätt så OT.

Alltså.. vad menar du med drivrutinsbibliotek, det är INTE ett OS eller? Tidigare skrev du en retorisk fråga om att det _var_ det....?

[sodjan]

JJ > "Jag tycket att timers och interrupt *är* svårt"

Och jag tycker att knyppling är svårt, men om jag var
intresserad så skulle jag antagligen kunna lära mig det med...

Vad är problemet med att det är "svårt" ?

[JimmyAndersson]

sodjan: Håller fullständigt med där! Det vore urtråkigt om man skulle låta bli saker bara för att det var svårt...



Hittade förresten denna förklaring av OS:

"Ett operativsystem (eller bara OS) är en uppsättning program för en dator som har till uppgift att underlätta användningen av den samma. Operativsystemets uppgifter är dels att sköta om och övervaka de övriga programmen som används på datorn (de s.k. användarprogrammen), så att de klarar av att samsas om gemensamma resurser som nätverk, hårddisk, terminaler, tangentbord, skärmar, processortid och minne, och dels att ge användaren ett sätt att interagera med datorn. Användarprogrammen kommunicerar med operativsystemets operativsystemskärna genom ett gränssnitt som definieras av de systemanrop som operativssystemet erbjuder.
En viktig egenskap hos ett operativsystemet är hur det sköter tidsdelningen av processorn. Idag är det vanligt att man vill att operativsystemet ska ge möjlig åt flera användare (s.k. multiuser?) eller flera processer (s.k. multitasking) att använda datorn samtidigt. Många moderna operativsystem har ett grafiskt användargränssnitt inbakat i operativsystemet.

Realtidsoperativsystem är en typ av operativsystem som radikalt skiljer sig från de system som används på persondatorer."

[Icecap]

Citerar mig själv: "...en sorts OS?"

Ett OS är oftast i betydelsen av att ha en standart väldokumenterat "grund" att viderutveckla program på, är det RTOS och/eller multitasking OS behövs en del overhead till att säkra minnesåtkomst osv, så långt allt rätt.

Men var finns definitionen av att ett OS ska ta hand om allokeringen av minne, interrupt osv?

Jag kan hålla med dig om att ett OS "brukar" ha dessa funktioner och att det tar hand om en hel del "housekeeping" men det är ju inte något jag har sett definierat att det ska vara så. Jag misstänkar att det kan vara svårt att sälja en while(1){}; för någon större summa så det finns väl en anledning till att det finns mycket med när man inhandlar ett OS.

Mina "standart" drivrutiner lägger jag ju med vid behov och det i sig ger just den väldokumenterade funktionen vilket gör att de blir en integrerat del av det OS jag byggar och därmed utgör de en del av ett OS eller hur?

Men OK, jag tror att vi alla är hyggligt överense om att ett RTOS till en processor med 8Kb FLASH och ett par K RAM är total overkill, kommer vi på filsystem, nätverk, GUI, multitask, Mb/Gb osv är ett OS mycket bra att ha och har man realtidskrav är det ett RTOS som gäller.

Och som jag ser det finns det en komplexitets-gråzon där det är huggit som stuckit vilket man ska ha, OS eller "hemkört".

[karlstedt]

1) Vi har en stor klass av system mellan 8-bitars och PC där RTOS kan behövas. Nu pratar vi inte AVR.
2) man kan slippa skriva så mycket kod själv=>spar tid. Till priset av mindra kontroll.
3) Om man behöver en IP-stack så har många OS en sådan integrerad. Detta kanske är killer-argumentet för mindre system.
4) Om man är många utvecklare behövs en struktur, ett OS kan vara en hjälp.
5) Samma sak om komplexiteten stiger över den nivå där man kan ha allt i huvudet. (*Du* kanske kan men inte den klantige praktikanten som skall hjälpa dig. OS *kan* kan vara en hjälp.)
6) En hjälp att separera applikationsdomänen från implementationsdetaljer.
7) Tillgång till komponenter; filsystem, ip-stack...

Angående din första punkt så undrar jag varför du börjar tråden med att nämna ATmega88 och ATmega128 och nu säjer du helt djärvt att vi inte pratar AVR? I vilken kategori tror du dessa faller in i?
punkt två; att ha färdiga bibliotek för tex en LCD eller annan extern utrustning spar också tid men är ju inte direkt ett operativsystem.
punkt tre. en stack har inget som helst att göra med operativsystemet...

sedan de återstående punkterna verkar vara mera din åsikt än verklighet.
en specifikation skulle jag vilja säga är botet på de problem du nämner där.

[JJ]

karlstedt: Anledningen att jag nämnde avr-modellerna i början är att jag har tänkt jobba med dem. Anledningen att jag nämnde dem senare är att diskussionen hade drivit iväg från den ursprungliga frågeställningen och jag ville markera det. I praktiken är enligt min erfarenhet ip-stackar o.likn. kopplade till ett OS, ofta är de testade tillsammans och så. Så i praktiken har det väldigt mycket att göra med OSet. Eller? Övriga punkter är mina åsikter grundade på verkligheten. Och som formuleringarna antyder, ett OS kan vara en del av lösningen men visst krävs en spec också.

Men OK, jag tror att vi alla är hyggligt överense om att ett RTOS till en processor med 8Kb FLASH och ett par K RAM är total overkill, kommer vi på filsystem, nätverk, GUI, multitask, Mb/Gb osv är ett OS mycket bra att ha och har man realtidskrav är det ett RTOS som gäller.

Och som jag ser det finns det en komplexitets-gråzon där det är huggit som stuckit vilket man ska ha, OS eller "hemkört".

Japp, vi är överens: en smakfråga, typ så att säga.

sodjan: Problemet med att interrupt är svårt är 1) att det tar tid att mickla med det. Jag skulle vilja bygga mekaniken, etsa kretskorten, konstruera elektroniken, skriva mitt eget RTOS, skapa ett eget programeringsspråk etc osv...problemet är att jag hinner med en procent av det och jag måste välja. 2) Om jag skall tänka på interrupt samtidigt som jag konstruerar en applikation blir det väldigt mycket att tänka på "och jag är en björn med en väldigt liten hjärna". Kan man separera inerrupttänkandet (kalla det OS eller vad du vill) från applikation kan man ta ett problem ena dagen och ett annat nästa.

[Kaggen]

JJ: Jag tycket att timers och interrupt *är* svårt

Jag har pulat en del med trådar, signaler, semaforer och dylikt både i windows och linux (det var dock ett tag sedan) och jag måste säga att själv programmera och sätta upp interrupt i assembler på PIC, är minst lika enkelt om inte enklare.

Frågan är hur du tänker utnyttja multitaskingen? Skall du köra flera "program" samtidigt som någon användare kan starta, eller skall du tråda "ett" program/applikation? Skall du kommunicera emellan trådarna/programmen eller skall du ha RTOS bara för interruptens skull?

Du bör också kolla vad det finns för utvecklingsverktyg för det RTOS du väljer. Finns det assembler bibliotek och/eller C bibliotek?

Frågan du lär ställa dig är om du inte gör det mer komplicerat än vad det skulle blivit utan RTOS?

mvh Mats