mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Entwicklung eines RTOS auf OSEK Spek.


Autor: Franjo Rupcic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mister mit Kanister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo Rupcic (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo Rupcic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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


Autor: MartinK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo R. (franjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Berti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gutes Buch: "Operating System Concepts" von Silberschatz

Autor: Franjo R. (franjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fabian Scheler (rosepeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo R. (franjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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



Autor: Sven Günther (s705081)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Franjo R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Günther (s705081)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mister mit Kanister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Franjo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mister mit Kanister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Franjo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mariano Cerdeiro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.-

Autor: Mariano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
If someone is still interested there is a pre beta release of OpenSEK 
(opensource OSEK-VDX implementation) available in 
http://www.openosek.com.ar/.

Autor: Franjo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mariano Cerdeiro (Firma: Mariano) (cerdeiro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-docum... 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/releas...

diesem File wird in die Makefile von example01

http://www.soix.com.ar/svn/opensek/releases/releas...

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... 
(das generator)
http://soix.com.ar/svn/opensek/releases/release_v0... 
(config parser)
http://soix.com.ar/svn/opensek/releases/release_v0... 
(oil parser)

Ein file die wird generiert ist:
http://soix.com.ar/svn/opensek/releases/release_v0...

Die generierte files sind unter
http://soix.com.ar/svn/opensek/releases/release_v0...

das out/gen Directory gespeichert.

Grüße
Mariano.-

Autor: Mariano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.-

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mariano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.-

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte, bitte ein Beispiel, ich bin kein Jurist.

Muss ich meinen eigenen Code veröffentlichen oder gehört er mir?

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
* 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.

Autor: Mariano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.-

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nicht dein
> Code, nur die Änderungen auf FreeOSEK.

Na, dann ist ja alles super. Vielen Dank.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.