halloj!
Jag sitter o funderar på ett litet primitivt RTOS som jag tänkte skriva till en pic16F (den skall fungera på olika modeller).
Men som vanligt har jag stött på patrull och undrar om någon vet hur jag ska gå vidare.
jag hade viljat har en vektor med pekare till funktioner.
int *ptrvec =
{ &function1,
&function2...... osv
}
och därefter välja vilken funktion jag vill köra för tillfället.
Problemet är:
Vilket kommando skall jag använda för att anropa min funkiton?
CALL och GOTO verkar enbart vilja ha konstanter som parameter vilket gör min vektor värdelös.
Kan man på något sätt ställa PCn till en given adress i en PIC?
och hur gör jag för att hoppa tillbaka där jag precis var (en return)?
Best regards/ dangraf
pekare till funktioner i en PIC16f
> Vilket kommando skall jag använda för att anropa min funkiton?
Du menar hur det skall implementeras i assembler ?
Eller vad menar du med "kommando" ?
Är det av någon speciell anledning som ditt exempel är i C ?
Har du tänkt att hela RTOS'et skulle vara skrivet i C ?
> CALL och GOTO verkar enbart vilja ha konstanter som parameter...
Jepp.
De nyare PIC18 processorerna har en "extenden mode" med
indexerade GOTO och CALL som just är tänkta att användas av
C kompilatorer och liknande.
> Kan man på något sätt ställa PCn till en given adress i en PIC?
Japp, du kan ställa PCL/PCH till vad du vill, och nästa intsruktion
hämtas från den adressen. Inget konstigt, används vid "table lookup".
Kräver att man hanterar PCLATH rätt på processorer med > 2 K word minne.
> och hur gör jag för att hoppa tillbaka där jag precis var (en return)?
Intruktionen RETURN förutsätter att return-adressen ligger på stacken.
Men eftersom du inte själv kan skriva till stacken, så blir det
lite svårt eftersom du inte kommer från en CALL.
Du menar hur det skall implementeras i assembler ?
Eller vad menar du med "kommando" ?
Är det av någon speciell anledning som ditt exempel är i C ?
Har du tänkt att hela RTOS'et skulle vara skrivet i C ?
> CALL och GOTO verkar enbart vilja ha konstanter som parameter...
Jepp.
De nyare PIC18 processorerna har en "extenden mode" med
indexerade GOTO och CALL som just är tänkta att användas av
C kompilatorer och liknande.
> Kan man på något sätt ställa PCn till en given adress i en PIC?
Japp, du kan ställa PCL/PCH till vad du vill, och nästa intsruktion
hämtas från den adressen. Inget konstigt, används vid "table lookup".
Kräver att man hanterar PCLATH rätt på processorer med > 2 K word minne.
> och hur gör jag för att hoppa tillbaka där jag precis var (en return)?
Intruktionen RETURN förutsätter att return-adressen ligger på stacken.
Men eftersom du inte själv kan skriva till stacken, så blir det
lite svårt eftersom du inte kommer från en CALL.
Det KAN gå men det är knepigt...
Man kan få returadressen på plats vid att placera ett "välriktat" kall där man vill att rutinen ska återkomma till:
Man kan få returadressen på plats vid att placera ett "välriktat" kall där man vill att rutinen ska återkomma till:
Kod: Markera allt
...
CALL SetNewAddress
; Här återkommer funktionen sedan, do your RTOS-thing
...
SetNewAddress:
; Greja hoppet vid att sätta PCLATH, PCH och PCL rätt UTAN att CALL'a
Det beror väll lite på hur mycket overhead man vill ha också.
D.v.s hur stor del av cyklerna skall vara RTOS-administration rellativt "nyttigt" job-
Hur är det tänkt att RTOS'et skall interface'a mot applikationskoden ?
Är det app-koden som släpper tillbaka kontrollen till RTOS'et, eller
är det RTOS'et som själv tar kontrollen regelbundet ? Vilka
resurser (interrupt, timers mm) kommer att vara allokerade av RTOS'et ?
Säkert ett intressant projekt, men lite tveksamt om det är realistiskt på PIC16.
På PIC18 med mer resurser och minne, är det lite annorlunda. T.ex möjlighten
i "extended mode" att ha ett "window" med en bas address mot RAM
minnet gör context-switching lite enklare. Bara att byta bas-address. På PIC18
kan man även manipulera stacken.
Personligen tycker jag assembler är tillräckligt mycket "RT" för att även ha behov av ett "OS"...
Det blir för mycket Basic-STAMP över det hela.
D.v.s hur stor del av cyklerna skall vara RTOS-administration rellativt "nyttigt" job-
Hur är det tänkt att RTOS'et skall interface'a mot applikationskoden ?
Är det app-koden som släpper tillbaka kontrollen till RTOS'et, eller
är det RTOS'et som själv tar kontrollen regelbundet ? Vilka
resurser (interrupt, timers mm) kommer att vara allokerade av RTOS'et ?
Säkert ett intressant projekt, men lite tveksamt om det är realistiskt på PIC16.
På PIC18 med mer resurser och minne, är det lite annorlunda. T.ex möjlighten
i "extended mode" att ha ett "window" med en bas address mot RAM
minnet gör context-switching lite enklare. Bara att byta bas-address. På PIC18
kan man även manipulera stacken.
Personligen tycker jag assembler är tillräckligt mycket "RT" för att även ha behov av ett "OS"...
Det blir för mycket Basic-STAMP över det hela.
dangraf: tackar 
Jag började i 80-talet med Z80 assembler och fick så småning om tag på en TRS80 som jag disassemblerade PROMmen på så bra att när jag assemblerade den igen fick jag exakt samma kod!
Dom som gjorde mjukvaran gjorde MÅNGA "roliga" saker, jag rensade i dom och la till en drös med SRAM + batteri så "disk"-kommandon kunne spara och ladda från SRAM'en, autoexekvera program (BASIC-program såklart...), all kommandon fanns tillgängliga för BASIC'en....
Jag lärde en HEL DEL programmeringstrix då och jag _vet_ att jag gör solid mjukvara, testat genom MÅNGA år.
Men allvar: ett RTOS till PIC? Är det inte lite som att skjuta gråsparvar med kanoner?
Jag började i 80-talet med Z80 assembler och fick så småning om tag på en TRS80 som jag disassemblerade PROMmen på så bra att när jag assemblerade den igen fick jag exakt samma kod!
Dom som gjorde mjukvaran gjorde MÅNGA "roliga" saker, jag rensade i dom och la till en drös med SRAM + batteri så "disk"-kommandon kunne spara och ladda från SRAM'en, autoexekvera program (BASIC-program såklart...), all kommandon fanns tillgängliga för BASIC'en....
Jag lärde en HEL DEL programmeringstrix då och jag _vet_ att jag gör solid mjukvara, testat genom MÅNGA år.
Men allvar: ett RTOS till PIC? Är det inte lite som att skjuta gråsparvar med kanoner?
Det kanske är lite väl att kalla det jag tänkte göra för ett RTOS.
Jag är medveten om att vissa saker får man skriva i assembler, det var därför jag skev "kommandon" eftersom det är ett öppet uttryck för både assembel och C-kod.
I stora drag tänkte jag att kärnan skulle fungera ung såhär.
Man skapar sina tasks med deadline och om de är aktiva eller inte(waiting blocket osv) och sortarar in dem i en lista.
Därefter tänkte jag låta varje task köra tills den flyttat fram sin deadline och når return. Då så sorteras min lilla task med ny deadline in i listan och låster efterföljande task köras.
Deadlinen bestämmer när tasken skall köras (deadline == ticks).
Jag funderar även på att ha en idle task som kollar när nästa task skall köras och lägger processorn i sleep tills dess och på så vis spar ström.
Det är tänkt att alla mina tasks ska kunna avbrytas av interrupt från processorn (och därefter fortsätta när interrupt rutinen är avslutad)
Anledningen till allt detta jidder är pga att jag just nu programmerar i en spagettigryta med säkert 4-5 olika personers kod. Denna gryta behöver kammas så man får lite rätsida på det hela.
Jag vill bara kolla om det är möjligt. blir det för mycket kod eller för krångligt, så skiter jag i det. Men jag tror att det hade kunnat underlätta om det går.
SALVO är föresten ett RTOS för pic16 familjen, så visst går det om man krystar riktigt hårt!
Jag är medveten om att vissa saker får man skriva i assembler, det var därför jag skev "kommandon" eftersom det är ett öppet uttryck för både assembel och C-kod.
I stora drag tänkte jag att kärnan skulle fungera ung såhär.
Man skapar sina tasks med deadline och om de är aktiva eller inte(waiting blocket osv) och sortarar in dem i en lista.
Därefter tänkte jag låta varje task köra tills den flyttat fram sin deadline och når return. Då så sorteras min lilla task med ny deadline in i listan och låster efterföljande task köras.
Deadlinen bestämmer när tasken skall köras (deadline == ticks).
Jag funderar även på att ha en idle task som kollar när nästa task skall köras och lägger processorn i sleep tills dess och på så vis spar ström.
Det är tänkt att alla mina tasks ska kunna avbrytas av interrupt från processorn (och därefter fortsätta när interrupt rutinen är avslutad)
Anledningen till allt detta jidder är pga att jag just nu programmerar i en spagettigryta med säkert 4-5 olika personers kod. Denna gryta behöver kammas så man får lite rätsida på det hela.
Jag vill bara kolla om det är möjligt. blir det för mycket kod eller för krångligt, så skiter jag i det. Men jag tror att det hade kunnat underlätta om det går.
SALVO är föresten ett RTOS för pic16 familjen, så visst går det om man krystar riktigt hårt!
Det tar antagligen mycket mer tid att försöka få ihop det "RTOS" som du beskriver, än att skriva om de 4-5 personernas kod från grunden...
Är det verkligen 4-5 personer som har varit inblandade i samma PIC16 appikation ? Eller menar du över tiden (alltså inte samtidigt) ?
Hur mycket kod handlar det om ? Språk ?
Jag känner till SALVO, men används det i någon större skala ??
Är det verkligen 4-5 personer som har varit inblandade i samma PIC16 appikation ? Eller menar du över tiden (alltså inte samtidigt) ?
Hur mycket kod handlar det om ? Språk ?
Jag känner till SALVO, men används det i någon större skala ??
