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.-
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 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.phphttp://www.gnu.org/software/classpath/license.html
Grüße
Mariano.-
* 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.-
