Hallo zusammen. Der ewige Anfänger meldet sich mal wieder ^^ Dieser Thread ist aber nicht direkt eine Frage sondern eher sowas wie ne kleine Hoffnung unterstützung zu finden. Momentan bin ich mit meiner Studienarbeit beschäfftigt und befasse mich mit dem Thema "Entwicklung eines Real Time Operating System (RTOS) auf OSEK Basis". Natürlich wie immer mit nur theoretischen Wissen und ohne vorherigen praktischen Erfahrungen wage ich es ein kleines Projekt zu starten wo ich ab und zu doch jemanden brauche den ich bei Problemen etc ansprechen kann. Klar gibts auch Professoren aber die haben ja nie Zeit wenns zu hoch wird ^^ Das ganze werde ich auf einem Freescale HCS12 Board (S19DP256B) tut und parallel auf dem LPC2148. Zum Schluss soll ein OpenSource Projekt entstehen welches dann dieses "miniOSEK / freeOSEK" anbietet. Als Grundlage für Programmierung von RTOS - Systemen habe ich den letzten Monat damit verbracht µC/OS II vom Herrn Lambrose zu lesen und bin gerade dabei so meine ersten Erfahrungen damit zu machen wie ich sowas ähnliches selbst hinbekomme. Ich werd natürlich net alles selbst schaffen da ich mitte Dezember fertig sein möchte. Meine Aufgabe ist lediglich einen präemtiven Scheduler, ContextSwitch, TCB's, Stack sowie Semaphore zu erstellen die wie die OSEK Spek angiebt verwendet werden können. Die aktuelle VDX-OSEK Spec hab ich auch gelesen allerdings ist das ganze doch ein wenig viel wenn man nie ein fertiges OSEK mal verwendet hat (um eben ein Gefühl für die ganze Sache zu bekommen). Deswegen währe ich über jeden Tipp und jede Hilfe dankbar. Tipps sowie eigene Schedulingalgorithmen (kenn bisher nur Round Robin und den Scheduler von µC/OS), ContextSwitch Methoden, DesignTipps..... ICH BRAUCHE EINFACH ALLES ^^ Würde es auch super finden wenn sich der eine oder andere dann als Beta Tester im Januar anbieten könnte. Ein weitere Frage währe auch ... Wer will sowas?? Ist das Thema auch Interessant für andere Entwickler oder eher nicht. Danke das Ihr euch Zeit genommen habt das hier zu lesen ... und nun POSTEN POSTEN POSTEN ^^ cya
Hi Franjo, hört sich interessant an, habe ein paar Erfahrungen mit Osek O6. So wie ich das verstehe brauchst du ein Tool, was Dir die TCBs, Events usw. nach den Osek Richtlinien erstellt. Was ist denn so der Stand der Dinge? Könnte Dir meine Hilfe anbieten. Hab leider Dein Thread etwas spät entdeckt. Grüße Mister
Hallo Mister mit Kanister, ja also der aktuelle Stand ist folgender: Das Free OSEK ist in der Version 0.1 fertig und für 2 Derivate (HCS12 und LPC2148) protiert und vollständig dokumentiert. Mit der Veröffentlichung auf einer Homepage oder Sourceforge wird gewartet, da das Projekt nur in C-verwendet werden kann. D.h. Es exsistiert noch ein System Generator der aus einer OIL-File das System erzeugt. Wenn man nun Betriebssystemmittel nutzen möchte, muss man sich mit dem Sourcecode und den Controll Blöcken auseinandersetzen. Ansonsten sind 2 verschiedene Scheduling-Methoden implementiert (Verkettete Listen und Lookuptable s.h. µC/OS2). Alle Betriebssystemmittel sind soweit Implementiert ausser (Messages und ISR der Kategorie 2) und unterstützt werden alle Konformitätsklassen. Das ganze ist im Rahmen einer Studienarbeit abgelaufen die ich hiermit abgeschlossen habe. Ich werde am HSE Free OSEK weiterarbeiten doch alleine und mit 2 weiteren Projekten am Hals wird es noch ne weile dauern. Mit meinem Prof rede ich gerade über ne kleiner Studentengruppe die evtl. das Projekt übernimmt !!! ABER !!! das ganze nicht nur weiterentwickelt sondern es in ein AUTOSAR OS umwandelt. Wo ich Hilfe brauchen könnte währe die weiterentwicklung und portierung auf andere Derivate, prüfen der Konformität, erzeugen eines SystemGenerators und portierung auf GNU-Toolchain (da das ganze entweder mit Metrowerks oder Keil erstellt worden ist) und die Fehlersuche ^^ Im Anhang ist der bisherige Sourcecode zu finden, für eine Ausführliche Dokumentation bitte mich per email Kontaktieren.
Wenns ne Studienarbeit ist, würde ich gerne mal die Einführung lesen. Also was bringt das ganze, wozu ist es nütze, was sind die Vorteile und Nachteile, welchen Overhead (Größe, Geschwindigeit) hat es, wofür ist es gut geeignet, wofür ist es nicht geeignet, welche Einschränkungen ergeben sich für die Anwendung usw. So eine umfassende Nutzenanalyse gehört ja zu jedem Projekt. Peter
Hallo Peter, eine Nutzenanalyse wurde nicht so wirklich druchgeführt. Gerade weils eine Studienarbeit ist, war der Kerngedanke, das man nicht nur Betriebssystemmittel verwendet sondern versteht wie ein Kernel wirklich arbeitet, was man bei der Entwicklung bedenken muss und welche Probleme unterschiedliche Hardware für die portabilität mit sich bringt. Vorerst ist das kein Konkurenzprodukt sondern es geht ums lernen. Nichts desto trotz ist HSE Free OSEK ein laufendes Echtzeitbetriebssystem und kann evtl. mit Free RTOS oder µC/OS verglichen werden, jedoch das es die OSEK API anbietet und eines Tages eine "kostenlose und vollwertige alternative zu kommerzielen OSEK OS Distributionen sein soll". Die größe liegt momentan bei 6kByte. Dabei sollte man beachten das in dieser Version für beide Microcontroller (HCS12 und den LPC2148) Code im Gesamtprojekt vorhanden ist. Es ist gut geeignet zum lernen und weiterentwickeln aber auch um kleinere Projekte damit zu betreiben. Vorteile sind gegenüber FreeRTOS das die Dokumentation umfassender ist und eben das es die OSEK-API implementiert. Ein weiterer Vorteil ist, dass es die möglichkeit bietet verschiedene Schedulingalternativen einzusetzen wie das Bitmaskenscheduling von µC/OS welches erweitert worden ist. In HSE Free OSEK ist es möglich mehrere Tasks mit der selben Priorität zu verwenden. Die Einschränkungen sind das es noch in der Entwicklung ist. Es gehört noch viel Arbeit dazu um es zu vervollständigen. Unter der Adresse: http://www2.hs-esslingen.de/~frruit00 ist die Dokumentation sowie der Sourcecode vorhanden. Ich hoffe das beantwortet deine Frage cya
Das sieht ja schon nett aus! OSEK wird in der Regel als statisches system verwendet, d.h. die Tasks stehen zur Laufzeit fest und werden nicht dynamisch erzeugt. Dazu dienen bei euch wohl die config.h/.c Dateien. Wie werden die erzeugt? Von Hand oder habt Ihr auch einen OIL Konfigurator samt dazugehörigem Codegenerator? Immer wichtiger wird auch die Unterstützung von ttOSEK, auch zusammen mit OSEK (Im Idle Task des ttOSEK läuft dann ein normales OSEK). Wie sieht es mit der Unterstützung von shared Stack in einem nicht preemptiven oder gemischten System aus? Gruß Martin
Hallo Martin, Also was OSEK Time betrifft kann ich dir nichts dazu sagen weil 4 Monate für 2 Leute nicht gereicht haben um den ganzen Umfang von OSEK abzudecken. Was die config.c/config.h angeht liegst du vollkommen richtig, die werden per Hand generiert. Im .zip File liegen ein paar Beispiele vor wie diese auszusehen haben. VORSICHT: wenn man nicht genau weiß was man tut kann es zu unerwarteten Fehlern während der Laufzeit kommen. Shard Stack ist im Projekt nicht vorhanden. Jede Task benötigt ihren eigenen Stack! HSE Free OSEK arbeitet immer im Mixed Mode d.h. das system ist immer gemischt. Martin du sprichst da alles Bereiche an die erst mit weiteren Versionen folgen sollen. Diese hier ist nur der Kernel in seiner Grundform und da es keinen System-Genorator gibt, muss das Gesamte Projekt immer verwendet werden. Eine Speicheroptimierung vom Code muss man noch selbst je nach Anwendung vornehmen. Vielleicht findet sich ja der eine oder andere der sich dazu bereit erklärt mitzuwirken. Würde mich sehr freuen. Ansonsten kann es eben noch ne weile dauern bis alle Feature unterstützt werden. Was mich betrifft bin ich nicht mehr direkt an das Projekt gebunden da die Studienarbeit von der HS Esslingen weitergeführt werden soll. Das hat den Vorteil, dass mind. jedes halbe Jahr ne neuere Version rauskommen soll. Nichts desto trotz werde ich die Nachfolger unterstützen. Mein nächstes Privatprojekt ist ein MP3-Autoradio mit dem LPC2148 welches dann mit HSE FREE OSEK laufen soll, EFSL für die SD-Karten mit zu integrieren und wenns gut läuft auch nen USB-Stack zu implementieren. Das sollte dann die erste reale Anwedung mit OSEK werden wo auch meinerseits Erweitungen stattfinden. Gruß Franjo
Hallo, ich habe mal einen kurzen flüchtigen Blick in die Ausarbeitung geworfen und mir sind dabei ein paar Dinge aufgefallen, zu denen ich Fragen habe: - wie sieht es mit der Mehrfachaktivierung für Tasks aus? Wie berücksichtigt ihr die Reihenfolge der Aktivierungen? - im Zusammenhang mit dem Stack-based bzw. OSEK Priority Ceiling Protocol sollte man sich das Flag "locked" bei Ressourcen eigentlich sparen können, oder? - ISRs der Kategorie 2 werden nicht unterstützt, aber trotzdem werden Alarme angeboten, die Tasks aktivieren können, Events setzen können etc. Für solche Alarme, sofern sie durch einen Hardeware Counter gesteuert werden, braucht man doch eigentlich genau eine Kategorie 2 ISR - es wird explizit eine API zur Verfügung gestellt, die das PSW in einer Thread-lokalen Variable sichert und wieder herstellt, das sollte doch eigentlich Suspend-/ResumeAllInterrupts() implizit erledigen. Ciao, Fabian
Hallo Fabian, also ich versuch mal deine Fragen so gut es geht zu beantworten. Wenn eine Task einmal aktiviert worden ist hat die erneute aktivierung keinen Einfluss. Es ist zu berücksichtigen das uns für die Mehrfachaktivierung kein beispiel eingefallen ist von daher denke ich ist die Lösung vorerst ausreichen. Wenn nicht bitte ich um korrektur meiner Aussage und es kommt dann auf die ToDo List. Die Reihenfolge der aktivierung basiert auf dem FIFO prinzip bei Tasks mit selber Priorität. Wenn du nun die selbe Task öffter aktivieren willst ist es notwendig für diese Task mehrere TCB zu erstellen mit unterschiedlichen ID's. Der Stack kann aber der selbe sein. Was die frage mit Ressourcen und das das Flag "locked" angeht hast du recht. Durch die erhöhte Priorität der Task welche die Ressource in Anspruch nimmt sollte das Flag nicht benötigt werden. Es handelt sich hier um Rudimentären Code. Vorerst bleibt das Flag aber noch erhalten da es sich um eine Alpha-Version handelt. Erst nach positiven feedback und eigenen Test wird diese Stelle optimiert. ISR der Kategorie 2 werden nur teils Unterstützt. Das kann man aber noch keine Unterstützung nennen weil der Code (den ich noch nicht freigegeben habe) nicht OSEK Conform ist. In der jetzigen Version wird vom OSTimer(ISR Timer0) die KernelTask aufgerfuen welche sich auf Task-Level befindet. Die KernelTask hat die Aufgabe alle Counter (rudimentär) Alarmeabzuarbeiten. D.h. die KernelTask wird alle 10ms aufgerufen und inkrementiert die TickSperBase und Vergleich den Countervalue dann mit den Alarmwerten. Soweit ich weiß dient Suspend-/ResumeAllInterrupts() nur für das Nesting innerhalb einer Task. Jedenfalls ist das bei HSE Free OSEK der Fall. Du hast recht wir bieten die Funktion SaveSR()/RestoreSR() an sie sollte, welche das PSW in einer Thread-lokalen Variable sichert. Sie ist jedoch keine API sondern wird nur von den Betriebssystemmitteln verwendet. Wenn ich mich mit Suspend-/ResumeAllInterrupts() irre bitte ich ebenfalls um bereichtigung. Ich bitte nochmals um Verständnis, das hier ist noch kein vollwertiges oder fertiges OSEK, es soll eines Tages mal eines werden. Fragen oder Mithilfe wie von Fabian oder Martin sind sehr erwünscht und ich freu mich auch darüber wenn jemand interesse daran zeigt. cya
Hallo Franjo, > keinen Einfluss. Es ist zu berücksichtigen das uns für die > Mehrfachaktivierung kein beispiel eingefallen ist von daher denke ich > ist die Lösung vorerst ausreichen. Wenn nicht bitte ich um korrektur > meiner Aussage und es kommt dann auf die ToDo List. also, nur weil dir dafür kein Beispiel eingefallen ist, ist das kein Grund, das nicht zu implementieren - der OSEK Standard spezifiziert dieses Verhalten und du möchtest ein zum Standard konformes Betriebssystem bauen. Ich liefere dir aber gern ein Beispiel: das OSEK OS beschreibt grundsätzlich eine OS, das echtzeitfähig implementiert werden kann, d.h. es ist auf die Behandlung von Ereignissen ausgelegt. solche Ereignisse können periodisch (solche sind nett, da einfach ;-)) oder sporadisch/aperiodisch sein. Bei letzteren kennt man leider keine Periode, nur eine minimal Zwischenankunftszeit => die Bearbeitungszeit für aperiodische bzw. die Deadline für sporadische Ereignisse kann durchaus höher sein, als diese minimale Zwischenankunftszeit => mehrfache Aktivierung der Ereignisbehanldung, also TASKs > Die Reihenfolge der aktivierung basiert auf dem FIFO prinzip bei Tasks > mit selber Priorität. Wenn du nun die selbe Task öffter aktivieren > willst ist es notwendig für diese Task mehrere TCB zu erstellen mit > unterschiedlichen ID's. Der Stack kann aber der selbe sein. Sicher, das geht, ist aber nicht schön, wenn ich mich recht an den OSEK OS Standard erinnere, ist immer nur eine Aktivierung "aktiv" (hier kann ich mich aber irren (*)), es würde also nur ein TCB benötigt werden. Wenn ich mich bei (*) wirklich irren sollte, wäre deine Möglichkeit, die einzig gangbare, schließlich könnte ein mehrfach aktivierter TASK durchaus Schedule() aufrufen ... Vielleich noch ein Wort zur Implementierung des Schedulers - du hast mitnichten zwei verschiedene Scheduling-Varianten - beide arbeiten prioritäten-gesteuert mit statischen Prioritäten, du bietest verschiedene Implementierugen desselben Schedulers an. Die erste Variante (Prioritätsliste) würde ich für dieses System einfach mal weglassen, macht IMHO mit statischen Prioritäten nicht so viel Sinn. Für solche Systeme ist die zweite Variante besser geeignet, die man gemeinhin eigentlich als Multi-Level-Queue-Scheduler (MLQS) bezeichnet (ein "echter" Bitmap-Scheduler, könnte nur einen Faden pro Priorität verwalten). Will man die Auswahl des nächsten Fadens noch optimieren, könnte man die Liste noch über alle Faden hindurch schlängeln (aber nur einfach verkettet - logsich), man hat dann eine Mischung aus Prioritätsliste und MLQS. Dann noch der TCB und der Kontextwechsel: Im TCB benötigt man meiner Meinung nach folgendes nicht: - Taskzustand: der hängt schließlich im wesentlich einfach nur davon ab, ob und in welcher Liste ein Faden gerade eingekettet ist - Unterscheidung zwischen Basic/Extended Task: wenn man die Task IDs entsprechend auftrennt, also z.B. alle Extended Tasks eine höhere Task ID haben als Basic Tasks, muss man sich nur die höchste Task ID eines Basic Tasks merken - Beim Kontextwechsel auf dem LPC2148 wird offenbar nicht zwischen flüchtigen und nicht-flüchtigen Registern unterschieden, es ist je nach Implementierung blanker Overhead bei einem Kontextwechsel alle Register R1 - R12 zu sichern (ich gehe mal nicht davon aus, dass ihr den Kontextwechsel geinlined habt ...), beim HCS12 ist das nicht sooo dramatisch, da gibt es schließlich nicht soooo viele Register Und dann mal noch der Kernel Task: wenn ich euch recht verstanden habe, ist der Kernel Task zwar der Task mit der höchsten Priorität, aber dennoch ein "normaler" Task, richtig? Was passiert dann, wenn gerade ein nicht-verdrängbarer Task läuft und läuft und läuft ... ? Was passiert dann mit den Countern die erhöht werden sollten ... > Ich bitte nochmals um Verständnis, das hier ist noch kein vollwertiges > oder fertiges OSEK, es soll eines Tages mal eines werden. Fragen oder > Mithilfe wie von Fabian oder Martin sind sehr erwünscht und ich freu > mich auch darüber wenn jemand interesse daran zeigt. sind ja keine "Vorwürfe" nur Dinge, die mir halt aufgefallen sind und auf die ich hinweisen möchte :-) Weiter Anmerkungen kommen bei Gelegenheit. Viel Spaß weiterhin! Ciao, Fabian
Hallo Fabian,
erstmal danke an dein Interesse und an die Verbesserungsmöglichkeiten.
Ich versuch nun mal unsere Gedanken zu erläutern.
//----------------------------------------------------------------------
---
Kernel Task:
Diese Task stellt einen Sonderfall dar. Sie wird auf jeden Fall
aufgerufen wenn es OSTimer-Interrupt zuschlägt (alle 10ms). Die ISR
merkt sich nur ob es sich um eine preemtive oder nicht preemptive Task
handel. D.h. Die Kernel Task läuft auf alle fällt und ihre Prio ist die
höchste aber nicht für den Anwender, weil er diese Prio nicht belegen
darf. Doch die Kernel Task wird auf jeden fall ausgeführt.
//----------------------------------------------------------------------
---
Die Sache mit Mehrfachaktivierung, ja du hast recht, diese wird
ebenfalls nicht im vollen maße Unterstützt. Ich sag jetzt einfach mal
Zeitmangel, doch das feature wird noch ergänzt. Meine Vorstellung der
Implementierung ist eine weitere Variable im TCB die sich merkt wie oft
die Task aktiviert wird. Beim Terminieren des ersten Taskaufrufs wird
dann geprüft ob die Variable = 0 ist, wenn net, wird sie ggf. Running
oder Ready. Was hälst du (Ihr) davon??
//----------------------------------------------------------------------
---
Die Sache mit dem nichtbenötigten Taskzustand währe meiner Meinung nach
bei der Entwicklung doch wichtig. Da wir ja oft abfragen besitzen wie
if(TaskList[ID].TCBStat == Running)
{...}
Doch man könnte das natürlich auch anders regeln doch es währe net
höchst Prior.
//----------------------------------------------------------------------
---
Mit den Scheduling gebe ich dir recht. Wir verwenden beim Testen
eigentlich fast nur den MLQS und es ist eine Mischfrom aus
Prioritätsliste und MLQS. Da ja die Ready Table nur ein Array aus
Pointer ist welche auf TCB's zeigt und diese mit *nextTCB entwender auf
NULL oder einen anderen TCB zeigen.
Warun nun 2 Schedulingverfahren?
Erstens aus lernzwecken und zweitens hatte ich im August letzen Jahres
noch keine Ahnung wie ein Schedulingalgorithmus funktioniert. Von daher
habe ich auf mir bekannte Mittel zurückgegriffen und da waren die
verketten Listen (Prioritätsliste) das erste was mir eingefallen ist.
Das MLQS habe ich erst durch das Buch µC/OS II vom Herrn Labrosse
kennengelernt und 1 + 1 zusammengezählt, was die Mischform ergab.
In der Dokumentation habe ich eine Messung wo aber erstaunlicher weiße
für den LCP2148 die Scheduling Zeiten nur leicht voneinander Abweichen.
//----------------------------------------------------------------------
---
Zum Context Switch:
Ja du hast recht, es wird nicht unterschieden ob die Register flücjtig
bzw. nicht flüchtig ist. Das liegt daran das der LPC bei Eintritt in
ISR's nicht auf dem Stack der Task weiterarbeitet wie es bei HCS12 der
Fall ist. Um das Problem zu Lösen, kamen wir auf die Idee für jede Task
den Context nicht auf den Stack zu legen, sondern jeder Task einen
zusätzlichen Stack (ContextStack) anzulegen. Immer wenn es zu einem
Taskwechsel kommt, werden alle Register (SVC-Modus) auf den ContextStack
der Task gelegt. Der Vorteil ist, dass das Debugen einfacher fällt da
man ja immer genau weiß wo der Context abgelegt wird, und das der Stack
nicht unnötigt wächst. Bei der realisierung in Interrupts muss also
bevor die Kernel Task aktiviert wird zwischen dem ContextStack der Task
die unterbrochen wurde, dem Stack der ISR und dem ContextStack der
KernelTask gewechselt werden. Dem Stack der ISR deswegen, weil man nach
Beenden der KernelTask wieder in der ISR landet. Das ist auch der Grund
warum wir einmal die Funktion __ContextSwitch() benutzen und zum anderen
__ISRCTXSwt().
Bei der Implementierung von ISR der Kategorie 2 ist es das Ziel nur noch
eine Funktion zu besitzen also nur __ContextSwitch(), da das selbe
Problem auftritt wenn eine ISR eine Task aktiviert oder ein Event setzt
oder nen Alarm auslöst.
Was mir noch unklar ist, ist ob ich nun doch nicht alle Register R0-R12
zwischenspeichern muss, da es sich ja immer um die Register im SVC-Modus
handelt?
//----------------------------------------------------------------------
---
Fabian du würdest mir sehr helfen wenn du mir eventuell ein Konkretes
Beispiel im Einsatz mit einem echten OSEK zuschicken könntest.
Ich freu mich schon auf den nächsten Post
cya
Hallo Franjo, eine Beispiel Nutzung wo ein OSEK eingesetzt wird, ist die Steuerung eines Hybrib-Antriebs. Die Steuerungsanlage die den Elektromotor Regelt und die Umschaltung zwischen Entladen und Laden der Akkus Steuert wird mit einem OSEK Konformen OS verwendet. Gruss Sven PS: Echt Nettes Projekt.
Hallo Sven, erstmal danke für den lieben Lob. Hab letzte Woche einen potentziellen Nachfolger kennengelernt d.h. es geht bestimmt auch weiter. Am Freitag halt ich ne Präsentation darüber und werde mich im Anschluss danach mit 2 Professoren über die Zukunft von HSE Free OSEK Unterhalten. Dabei wird unter anderem die Gründung einer Homepage besprochen. Dein Beispiel find ich gut. Ladeschaltung, Akkus und ein Elektromotor währen ja nicht all zu schwierig aufzubauen. Ich will nen AutoradioMP3 player auf dem LPC2148 mit HSE Free OSEK betreiben. Da mein zukünftiger Arbeitgeber sich mit entwicklung von Embedded System Software für den KfZ Bereich beschäfftigt hoffe ich dass ich auch mit OSEK konformen Betriebssystemen arbeiten werde und so Erfahrung für die weiterentwicklung des Free OSEKS finde. Lieben Gruß Franjo
Hallo Franjo, ich werde, wenn mir demnächst mal die Zeit dazu bleibt den ARM Tree auf den gcc kompilier umsetzen. Da ich die ganze Entwicklung auf dem Mac mache erleichtert mir dann das ganze das Ausprobieren. Außerdem werde ich dann den lpc2129 nutzen, der hat zwei CAN2.0b Schnittstellen und ist damit schon für Automotive Aufgaben präsidiert. Als direkte Implantation wäre hier wirklich die Grundschaltung zur Antriebssteuerung für ein Elektrofahrzeug geeignet. Wäre sicher auch eine Nette Diplom Arbeit, mit allen Sicherheitsrelevanten Funktionen, Steuerung über CAN und Fehler Management auf Basis vom FreeOSEK. Und dann bitte MISRA-C Einhalten ;) Gruss Sven
Sven das find ich wirklich gut und würde mich wirklich sehr freuen. Ja du hast recht währ ne super Erweiterung für ne Studien- bzw Diplomarbeit. Du kannst mir mal ne e-mail schreiben und ich könnte am Freitag das den Professoren vorschlagen. Ich denke da würde sich was realisieren lassen. Gruss Franjo
Hi Franjo, da ich finde das das eine gute Sache ist die Du da machst, mal ein paar Fragen, um den Thread am Leben zu erhalten: Wie gestaltet es sich mit der Portierung auf AVR Systeme? So wie ich das sehe sind doch die API Funktionen der Kern des Systems und die hast Du ja schon fast vollständig implementiert. Also wenn man alles außen herum dem Controller, auf dem man das System laufen lassen will, anpasst, wäre es doch kein Problem mit dem Portieren? Ist es denn überhaupt so, dass die API Funktionen ohne weiteres verwendbar sind? Ich muss zugeben ich hab mir Deine doc noch nicht genauer angesehen, finde das aber nach wie vor interessant.
Hallo Mister mit Kanister, freut mich das dir das OSEK freude macht. Also zu deiner Frage bezüglich portierbarkeit. Du hast recht, das "aussenrum" ist anders doch der Code sollte theoretisch portierbar sein. Man müsste sich eigenlich nur die jeweilige Timer ISR anpassten sowie den Context Switch. Problem bei der Sache ist lediglich einer. Der Context Switch für die LPC Version ist umfangreicher da zwischen 4 verschiedenen Stackadressen sowie 2 Betriebsmodies gewechselt wird. Leider kenn ich mich mit den AVR Controller nicht wirklich aus doch wenn die ISRs den Stack der Task nutzten die unterbrochen worde, würde das die Portierung wesentlich erleichtern. Es währe sehr interessant das ganz zu Testen jedoch steht das Projekt momentan. Am Wochenende werde ich mich aber wieder hinsetzen und versuchen das ganze mal langsam mit EFSL zu verheiraten. Da EFSL sehr gerne genutzt wird denke ich würde sich jeder darüber freuen die mit einem Kostenlosen Betriebssystem verwenden zu können. Ansonsten geht es erst ab Mitte März mit der weiterentwicklung offiziel weiter wo die Messages implementiert werden sowie den umstieg auf die GNU Toolchain. Mister, danke nochmal das den Thread am Leben hälst. Falls das ganze hier mager ausfällt keine Sorge. In spätestens 1. Jahr wird das Projekt öffentlich mit Homepage und allem drum und dran. CYa
Hallo Franjo, also ich werd mal bei Gelegenheit ein Versuch wagen das auf AVR anzuwenden, wird mir wohl vorerst nur rudimentär gelingen wenn überhaupt. Bin auf dem Gebiet auch kein Profi, mal sehen was bei rauskommt. Was genau meinst Du mit Context Switch? Ist damit der Reschedulprozess gemeint, also die phys. Prozessorabgab? Grüße
Hallo Mister, ja genau. Context Switch wird auch als Dispatcher bezeichnet und ist dafür verantwortlich die Arbeitsregister, Stackpointer, Programmcounter und ggf. Prozessorstatuswort einer Task zu sichern. Ich würde bevor du dich ans portieren machst zuerst diesen Mechanismus anschauen. Findest du in meiner Doku also ne Theoretische erklärung und Lösungen zum LPC und HCS12. Danach würde ich mir das ganz beim ARM anschauen und vorallem nachschauen was genau passiert wenn ein Interrupt eintritt. Ansonsten wenn Fragen oder so sind helf ich dir natürlich sehr gern. CYa
Hallo Franjo, ich arbeite in meiner Abschlussarbeit gerade an einem Testkonzept um OSEK Betriebssysteme auf Konformität zum Standard zu prüfen. Dabei hat mir dein FreeOSEK schon sehr weitergeholfen, dafür zunächst mal vielen Dank. Ich habe gesehen das du noch auf eine Bewertung des FreeOSEK auf Konformität wartest. Bei Interesse können wir uns gerne mal austauschen. Ich habe eine Frage zur Bedienung des True-Time Simulator, bei der du mir hoffentlich helfen kannst. Für die Durchführung meiner Testcases benötige ich eine Ausgabe die ähnlich zu printf() arbeitet. Ich möchte einfach nur die Ausgabe von Strings in einem Terminalfenster abfangen. Leider meldet mir der Compiler des CodeWarrior ein fehlendes Symbol _CASE_CHECKED_BYTE, wenn ich versuche sci1.h einzubinden und in der HardwareInit() die SCI1_Init() auszuführen. Kannst du damit etwas anfangen? Gruß Alex
Hallo Alex, zunächst einmal danke für den Post. Mich freut es immer wieder wenn sich jemand mit dem Thema auseinander setzt. Die Fehlermeldung von dir sagt mir leider nichts. Es ist klar das Define _CASE_CHECKED_BYTE wird in deinen Sourcen verwendet aber ist nicht definiert. Es ist mittlerweile 2 1/2 Jahre her, dass ich mich mit dem HC12 auseinander gesetzt habe. Leider kann ich dir dazu nichts sagen. Der aktuelle Stand der Treiber ist mir daher unbekannt. Ich kenn mich mit dem theoretischen Teil von OSEK ganz gut aus, aber spezifische Sachen wie Hardware, Compiler etc. dafür ist es leider schon zu lange her. Trotzdem viel Glück bei deiner Arbeit.
Hallo Franjo, bist du noch an der Hochschule Esslingen tätig oder stehst dort mit Professoren/Studenten in Kontakt? Ich hatte im letzten Beitrag kurz erwähnt wie sich der Rahmen meiner Abschlussarbeit zusammensetzt. Leider werde ich über eine Validierung, des mir vorliegenden OSEK Betriebsystems nicht hinauskommen. Wie ist zur Zeit der aktuelle Stand was die Kontrolle der OSEK Konformität für das HSE FreeOSEK angeht? Das Problem ist das ich keine zweite Meinung habe, die mir die Korrektheit meiner Testfälle bestätigen kann. Ich könnte im Rahmen einer zusätzlichen Testreihe z.B. den Bereich Task Management des HSE FreeOSEK testen und dir das Testprotokoll zukommen lassen. Wenn du mir bestätigen kannst, das die Ergebnisse mit deinem Kenntnisstand über das HSE FreeOSEK übereinstimmen wären wir beide einen Schritt weiter. Du hättest eine Validierung der Konformität von externer Stelle und ich die Bestätigung für die Korrektheit meiner Testsequenzen. Gruß Alex ======================================================================== == FÜR ALLE DIE DIESEN BEITRAG LESEN: Das Unternehmen für das ich arbeite hat großes Interesse, das ihr eigenes OSEK weiterentwickelt wird und sucht Studenten die sich im Rahmen eines Praktikums oder einer Abschlussarbeit mit dem Thema auseinander setzen möchten. Der Betrieb agiert zum Großteil im Bereich Automotive, die Niederlassung liegt in Köln. Bei ernstem Interesse bitte hier im Forum einen Beitrag schreiben. Erwünschte Kenntnisse: - Basiswissen über den OSEK/VDX Standard - Vertrauter Umgang mit der Programmiersprache C - Erste Erfahrungen im Bereich Embedded Programmierung
Hallo Alex, vor 2 Jahren wäre ich der richtige Partner für dich gewesen. Seit damals habe ich nichts mehr mit OSEK am Hut. Nichts desto trotz kann ich dir ggf. weiter helfen, da ich mich trotzdem noch theoretisch damit sehr gut auskenne. An der Validierung der Tests hätte ich sehr großes Interesse. Ich würde mich wieder dahinter setzten, da mir an der Arbeit sehr viel liegt. Ich würde Vorschlagen, dass du mich per eMail Kontaktierst und wie mal Telefonieren oder Skypen. franjo.rupcic@gmx.de Mit freundlichen Grüßen Franjo
Hallo Alex und Franjo ich programmiere gerade auch ein OpenSource OSEK (als Hobby), ich bin siemlich fertig mit die erste beta Release. Heute läuft nur auf "POSIX" (ich arbeite auf linux aber soll auf Windows auch laufen). Ich werde es in kurz freigeben. Da ich im ähnlichen Bereich arbeite ich warte auf eine Bestätigung von meiner Firma um es zu freigeben. Mit interessiert sehr eine "externe" Validierung da ich nur ein bisschien teste. Ich habe paar Requirements geschrieben, mein Prozess ist aber nicht perfekt, ich habe kein Tool für Requirements-E nur mediawiki/svn/doxygen/php/gcc/gnumake sind alle meine tools. m.cerdeiro at gmail dot com cerdeiro at yahoo dot com dot ar Danke. Mariano.-
If someone is still interested there is a pre beta release of OpenSEK (opensource OSEK-VDX implementation) available in http://www.openosek.com.ar/.
Hallo Mariano, ich habe mir mal deine Implementierung angeschaut. Auf den ersten Blick sieht es nach einer sehr ordentlichen Arbeit aus. Erinnert mich sehr stark an meine Implementierung. Was ich leider nicht finden konnte, ist die Konfigurationsdatei. Bei kommerziellen Implementierungen von OSEK (ProOSEK, CANos etc.) erhält man ein Konfigurationstool, dass mit dem OIL File festlegt, wie das Betriebssystem konfiguriert wird. In meiner Implementierung damals gab es kein Tool, sondern eine Datei Namens osek_config.h. Diese Datei setzte sich auch lediglich aus #defines zusammen. Wie konfiguriert man openSEK?
Hallo Franjo, Ich freue mich, dass es dir gefällt hat, es ist aber nicht fertig, die Alarms apis machen noch nichts, rest funktioniert aber nicht viel getestet. ich versuche gerade ein bisschen zu dokumentieren unter: http://soix.com.ar/index.php/opensek/opensek-documentation.html ich glaube ich werde eine MediaWiki einrichten, oder eine andere benutzen im (http://www.proyectosutn.com.ar/wiki/index.php/OpenOSEK) wo auch die Req geschrieben habe. Bei OpenSEK gibt es keine Konfiguration Tool (es gibt aber Generator), muss man die oil Files per Hand anpassen, aber die oil sprache ist sehr einfach. Jedes Projekt, zb. example01 hat ein etc Ordner wo die Konfiguration drin steht: http://www.soix.com.ar/svn/opensek/releases/release_v0_1_020080917_prebeta/example01/etc/example01.oil diesem File wird in die Makefile von example01 http://www.soix.com.ar/svn/opensek/releases/release_v0_1_020080917_prebeta/example01/mak/Makefile als config file gegeben. Wenn man "make generate" macht, wird diesem oil file geparst und OpenSEK generiert für diese Konfiguration, deswegen braucht man php da das generator im php Sprache geschrieben wurde: http://soix.com.ar/svn/opensek/releases/release_v0_1_020080917_prebeta/OpenSEK/etc/generator.php (das generator) http://soix.com.ar/svn/opensek/releases/release_v0_1_020080917_prebeta/OpenSEK/etc/config.php (config parser) http://soix.com.ar/svn/opensek/releases/release_v0_1_020080917_prebeta/OpenSEK/etc/oilParser.php (oil parser) Ein file die wird generiert ist: http://soix.com.ar/svn/opensek/releases/release_v0_1_020080917_prebeta/OpenSEK/etc/src/Osek_Internal_Cfg.c.php Die generierte files sind unter http://soix.com.ar/svn/opensek/releases/release_v0_1_020080917_prebeta/out/gen/ das out/gen Directory gespeichert. Grüße Mariano.-
Hallo Alle, wenn jemand nach mein open source OSEK Projekt noch sucht, das Projekt ist jetzt im SourceForge.net: http://opensek.sourceforge.net/ Grüße Mariano.-
aus der README: * FreeOSEK is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * Linking FreeOSEK statically or dynamically with other modules is making a * combined work based on FreeOSEK. Thus, the terms and conditions of the GNU * General Public License cover the whole combination. Kann mir jemand den letzten Abschnitt erklären, am besten anhand eines Beispiels. So, wie ich das verstehe, ist der letzte Absatz genau anders, als es bei FreeRTOS der Fall ist. Bei FreeRTOS gehören die Anwendungen, die ich programmiere, mir und ich muss sie nicht veröffentlichen. Sehe ich das richtig, dass das hier anders ist? Für mich ist das ein sehr entscheidendes Kriterium, wenn ich die Wahl habe zwischen FreeRTOS und FreeOSEK.
Hallo Heinz, und danach steht: .... In addition, as a special exception, the copyright holders of FreeOSEK give you permission to combine FreeOSEK program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with FreeOSEK solely through the FreeOSEK defined interface. You may copy and distribute such a system following the terms of the GNU GPL for FreeOSEK and the licenses of the other code concerned, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code. .... mehr Info unter: http://opensek.sourceforge.net/licensing.php http://www.gnu.org/software/classpath/license.html Grüße Mariano.-
Bitte, bitte ein Beispiel, ich bin kein Jurist. Muss ich meinen eigenen Code veröffentlichen oder gehört er mir?
* In this way you can use FreeOSEK for commercial purposes * without having to * provide your software as GPL. Also gehört meine Anwendung mir, oder? Wenn ich Änderungen am FreeOSEK mache, gilt die GPL oder sonst was, ich muss es veröffentlichen. Das verstehe ich.
Hallo Heinz, dein Code die mit FreeOSEK zusammen gelinkt wird gehört zu dir unter die Lizenz die du definierst. In dem Fall, dass du FreeOSEK änderst (Verbesserungen, Bugfixen, usw.) diese Änderungen von FreeOSEK müssen veröffentlichen werden. Nicht dein Code, nur die Änderungen auf FreeOSEK. Grüße Mariano.-
> Nicht dein > Code, nur die Änderungen auf FreeOSEK. Na, dann ist ja alles super. Vielen Dank.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.